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