是否有可能在percona集群中具有读写竞争条件？

Question

我今天讨论了percona集群中的一个事件。设置如下：

一个三节点的percona集群负载--由haproxy均衡。在代理对所有三个节点进行平衡的情况下，都会进行读写。

应用程序(php)使用数据库进行编码，使其能够对数据库执行写操作，然后立即尝试读取新记录。这个人告诉我，有些情况下，如果立即读取(在写入之后)被代理平衡到一个与写操作不同的节点，它就不会找到记录。

这在percona集群中有可能吗？据我所知，执行写查询的节点必须首先接收所有percona节点的确认，然后才能将成功返回给发出查询的客户端。那么，这是怎么可能的，即使读取查询位于与执行写操作所用的服务器不同的服务器上？

Answer 1

复制设置确定哪些类型的查询首先执行因果关系检查，即让正在执行的服务器确认它是最新的。

检查这里的wsrep_sync_wait变量描述：https://www.percona.com/doc/percona-xtradb-cluster/5.5/wsrep-system-index.html

我们的顾问建议设置6(即2 | 4)，意思是UPDATE、DELETE、INSERT和UPDATE执行因果关系检查。换句话说，编写查询。最后，我们决定切换到7(即1 | 2 | 4)，对读取执行因果关系检查。虽然这使得阅读需要更长的时间，但是你描述的过时阅读的问题就消失了。

注:经过几周的成功设置，问题突然又出现了。当我们(暂时)开始在同一台服务器上执行所有的读写操作时，它就消失了，所以似乎出现了一些问题。我想知道是否有另一个环境发挥作用，并需要修复以及。

更新.

我相信我们在上一个说明中减轻了这个问题，但我似乎记不起到底是什么了。

使用单个写节点

无论如何，我强烈建议只使用一个写节点。由于所有的写入反正都是复制的，所有服务器都在执行类似的写入，所以写缩放是非常有限的--不像读缩放。然而，在单个节点上编写确实给了我们一些优势。

避免冲突写入

使用具有多个写节点的集群有一个不幸的后果:如果两个同时写入不同节点的冲突，它们一开始可能看起来成功，但其中一个在提交时会失败。至少对于应用程序开发来说，这有很大的影响。运行此风险的应用程序中的每个位置都必须实现一些捕获和重试逻辑.或者我们只需要一个写节点！

当然，您需要高可用性。我们使用ProxySQL来实现负载平衡。如果写入节点下移(或被取下)，则另一个节点成为写节点。是的，只有在故障转移期间可能存在上述风险，但这只是一个非常小的窗口。理想情况下，在执行手动故障转移时，我们应该暂时对传入的请求进行排队，让旧的写节点在分配新的写节点之前完成它的工作。

自动增量并不总是增加

自动增量并不一定总是在增加！我发现这是一个特别令人不安的问题，许多人都不知道。最大的ID不一定是最近的行。违反直觉很难推理。有各种配置选项。

自动增量可以使用wsrep_auto_increment_control和朋友控制，ServerA使用1, 4, 7, ...，ServerB使用2, 5, 8, ...，ServerC使用3, 6, 9, ....这避免了ID的争用，是的，但它也跳过ID，并真正创建非增量序列。

或者，正如我从Percona了解到的，我们可以使用单个写节点并禁用自动增量控制。现在的数值应该一直在增加。在故障转移期间，如果新写节点还没有复制最新的自动增量值，那么它可能会在提交时失败一两个事务，尽管我认为这个问题应该通过这个答案顶部讨论的因果关系设置来缓解。

我同意后者，并且，为了确定地，我指示每个人不要依赖于严格增长的自动增量。

请让我们知道您是否可以使用HAProxy实现单个写节点和高可用性。我已经看到它是用ProxySQL完成的，但是很高兴知道它是否可以不用它来完成。