mgr不能直接迁移主从，因其基于paxos共识而非binlog回放，需全新部署并满足innodb、主键、gtid等硬性约束，否则触发recovering状态或启动失败。
直接迁移不可行，必须停写窗口或做双向同步过渡。MGR不是主从的“升级开关”，而是全新复制范式，硬切会导致数据不一致甚至集群启动失败。
为什么不能直接把主从改配置就加入MGR
主从复制和MGR底层机制完全不同：主从靠SQL线程回放binlog事件，MGR靠Paxos协议在节点间达成事务写集共识。强行复用旧datadir、未重置GTID、忽略事务隔离要求，会触发以下典型错误：
-
ERROR 3092 (HY000)：节点状态卡在RECOVERING，实际是GTID冲突或写集校验失败 -
Group replication requires GTID_MODE = ON：但旧主从可能关着GTID，或开启方式不兼容（如只设gtid_mode=ON没配enforce_gtid_consistency=ON） -
Plugin 'group_replication' is not active：插件加载失败，常见于MySQL版本＜8.0.19，或plugin_load_add=group_replication.so路径不对
关键区别在于：主从允许MyISAM表、无主键表、非事务混合更新；MGR强制要求所有表为InnoDB、每张表有主键或唯一索引、禁用CREATE TABLE ... SELECT等非原子操作。
在线迁移必须走双向同步过渡路径
所谓“在线”，本质是用中间态掩盖切换过程——老主从继续提供写服务，新MGR集群通过双向复制实时同步，直到数据追平再切流。这不是配置变更，而是架构并行运行。
- 先在新节点部署干净的MySQL 8.0.19+实例，初始化空
datadir，禁用super_read_only - 用
mysqldump --set-gtid-purged=OFF导出老主库全量，导入前执行SET SQL_LOG_BIN = 0，导入后RESET MASTER并设置gtid_purged - 搭建老主→新MGR单向复制（基于GTID），同时反向建新MGR→老主的复制通道（需业务层控制写入路由，避免环路）
- 读流量先切到新MGR，验证查询一致性；写流量切前必须确认双向延迟为0，且
SELECT @@GLOBAL.GTID_EXECUTED两集群完全一致
最容易被忽略的三个初始化细节
MGR节点启动后进不了ONLINE状态，90%问题出在这三处，而非网络或权限：
-
transaction_write_set_extraction必须设为XXHASH64（MySQL 8.0默认），5.7需显式指定，否则写集为空导致无法共识 - 所有节点
server_id必须全局唯一，且不能与老主从集群重复——MGR内部用它标识节点，冲突会导致心跳丢失 -
group_replication_group_name必须是合法UUID格式（如aabbccdd-eeff-1122-3344-5566778899aa），不能用主机名或数字字符串，否则插件加载报错MY-011582
配置项必须用SET PERSIST写入mysqld-auto.cnf，仅SET GLOBAL在重启后失效——这是手动部署时最常漏掉的操作。
切流后必须验证的三项状态
写流量切到MGR后，不能只看SELECT * FROM performance_schema.replication_group_members全是ONLINE就认为成功：
- 查
SELECT MEMBER_ROLE, MEMBER_STATE FROM performance_schema.replication_group_members，确认主节点角色是PRIMARY而非SECONDARY - 执行
INSERT后立刻在其他节点SELECT，验证强一致性——MGR默认单主模式下，非主节点写会报错ERROR 1290 (HY000)，这是正常行为 - 模拟主节点宕机（
kill -9 mysqld），观察SECONDARY节点是否在10秒内自动升主，并检查SHOW MASTER STATUS的File和Position是否连续
真正的难点不在启动集群，而在让业务接受MGR的约束：比如自增列不再绝对连续、DDL需在主节点执行、临时表不能跨事务使用——这些不是配置能绕过的，必须代码层适配。
