如何将MySQL 5.7通过异步复制平滑过渡至MGR架构实现同步改写？

本文共计1176个文字，预计阅读时间需要5分钟。

MySQL 5.7 到 MGR 的在线平滑迁移，不能直接切过去，必须使用异步复制作为中间过渡——因为 MGR 需要所有节点开启 GTID、binlog_format=ROW、enforce_gtid_consistency=ON 等强约束，而 5.7 主从迁移往往不足以满足这些要求；强行初始化 MGR 可能导致数据不一致或启动失败。

为什么必须先建异步复制链路而不是直连MGR

MGR 集群节点加入前，必须与源主库保持事务级一致，但源主库若未启用 GTID，或存在 CREATE TABLE ... SELECT、非事务表混用等不安全语句，MGR 的 group_replication_start_on_boot=ON 会拒绝启动。异步复制（传统 binlog relay）是唯一能兼容旧配置、同时承载全量+增量数据的兜底通道。

• 异步复制允许你保留原主库配置不动，只在新节点上启用必要参数
• 你可以先拉起一个 5.7 实例作为“中继节点”，开启 GTID_MODE=ON 和 ENFORCE_GTID_CONSISTENCY=ON，再把它作为 MGR 成员加入
• 过程中业务无感知：读流量可逐步切到该中继节点，写仍走原主库
• 关键限制：server_id 必须全局唯一，且不能与原集群任何节点重复

如何配置中继节点并开启GTID（5.7.6+必需步骤）

中继节点不是简单加个从库，它要承担“协议转换”角色：把原主库的非 GTID 流量转换为 GTID 模式，供后续 MGR 使用。这要求你在中继节点上执行严格初始化。

• 停掉中继节点的 MySQL，清空 datadir，确保无残留 auto.cnf
• 配置文件中强制设置：gtid_mode=ON、enforce_gtid_consistency=ON、binlog_format=ROW
• 首次启动后，执行：RESET MASTER（清空本地 binlog，避免 GTID 冲突）
• 再执行：CHANGE MASTER TO MASTER_HOST='原主库IP', MASTER_USER='repl', MASTER_PASSWORD='xxx', MASTER_AUTO_POSITION=0（注意：此时用 MASTER_AUTO_POSITION=0，因原主库无 GTID）
• 启动复制：START SLAVE，确认 Seconds_Behind_Master 归零后再继续下一步

向MGR集群添加节点时最常踩的坑

中继节点数据追平后，你以为可以 START GROUP_REPLICATION 就完事？实际 80% 失败都发生在这一步。

• group_replication_group_name 必须是合法 UUID 格式（如 aaaaaaaa-bbbb-cccc-dddd-eeeeeeeeeeee），不能是字符串或空值
• group_replication_local_address 必须绑定真实网卡 IP，不能写 127.0.0.1 或 localhost；多网卡环境要确认防火墙放行对应端口（默认 33061）
• 如果原主库用了 lower_case_table_names=1，中继节点也必须一致，否则 MGR 启动时校验表名大小写会失败
• group_replication_bootstrap_group=ON 只能在第一个节点执行一次，后续节点必须设为 OFF，否则形成多个独立组
• 执行 START GROUP_REPLICATION 后，立刻查 SELECT * FROM performance_schema.replication_group_members，状态为 OFFLINE 表示网络或参数问题，RECOVERING 才是正常同步中

写流量切换前必须验证的三件事

别急着改 DNS 或应用连接串。MGR 集群稳定运行至少 2 小时后，还要人工确认：

• 所有节点的 SELECT @@gtid_executed 输出是否完全一致？不一致说明有事务丢失或跳过
• 在任意 MGR 节点执行 INSERT INTO test_tbl VALUES (1)，检查其他节点是否秒级可见（验证多主写入通路）
• 模拟主节点宕机：kill -9 当前 PRIMARY 节点进程，观察 performance_schema.replication_group_members 中 MEMBER_ROLE 是否自动重选，且新 PRIMARY 能正常接受写入

真正难的不是启动 MGR，而是让它的数据视图和原主库在任意时刻都对得上——尤其当原主库还在持续写入时，中继节点的延迟抖动、网络分区、GTID gap 都可能在切换瞬间放大成数据错乱。建议在业务低峰期做最终切流，并预留回滚到原主从链路的快速路径（比如提前备份好中继节点的 mysqldump --set-gtid-purged=OFF 全量）。