第23问：3节点MGR集群，能不能将一个节点放在地球另一端？问题我们都知道

文章插图
问题我们都知道， MGR 用了类 Paxos 机制的协议，协商过程只要多数节点同意即可达成一致。
那么对于 3 节点的 MGR 集群，我们能不能让某一个节点延迟较高（放在地球另一端），而不影响整体性能？
实验我们省略搭建 MGR 集群的过程，得到一个 3 节点的集群：
文章插图
将 3 个节点的流控功能全关掉，让数据压力能尽情跑：
文章插图
下面来跑一个 sysbench 压力，这里用 ts 命令，给命令输出的每一行增加了时间戳：
文章插图
然后我们给 mgr-3 节点增加一些网络延迟：
文章插图
运行一段时间后，取消网络延迟：
文章插图
来看这段时间 sysbench 的性能报表：
文章插图
在我们给网络增加延迟的这段时间，会发现 MGR 的整体性能下降，直到我们取消网络延迟。
分析实验结果跟我们的直觉不同，即使没有流控功能的影响，单节点的网络延迟仍然会影响到 MGR 的整体性能。
其中的原理与 MySQL 使用的 multi-paxos 协议有关，讲述起来会比较复杂，大家可以参考 Oracle 的 slide：
文章插图
小贴士：
这里我们简化描述一下原理：
【第23问：3节点MGR集群，能不能将一个节点放在地球另一端？】1. MGR 选取了 multi-paxos 协议作为底层协商协议
2. 传统 paxos 是单人坐庄，发起协商。

在多主模式下，非庄家节点想发起事务时，要将事务信息转交给庄家，由庄家代表它发起协商。
这样庄家就变成了是性能瓶颈。

3. multi-paxos 是轮流坐庄的形式。

每个节点都有机会发起协商，各个节点发起事务时，由自己发起协商即可。
不存在明显的性能瓶颈

4. 但在轮流坐庄的模式下，如果存在一个高延迟的节点，轮到它坐庄时，其他节点都需要等待，它延迟越高，大家就等待越久，从而影响整体性能。
关于 MySQL 的技术内容，你们还有什么想知道的吗？赶紧留言告诉小编吧！

文章插图