问题

我们都知道,MGR 用了类 Paxos 机制的协议,协商过程只要多数节点同意即可达成一致。

那么对于 3 节点的 MGR 集群,我们能不能让某一个节点延迟较高(放在地球另一端),而不影响整体性能?

实验

我们省略搭建 MGR 集群的过程,得到一个 3 节点的集群:

将 3 个节点的流控功能全关掉,让数据压力能尽情跑:

下面来跑一个 sysbench 压力,这里用 ts 命令,给命令输出的每一行增加了时间戳:

然后我们给 mgr-3 节点增加一些网络延迟:

运行一段时间后,取消网络延迟:

来看这段时间 sysbench 的性能报表:

在我们给网络增加延迟的这段时间,会发现 MGR 的整体性能下降,直到我们取消网络延迟。

分析

实验结果跟我们的直觉不同,即使没有流控功能的影响,单节点的网络延迟仍然会影响到 MGR 的整体性能。

其中的原理与 MySQL 使用的 multi-paxos 协议有关,讲述起来会比较复杂,大家可以参考 Oracle 的 slide:

https://www.slideshare.net/lefred.descamps/dataopsbarcelona-2019-deep-dive-into-mysql-group-replication-the-magic-explained

小贴士:

这里我们简化描述一下原理:

1. MGR 选取了 multi-paxos 协议作为底层协商协议

2. 传统 paxos 是单人坐庄,发起协商。

  • 在多主模式下,非庄家节点想发起事务时,要将事务信息转交给庄家,由庄家代表它发起协商。

  • 这样庄家就变成了是性能瓶颈。

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

  • 每个节点都有机会发起协商,各个节点发起事务时,由自己发起协商即可。

  • 不存在明显的性能瓶颈

4. 但在轮流坐庄的模式下,如果存在一个高延迟的节点,轮到它坐庄时,其他节点都需要等待,它延迟越高,大家就等待越久,从而影响整体性能。

关于 MySQL 的技术内容,你们还有什么想知道的吗?赶紧留言告诉小编吧!