mysql单机迁集群须先校验版本兼容性（如mgr要求≥8.0.19）、启用row格式binlog、转myisam为innodb、禁用只读模式；导出需--set-gtid-purged=off，导入前停binlog并重置gtid；新节点须清空datadir后初始化再导入数据，最后通过mysql shell加入集群。
确认单机 MySQL 版本与 MGR 兼容性
MySQL 单机实例必须 ≥ 8.0.19（MGR 官方最低要求），低于该版本无法启用 group_replication 插件。执行 SELECT VERSION(); 查看精确版本号，注意小版本差异——例如 8.0.33 和 8.0.37 在某些集群初始化场景下行为不同。若为 5.7 系统，需先升级至 5.7.25+ 并运行 mysql_upgrade；若为 5.6 或更早，不能直连 MGR，必须先跨版本升级。
导出数据时必须禁用 GTID 冲突
直接 mysqldump --all-databases 会把原库的 GTID_PURGED 写入 dump 文件，导入到已有 GTID 集合的集群节点时会报错：GTID_PURGED can only be set when GTID_EXECUTED is empty。解决方法只有一条：导出时强制跳过 GTID 相关语句。
- 使用
--set-gtid-purged=OFF参数，例如：mysqldump -u root -p --all-databases --set-gtid-purged=OFF > full_backup.sql - 若含
AUTO_INCREMENT表，导入后建议手动重设偏移：ALTER TABLE t AUTO_INCREMENT = 10000;（N 取原库最大 ID + 1000，避免多主写入冲突） - 大表慎用
--single-transaction：在复制延迟场景下可能读到不一致快照；窗口可控时改用--lock-all-tables
新节点必须清空 datadir 后重新初始化
MGR 节点不是“把单机 mysqld 改配置就能加入”，而是全新实例。常见错误是直接复用旧 datadir，导致 group_replication 启动失败或状态卡在 RECOVERING。
- 停掉目标节点 MySQL，备份并清空
/var/lib/mysql（或你配置的datadir） - 用同版本 MySQL 初始化：
mysqld --initialize-insecure --datadir=/var/lib/mysql - 启动干净实例后，导入前务必执行：
SET SQL_LOG_BIN = 0;，再source full_backup.sql - 导入完成后执行：
RESET MASTER;清空本地 binlog，并设置SET GLOBAL gtid_purged = 'xxx';（值取自 dump 文件头的SET @@GLOBAL.GTID_PURGED行，或原库SELECT @@GLOBAL.GTID_EXECUTED;）
加入集群前检查关键参数与权限
节点能启动不代表能加入 MGR。最常被忽略的是网络连通性、复制账户权限和 binlog 格式。
- 确认
binlog_format = ROW且log_bin = ON（SHOW VARIABLES LIKE 'log_bin';和SHOW VARIABLES LIKE 'binlog_format';） - 确保所有节点已创建复制用户并授权：
CREATE USER 'repl'@'%' IDENTIFIED BY 'xxx'; GRANT REPLICATION SLAVE ON *.* TO 'repl'@'%'; - 检查节点间 3306（SQL）、33061（MGR XCom）端口互通：
telnet 192.168.1.12 33061，防火墙或 SELinux 可能拦截 33061 - MyISAM 表必须转为 InnoDB：
ALTER TABLE t ENGINE=InnoDB;，MGR 不支持 MyISAM
真正容易卡住的地方不是加节点命令本身，而是节点初始化后未重置 GTID、未关闭 SQL_LOG_BIN 就导入数据、或复制用户没开 REPLICATION SLAVE 权限——这三个点占了实际迁移中 70% 以上的失败原因。
