第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 是单人坐庄 , 发起协商 。
- 在多主模式下 , 非庄家节点想发起事务时 , 要将事务信息转交给庄家 , 由庄家代表它发起协商 。
- 这样庄家就变成了是性能瓶颈 。
- 每个节点都有机会发起协商 , 各个节点发起事务时 , 由自己发起协商即可 。
- 不存在明显的性能瓶颈
关于 MySQL 的技术内容 , 你们还有什么想知道的吗?赶紧留言告诉小编吧!
文章插图
推荐阅读
- Redis集群做法的难点,百万并发客户端「实战」
- 上海|全球科技集群100强发布,北京、上海、粤港三城跻身前十
- 部署红帽pcs高可用集群详解
- 推动5G产业融合 重庆将形成千亿级5G产业集群
- 手把手教你实现Docker部署Redis集群
- 听说生鲜领军企业k8s集群都上云了,鱼会飞了?
- 打造数智化协同生态 京东超市携手五常共建复合型产业带集群
- 连环触发!MongoDB核心集群雪崩故障背后竟是……
- helm3部署milvus集群部署
- 如何基于Docker快速搭建Elasticsearch集群?