确认当前 MySQL 单机版本与集群组件兼容性
迁移前必须核对
mysqld --version输出的版本号，尤其是小版本（如 8.0.33 vs 8.0.37），部分 MySQL Group Replication 或 InnoDB Cluster 要求最低版本为 8.0.19，而 Percona XtraDB Cluster 对 5.7 支持已逐步终止。若单机是 5.6 或更早，不能直连 MGR 或 PXC，需先升级到 5.7.25+ 或 8.0.19+ 并完成
mysql_upgrade。 运行
SELECT VERSION();和
SHOW VARIABLES LIKE 'log_bin';，确保 binlog 已启用且格式为
ROW检查是否使用 MyISAM 表：MGR 不支持，需提前转为 InnoDB：
ALTER TABLE t ENGINE=InnoDB;禁用
super_read_only=ON、
read_only=ON等限制，否则后续加入集群时节点无法写入
导出数据时避开 GTID 冲突和自增主键重复
直接
mysqldump全库导出会把原实例的
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 = <em>N</em>;手动设偏移（N 取原库最大 ID + 1000） 避免用
--single-transaction导出大表：某些集群复制延迟下，可能导致从节点读到不一致快照；改用
--lock-all-tables（停写窗口可控时）
在集群中初始化第一个节点并加载数据
以 MySQL InnoDB Cluster（基于 Group Replication）为例，不能把单机 mysqld 直接“升级”为集群节点，必须重装实例并清空 datadir。新节点启动后，再导入数据，最后才加入集群。
停止原单机 MySQL，备份/var/lib/mysql后清空该目录 用相同版本 MySQL 初始化：
mysqld --initialize-insecure --datadir=/var/lib/mysql，然后启动干净实例 导入前执行
SET SQL_LOG_BIN = 0;，再 source dump 文件，防止导入过程产生 binlog 干扰集群同步 导入完成后执行
RESET MASTER;清空本地 binlog，并设置
SET GLOBAL gtid_purged = 'xxx';（值来自 dump 文件头或原库
SELECT @@GLOBAL.GTID_EXECUTED;）
添加其余节点时注意复制账户和网络权限
集群节点间靠异步/半同步复制通信，但新节点加入时需能连接种子节点的 MySQL 端口（默认 3306），且账号必须有
REPLICATION SLAVE权限。常见错误是防火墙放行了应用端口却漏掉复制端口，或账号未授权
host='%'导致连接被拒。 在种子节点创建复制用户：
CREATE USER 'repl'@'%' IDENTIFIED BY 'pwd'; GRANT REPLICATION SLAVE ON *.* TO 'repl'@'%';确认所有节点
bind_address不是
127.0.0.1，应设为
0.0.0.0或具体内网 IP 加入集群命令（MySQL Shell）：
cluster.addInstance('repl@node2:3306');，若卡住超时，优先查 telnet node2 3306是否通，而非怀疑配置项
真正麻烦的是跨机房或云厂商 VPC 的 MTU 不一致，会导致 Group Replication 心跳包被截断，现象是节点反复 offline，日志里出现
Connection lost during packet read—— 这类问题不会在文档里强调，但实际迁移中高频发生。
