
金融应用场景下跨数据中心的MGR架构方案(1)
0. 内容提纲
• 1. 运行环境
• 2.部署MGR A&B
• 3. 部署MGR A、B之间的复制通道
• 4. 几个注意事项
如何在多个数据中心部署多套MySQL MGR集群以便快速切换。
在金融应用场景下,经常会要求在同城多中心部署高可用数据库架构,以期实现在发生故障时能达到快速切换的目标。
在同一个数据中心内,可以部署MGR集群,就可以实现快速灵活切换。
而即便是在同城,跨数据中心时,网络条件好的话,延迟可能也在 1ms 之内。这种网络条件下,如果要在同城多中心部署MGR集群也是可以尝试的(如果业务并发量不是特别高的话),但考虑到多数据中心间有较大概率会出现光缆被挖断等风险,所以还是不建议这么做。
因此,最好还是在同一个数据中心内部署一套独立的MGR集群,再通过主从复制(replication)方式(可以是异步复制或半同步复制),把数据复制一份到另一个数据中心内的MGR集群里,这样一旦主机房出现异常时,就可以快速切换到备用机房了,并且不担心数据库的高可用保障等级。
上面该方案的架构示意图。
接下来一起来完成这个架构方案的实施。
1. 运行环境
本次采用3个节点部署这套架构,各节点用途说明见下
每个节点上都运行两个实例,分别是3306、4306端口,其中3306端口的实例构成MGR A集群,4306端口的实例构成MGR B集群。
除了MySQL官方社区版本外,如果想体验更可靠、稳定、高效的MGR,推荐使用GreatSQL版本。本文采用GreatSQL 8.0.22版本,关于这个版本的说明详见 GreatSQL,打造更好的MGR生态。
2. 部署MGR A&B
按照常规方式部署MGR即可,下面是一份关键配置参考:
更多关于MGR以及复制的配置参考这份指南:MGR最佳实践。
启动MGR A,确认工作正常:
用同样的方法,再部署MGR B,并确认工作正常:
确认上述2个MGR集群以及各个节点的 server_uuid 都不一样。
3. 部署MGR A、B之间的复制通道
从MySQL 5.7开始,支持多源复制(Multi-Source Replication),因此我们可以很方便的利用多源复制,在两个MGR集群之间再构建一个复制通道。
这个复制通道,既可以选择 异步复制(Asynchronous Replication),也可以选择 半同步复制(Semisynchronous Replication),可以根据两个MGR集群之间的网络状况,以及实际业务需要评估决定。
本案选择半同步复制方案,这仅限于实验目的,不表示我们推荐大家也采用半同步方案。
相应地,下面也是一份半同步的参考配置,大家可根据实际情况适当调整:
在MGR B的Pirmary节点上创建半同步复制通道(记得设置通道名):
确认半同步复制生效:
P.S,上面的信息是已经运行一段时间后截取出来的,所以GTID的值看起来比较大。
也可以用类似的方法构建传统的异步复制通道,以及双向复制通道,都是可以的。
4. 几个注意事项
1. 两个MGR集群各节点的 server_uuid 确保不重复。
2. 两个MGR集群的名字(group_replication_group_name)确保不重复。
3. 构建完复制通道后,MGR B里的Primary节点最好也要设置为只读(super_read_only=1),避免误操作写入数据。
4. 两个MGR集群之间也要定期校验数据一致性,不管是异步复制还是(增强)半同步复制,乃至MGR都还存在多个丢数据的BUG,不能盲目乐观相信用了增强版同 步/MGR就能保证数据一致性了。
本文先介绍基于多数据中心、多套MGR的架构方案。下一次再进一步介绍当发生故障或其他异常需要进行高可用切换的方案。
本文转载自公共号GreatSQL社区。
