0

我正在寻找一个高可用的 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 与已提交的事务冲突会发生什么？

他还说：

然后在每个节点上（按顺序）“认证”写入集。

Galera Cluster 如何使 WriteSets 在集群上排序？是否有任何隐藏的主节点使 WriteSets 有序；像动物园管理员？或者是什么？

4

2 回答 2

1

这是第二个问题（关于 Galera 如何订购 writesets）。

Galera基于 Totem 协议实现了扩展虚拟同步（EVS） 。Totem 协议实现了一种令牌传递形式，其中只有具有令牌的节点才被允许发送新请求（据我了解）。因此写入是有序的，因为一次只有一个节点具有令牌。

对于学术背景，你可以看看这些：

Totem 单环排序和成员协议

数据库状态机和组通信问题

于 2018-02-02T02:20:31.737 回答
0

（此答案不会直接解决您的问题，但它可能会让您相信 Galera 是“好”的。）

在 Galera（PXC 等）中，交易失败通常有两种情况。

  1. 在运行事务的节点上，将操作与当前在同一节点上运行的操作进行比较。如果存在冲突，则其中一个事务被停止（想想innodb_lock_wait_timeout）或死锁（并回滚）。

  2. 有时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 时的编码差异的提示（其中一些包含在上面）。

于 2017-11-12T15:06:44.557 回答