乐趣区

关于mysql:MySQL金融应用场景下跨数据中心的MGR架构方案1

jiezi
  • 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=ON
log_error_verbosity=3
group_replication_bootstrap_group=OFF 
group_replication_transaction_size_limit=< 默认值 150MB，但倡议调低在 20MB 以内，不要应用大事务 >
group_replication_communication_max_message_size=10M
group_replication_flow_control_mode=“DISABLED”#官网版本的流控机制不太正当，其实能够思考敞开
group_replication_exit_state_action=READ_ONLY
group_replication_member_expel_timeout=5 #如果网络环境不好，能够适当调高

slave_parallel_type=LOGICAL_CLOCK
slave_parallel_workers=128 #能够设置为逻辑 CPU 数量的 2 - 4 倍
binlog_transaction_dependency_tracking=writeset
transaction_write_set_extraction=XXHASH64
slave_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=2592000000
rpl_semi_sync_master_wait_for_slave_count=1
rpl_semi_sync_master_wait_point=AFTER_SYNC

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

[root@GreatSQL mgrB-1][(none)]> CHANGE MASTER TO
MASTER_HOST='172.16.16.10', MASTER_PORT=3306, 
MASTER_USER='repl', MASTER_PASSWORD='repl',
MASTER_AUTO_POSITION=1
FOR 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 公布！

退出移动版