乐趣区

关于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 公布！

退出移动版