我正在寻找一种高可用的SQL解决方案！我读过的其中一篇文章是关于Galera集群中的“几乎同步”：https://www.percona.com/blog/2012/11/20/understanding-multi-node-writing-conflict-metrics-in-percona-xtradb-cluster-and-galera/
他说
当writeset实际应用于给定节点时，任何锁定 它通过打开（尚未提交）的事务检测到的冲突 该节点导致打开的事务被回滚。
和
复制线程应用的写集总是胜利
如果WriteSet与已提交的事务冲突，会发生什么？
他还说：
然后然后在每个节点上按顺序“认证”写入集。
Galera Cluster如何通过群集订购WriteSets？是否有任何隐藏的主节点使WriteSets有序;像Zookeeper这样的东西？或者什么？
答案 0 :(得分：1)
这是第二个问题（关于Galera如何命令写集）。
Galera根据Totem协议实施扩展虚拟同步（EVS）。 Totem协议实现了一种令牌传递形式，其中只允许带有令牌的节点发送新请求（据我所知）。因此写入是有序的，因为一次只有一个节点具有令牌。
对于学术背景，你可以看看这些：
答案 1 :(得分：0)
（本答案并非直接解决您的问题，但它可能让您相信Galera'好'。）
在Galera（PXC等）中，交易有两次失败。
在运行事务的节点上，将操作与相同节点上当前运行的操作进行比较。如果存在冲突，则其中一个事务会停止（请innodb_lock_wait_timeout）或死锁（并回滚）。
在COMMIT时间，信息被发送到所有其他节点;他们检查您的交易是针对节点上的任何内容还是待处理的（在gcache中）。如果存在冲突，则会发回一条消息，说明会有问题。因此，始发节点的COMMIT失败。因此，您必须检查COMMIT语句中的错误。
与单节点系统一样，通过重放整个事务来解决死锁通常。
在autocommit的情况下，有一个小的，可配置的重试次数，之后语句将失败。所以，再次检查错误。但是，由于已经尝试过重试，您可能想要中止该程序。
目前（在我看来）Galera在至少3个不同的物理位置至少有3个节点，是MySQL最好的HA解决方案。它可以有效地承受任何单点故障。 （来自Oracle的Group Replication / InnoDB Cluster即将推出，非常有前景。）
有一点需要注意的是，“关键阅读”问题在加莱拉有一个解决方案，但你必须采取行动。见wsrep_sync_wait。 （截至撰写本文时，InnoDB Cluster没有解决方案。）
有关迁移到PXC / Galera时的编码差异的提示（上面包含其中一些提示），请参阅http://mysql.rjweb.org/doc.php/galera。