不能直接将单机MySQL升级为MGR集群，因MGR要求所有节点GTID集合一致、binlog位置可追溯，而mysqldump无GTID上下文，XtraBackup恢复后server_uuid冲突且默认未启用GTID，需手动设置gtid_purged、确保各节点server_uuid唯一、仅首节点临时启用group_replication_bootstrap_group，并通过MySQL Router实现读写分离与平滑写入切换。
不能直接把单机MySQL“升级”成MGR集群，必须重建复制关系、重配网络与权限、并控制写入切换时机。平滑迁移的核心不是数据搬移，而是让新集群在业务无感前提下接管写流量。
为什么不能用mysqldump或Percona XtraBackup直接导入后启动MGR
MGR要求所有节点初始状态必须满足两个硬性前提：一是事务日志（binlog）位置必须对齐且可追溯；二是组内所有节点的GTID集合必须一致或可推导。而mysqldump导出的是逻辑快照，不带GTID上下文；Percona XtraBackup虽能保留binlog位置，但恢复后的实例默认未启用GTID，且server_uuid与原单机冲突，会导致后续加入组时被拒绝。
- 执行
CHANGE MASTER TO前必须确保源库已开启gtid_mode=ON、enforce_gtid_consistency=ON，且所有历史binlog未被purge - 备份恢复后需手动执行
SET GLOBAL gtid_purged = 'xxx'，值来自备份时记录的SHOW MASTER STATUS输出 - 每个MGR节点的
server_uuid必须全局唯一，不能复用单机旧值，否则组通信会失败
group_replication_bootstrap_group只允许在第一个节点上设为ON
这是MGR集群初始化的“点火开关”，一旦误操作在多个节点同时启用，会触发脑裂：各自形成孤立组，后续无法合并，只能清空数据重来。
- 仅在首个节点启动前临时设置
group_replication_bootstrap_group=ON，启动成功后立即设为OFF - 其他节点加入时，必须使用
START GROUP_REPLICATION，而非再次设bootstrap - 若第一个节点异常退出，重启时不能再设
bootstrap=ON，否则会创建新组，与原组数据不兼容
单主模式下如何安全切换写入流量
切换不是改DNS或IP那么简单。MGR单主模式中，只有PRIMARY节点接受写入，其余节点自动super_read_only=ON。如果应用直连IP，在切换瞬间可能因连接到只读节点而报错ERROR 1290 (HY000): The MySQL server is running with the --super-read-only option so it cannot execute this statement。
- 必须通过
MySQL Router或ProxySQL做读写分离路由，它能自动识别PRIMARY节点并转发写请求 - 切换前先在应用侧停写（如关闭定时任务、切走API入口），确认
show global status like 'Com_commit'归零 - 检查所有从节点
performance_schema.replication_group_members状态为ONLINE，且MEMBER_ROLE='PRIMARY'已稳定 - 切完后立刻验证：在新PRIMARY执行
INSERT，再从任意SECONDARY查，确认同步延迟为0
最容易被忽略的是时区和SQL mode一致性——单机环境常忽略time_zone配置，而MGR组内各节点time_zone不一致会导致基于时间的函数（如NOW()）在不同节点返回不同值，引发复制中断；同样，sql_mode差异会让同一条SQL在一个节点成功、另一个节点报错，直接卡住事务流。
