金融应用场景下跨数据中心的MGR架构方案——上篇
0. 内容提纲
- 1. 运行环境
- 2. 部署MGR A&B
- 3. 部署MGR A、B之间的复制通道
- 4. 几个注意事项
如何在多个数据中心部署多套MySQL MGR集群以便快速切换。
在金融应用场景下，经常会要求在同城多中心部署高可用数据库架构，以期实现在发生故障时能达到快速切换的目标。
在同一个数据中心内，可以部署MGR集群，就可以实现快速灵活切换。
而即便是在同城，跨数据中心时，网络条件好的话，延迟可能也在 1ms 之内。这种网络条件下，如果要在同城多中心部署MGR集群也是可以尝试的（如果业务并发量不是特别高的话），但考虑到多数据中心间有较大概率会出现光缆被挖断等风险，所以还是不建议这么做。
因此，最好还是在同一个数据中心内部署一套独立的MGR集群，再通过主从复制（replication）方式（可以是异步复制或半同步复制），把数据复制一份到另一个数据中心内的MGR集群里，这样一旦主机房出现异常时，就可以快速切换到备用机房了，并且不担心数据库的高可用保障等级。
上面该方案的架构示意图。
接下来一起来完成这个架构方案的实施。
1. 运行环境
本次采用3个节点部署这套架构，各节点用途说明见下
| 节点 | IP | 用途 |
|---|---|---|
| Node1 | 172.16.16.10 | MGR A & B 主节点（分配不同端口，多实例方式，下同） |
| Node2 | 172.16.16.11 | MGR A & B 从节点 |
| Node3 | 172.16.16.12 | MGR A & B 从节点 |
每个节点上都运行两个实例，分别是3306、4306端口，其中3306端口的实例构成MGR A集群，4306端口的实例构成MGR B集群。
除了MySQL官方社区版本外，如果想体验更可靠、稳定、高效的MGR，推荐使用GreatSQL版本。本文采用GreatSQL 8.0.22版本，关于这个版本的说明详见 GreatSQL，打造更好的MGR生态。
2. 部署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
