共计 3336 个字符，预计需要花费 9 分钟才能阅读完成。
欢送来到 GreatSQL 社区分享的 MySQL 技术文章，如有疑难或想学习的内容，能够在下方评论区留言，看到后会进行解答
- GreatSQL 社区原创内容未经受权不得随便应用，转载请分割小编并注明起源。
- 本文来自投稿：by 作业帮 DBA 团队
一、架构需要:
- 失常状况下每个云的业务程序 (下图中的 APP) 通过本地的 cetus 写入本地的 MGR 节点 (默认启动时通过 cetus 配置本地 MGR 节点为 rw); 读申请会依据 cetus 读写拆散策略路由到不同的云的 MGR 节点
- 当本地 MGR 节点故障, 则 cetus 会自动检测配置中的后端 MGR 节点, 选取一个新的存活节点作为 rw 节点。此时业务跨云读写。
- 当单个云整体故障时 (单云孤岛), 集群残余节点能够失常提供服务, 业务层须要切流, 将业务流量指向其余失常云的服务 (APP)
二、测试流程
1. 性能测试比照
- 同机房是指 sysbench 以及压测的节点都在同一个机房; 跨机房指 sysbench 和 压测脚本中配置的 mysql_host 在不同的机房
- 次要进行 Read_Write 以及 Write_Only 两个模式进行比照
主机配置: 35C 376G
MySQL 版本: GreatSQL 8.0.25
buffer_pool: 24G
测试数据: sbtest 8 张表 * 3000w
sysbench 压测脚本:
- oltp_read_write.lua
- oltp_write_only.lua=> Read_Write 压测比照
跨机房状况下集群吞吐量降落显著, 耗时减少显著
=> Write_Only 压测比照
跨机房比照同机房耗时减少 20ms 左右
跨机房下耗时高起因排查:
通过抓包剖析, 压测应用的脚本中的事务都是带有 begin,commit。在 commit 之前的每个语句都要减少一个 rtt 的延迟时间 (机房之间的耗时在 3ms 左右)。
因而在跨机房的状况下每个事务的响应工夫都会至多额定减少 (每个事务中 sql 个数 * 3ms) 的工夫。
2. 故障场景测试
次要测试在单节点故障, 多节点故障, 单机房整体故障时对业务的预期影响以及 DB 侧应答的策略 集群初始状态: (3 个 主机, 每台主机部署一个 MGR 节点 +cetus 节点)
Cetus 中 rw 节点在 172 上
==> 单实例故障场景:
1.Kill 掉 172 实例后，在 192 和 10 实例上察看集群状态，172 被踢出 MGR 集群 Cetus 中 rw 节点切到了 192 上，172 实例 offline+ro 状态
2. 重新启动 172 实例, 并启动 group_replication 退出组复制
mysql> start group_replication;
mysql> select * from information_schema.replication_group_member
察看 cetus 中后端的状态:172 实例复原 up + ro 状态
留神：cetus 用户有 super 权限, 当 DB 实例重启后 Cetus 会尝试主动 start group_replication，如果 start group_replication 失败 Cetus 会一直尝试重启，不倡议开启
论断：MGR 集群中多数实例宕机后重新启动实例，start group_replication 后会主动退出 MGR 集群并补齐数据（如果 binlog 存在），Cetus 中实例状态也会复原为 up+ro
问题：如果实例产生故障前在 Cetus 中为 rw 状态，当实例故障时 Cetus 中的 rw 节点会切换到别的实例，故障实例复原后在 Cetus 中为 ro 状态，如果须要复原 rw 状态，须要手动保护 ==> 多实例故障
Kill 掉 172 和 10 的 2 个实例，在存活实例 192 上查问 members 状态，172 和 10 实例为 UNREACHABLE
Cetus 中存活实例 192 可读不可写，写入报错 service unavailable
如果直连 192 实例写入会 hang 死
重启 172 和 10 实例后，启动 group_replication 失败, 须要从新疏导组复制
在 172 和 10 的实例上 start group_replication 退出 MGR 集群胜利
论断：MGR 集群中少数实例宕机后重新启动实例，start group_replication 会失败，此时 MGR 集群已不存在，须要从新初始化集群能力将原有实例退出集群
问题：MGR 集群中少数实例故障会导致集群解体，整个集群可读不可写，如果故障实例短时间能复原则可手动重置 MGR 集群让实例重新加入集群，不可写工夫绝对较短，对业务影响较小。如果故障实例短时间不能复原，则须要强制激活存活的多数节点为新 MGR 集群（单主模式），复原写能力，对业务提供服务，而后利用存活节点数据备份从新搭建 DB 实例，复原新的多主 MGR 集群 ==> 单机房网络隔离
192 实例单云网络隔离。此时以后云内的业务通过 192 上的 cetus 进行读写操作时, 可读不可写, 写入报错 service unavailable; 另外两个节点组成的 MGR 集群能够失常提供服务 192 cetus 实例查看的状态
172 和 10 节点 MGR 集群状态, 数据写入失常
网络复原后被隔离的 192 实例主动退出 MGR 集群且补齐网络隔离期间 MGR 集群写入的数据
问题点：如果业务次要流量在被隔离的机房且下层无奈切流到少数节点的 MGR 集群，则须要强制激活隔离机房的实例为单实例多主模式 MGR 集群，复原写能力（后续再增加实例），此时原来的 MGR 集群会被拆分为 2 个同时可用的 MGR 集群（多数节点的单实例多主模式 MGR 集群和少数节点的多实例多主模式 MGR 集群）如果 2 个集群都有数据写入则后续会因为写入数据抵触或者 gtid 不统一无奈合并为 1 个集群，如果后续想合并数据最好是通过业务层做数据回归 ==> 多机房网络隔离
此时各机房相互拜访不通，则会造成多个可读不可写的实例
- 短时间内网络不能复原 须要强制激活某个实例复原读写能力，在 192 上察看另外 2 个节点变为 UNREACHABLE
Cetus 中 192 实例从 up+ro 复原为 up+rw
- 机房之间网络抖动，随着网络复原 MGR 集群主动复原
能忍耐抖动工夫内可读不可写，不须要强制激活节点复原写能力，网络复原后 MGR 集群会主动复原
测试总结:
以后测试次要联合 CETUS 来满足在各种不同场景下我司的业务需要。不同公司的不同业务有着不同的状态.
在应用其余 proxy 进行测试时, 须要留神在各种场景下业务的预期状态是什么样的.
- 比方在单云隔离时, 被隔离的云内的业务是心愿能持续读取数据还是不可读不可写;
- 是否容许跨云拜访, 能承受的耗时范畴是多少?
以上种种须要应用 proxy 或者其余外挂伎俩设置不同的读写策略。总体测试下来 MGR 的多主模式的性能以及故障解决满足咱们的应用需要。Enjoy GreatSQL :)
文章举荐：
GreatSQL MGR FAQ
https://mp.weixin.qq.com/s/J6…
万答 #12，MGR 整个集群挂掉后，如何能力主动选主，不必手动干涉
https://mp.weixin.qq.com/s/07…
『2021 数据技术嘉年华·ON LINE』：《MySQL 高可用架构演进及实际》
https://mp.weixin.qq.com/s/u7…
一条 sql 语句慢在哪之抓包剖析
https://mp.weixin.qq.com/s/AY…
万答 #15，都有哪些状况可能导致 MGR 服务无奈启动
https://mp.weixin.qq.com/s/in…
技术分享 | 为什么 MGR 一致性模式不举荐 AFTER
https://mp.weixin.qq.com/s/rN…
对于 GreatSQL
GreatSQL 是由万里数据库保护的 MySQL 分支，专一于晋升 MGR 可靠性及性能，反对 InnoDB 并行查问个性，是实用于金融级利用的 MySQL 分支版本。
Gitee:
https://gitee.com/GreatSQL/Gr…
GitHub:
https://github.com/GreatSQL/G…
Bilibili：
https://space.bilibili.com/13…
微信 &QQ 群：
可搜寻增加 GreatSQL 社区助手微信好友，发送验证信息“加群”退出 GreatSQL/MGR 交换微信群
QQ 群：533341697
微信小助手：wanlidbc
本文由博客一文多发平台 OpenWrite 公布！
