• GreatSQL社区原创内容未经受权不得随便应用，转载请分割小编并注明起源。

0. 内容提纲

    1. 运行环境
    1. 部署MGR A&B
    1. 部署MGR A、B之间的复制通道
    1. 几个注意事项
如何在多个数据中心部署多套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生态。

  1. 部署MGR A&B
    依照惯例形式部署MGR即可，上面是一份要害配置参考：
group_replication_single_primary_mode=ONlog_error_verbosity=3group_replication_bootstrap_group=OFF group_replication_transaction_size_limit=<默认值150MB，但倡议调低在20MB以内，不要应用大事务>group_replication_communication_max_message_size=10Mgroup_replication_flow_control_mode=“DISABLED” #官网版本的流控机制不太正当，其实能够思考敞开group_replication_exit_state_action=READ_ONLYgroup_replication_member_expel_timeout=5 #如果网络环境不好，能够适当调高slave_parallel_type=LOGICAL_CLOCKslave_parallel_workers=128 #能够设置为逻辑CPU数量的2-4倍binlog_transaction_dependency_tracking=writesettransaction_write_set_extraction=XXHASH64slave_checkpoint_period=2

更多对于MGR以及复制的配置参考这份指南：MGR最佳实际。

启动MGR A，确认工作失常：

[root@GreatSQL mgrA-1][(none)]> select * from performance_schema.replication_group_members;+---------------------------+--------------------------------------+-------------+-------------+--------------+-------------+----------------+| CHANNEL_NAME              | MEMBER_ID                            | MEMBER_HOST | MEMBER_PORT | MEMBER_STATE | MEMBER_ROLE | MEMBER_VERSION |+---------------------------+--------------------------------------+-------------+-------------+--------------+-------------+----------------+| group_replication_applier | 5499a6cb-91cb-11eb-966f-525400e802e2 |    mgrA-1   |        3306 | ONLINE       | PRIMARY     | 8.0.22         || group_replication_applier | ec2fcbeb-976c-11eb-a652-525400e2078a |    mgrA-2   |        3306 | ONLINE       | SECONDARY   | 8.0.22         || group_replication_applier | edfbdeda-91c8-11eb-a3c6-525400fb993a |    mgrA-3   |        3306 | ONLINE       | SECONDARY   | 8.0.22         |+---------------------------+--------------------------------------+-------------+-------------+--------------+-------------+----------------+[root@GreatSQL mgrA-1][(none)]> select @@global.group_replication_group_name;+---------------------------------------+| @@global.group_replication_group_name |+---------------------------------------+| f195537d-19ac-11eb-b29f-5254002eb6d6  |+---------------------------------------+

用同样的办法，再部署MGR B，并确认工作失常：

[root@GreatSQL mgrB-1][(none)]> select * from performance_schema.replication_group_members;+---------------------------+--------------------------------------+-------------+-------------+--------------+-------------+----------------+| CHANNEL_NAME              | MEMBER_ID                            | MEMBER_HOST | MEMBER_PORT | MEMBER_STATE | MEMBER_ROLE | MEMBER_VERSION |+---------------------------+--------------------------------------+-------------+-------------+--------------+-------------+----------------+| group_replication_applier | 31f7accc-96ac-11eb-92f8-525400e802e2 |    mgrB-1   |        4306 | ONLINE       | PRIMARY     | 8.0.22         || group_replication_applier | b084f8a1-96a8-11eb-9a70-525400fb993a |    mgrB-2   |        4306 | ONLINE       | SECONDARY   | 8.0.22         || group_replication_applier | ed57ca6b-96a9-11eb-be28-525400e2078a |    mgrB-3   |        4306 | ONLINE       | SECONDARY   | 8.0.22         |+---------------------------+--------------------------------------+-------------+-------------+--------------+-------------+----------------+[root@GreatSQL mgrB-1][(none)]> select @@global.group_replication_group_name;+---------------------------------------+| @@global.group_replication_group_name |+---------------------------------------+| 476c0276-be03-11eb-bd34-525400e802e2  |+---------------------------------------+

确认上述2个MGR集群以及各个节点的 server_uuid 都不一样。

3. 部署MGR A、B之间的复制通道

从MySQL 5.7开始，反对多源复制（Multi-Source Replication），因而咱们能够很不便的利用多源复制，在两个MGR集群之间再构建一个复制通道。

这个复制通道，既能够抉择 异步复制（Asynchronous Replication），也能够抉择 半同步复制（Semisynchronous Replication），能够依据两个MGR集群之间的网络情况，以及理论业务须要评估决定。

本案抉择半同步复制计划，这仅限于试验目标，不示意咱们举荐大家也采纳半同步计划。

相应地，上面也是一份半同步的参考配置，大家可依据理论状况适当调整：

rpl_semi_sync_master_timeout=2592000000rpl_semi_sync_master_wait_for_slave_count=1rpl_semi_sync_master_wait_point=AFTER_SYNC

在MGR B的Pirmary节点上创立半同步复制通道（记得设置通道名）：

[root@GreatSQL mgrB-1][(none)]> CHANGE MASTER TOMASTER_HOST='172.16.16.10', MASTER_PORT=3306, MASTER_USER='repl', MASTER_PASSWORD='repl',MASTER_AUTO_POSITION=1FOR CHANNEL 'mgrA-to-mgrB-semisync' ;

确认半同步复制失效：

[root@GreatSQL mgrB-1][(none)]> SHOW REPLICA STATUS\G             Replica_IO_State: Queueing master event to the relay log                  Source_Host: 172.16.16.10                  Source_User: repl                  Source_Port: 3306...           Replica_IO_Running: Yes          Replica_SQL_Running: Yes...                  Source_UUID: 5499a6cb-91cb-11eb-966f-525400e802e2...    Replica_SQL_Running_State: waiting for handler commit...           Retrieved_Gtid_Set: f195537d-19ac-11eb-b29f-5254002eb6d6:17-36885051:36885053:36885057:36885059:36885064:36885067            Executed_Gtid_Set: 476c0276-be03-11eb-bd34-525400e802e2:1-5,f195537d-19ac-11eb-b29f-5254002eb6d6:1-36884719:36884727:36884729-36884732:36884734-36884737                Auto_Position: 1         Replicate_Rewrite_DB:                 Channel_Name: mgrA-to-mgrB-semisync...

P.S，下面的信息是曾经运行一段时间后截取进去的，所以GTID的值看起来比拟大。

也能够用相似的办法构建传统的异步复制通道，以及双向复制通道，都是能够的。

4. 几个注意事项

  • 两个MGR集群各节点的 server_uuid 确保不反复。
  • 两个MGR集群的名字（group_replication_group_name）确保不反复。
  • 构建完复制通道后，MGR B里的Primary节点最好也要设置为只读（super_read_only=1），防止误操作写入数据。
  • 两个MGR集群之间也要定期校验数据一致性，不论是异步复制还是（加强）半同步复制，乃至MGR都还存在多个丢数据的BUG，不能盲目乐观置信用了增强版同步/MGR就能保证数据一致性了。

本文先介绍基于多数据中心、多套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 公布！