乐趣区

关于mysql:多云部署多主模式的MGR集群每个云一个MGR-节点满足业务单元化改造的需求

作者：

jiezi

在

欢送来到 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 公布！

更多文章