直接用 mysqldump + --set-gtid-purged=OFF 导出再导入可跳过 GTID 位点校验，避免从库启动复制时报错；因 --master-data=2 默认写入 SET @@GLOBAL.GTID_PURGED 语句，而新从库 gtid_executed 为空，MySQL 不允许在 gtid_mode=ON 时向空 gtid_purged 写入非空值，导致导入失败。
直接用 mysqldump + --set-gtid-purged=OFF 导出再导入，就能跳过 GTID 位点校验，避免从库启动复制时报 GTID_PURGED cannot be changed 或 cannot change gtid_purged when gtid_mode is ON 错误。
为什么不能用 --master-data=2 直接导出？
因为 --master-data=2 默认会写入 SET @@GLOBAL.GTID_PURGED 语句，而新从库尚未执行过任何事务，gtid_executed 为空，MySQL 不允许在 gtid_mode=ON 时向空的 gtid_purged 写入非空值——这会导致导入失败或复制无法启动。
-
--set-gtid-purged=OFF会禁用该语句生成，只保留CREATE DATABASE和表结构/数据 - 配合
--single-transaction可保证一致性快照，适合 InnoDB - 如果主库有 MyISAM 表，需额外加
--lock-all-tables，否则可能不一致
从库导入后必须手动设置 GTID_PURGED 吗？
不需要。只要主库导出时没写 GTID_PURGED，且从库是全新实例（mysql.gtid_executed 表为空），导入后直接执行 CHANGE MASTER TO ... FOR CHANNEL 'group_replication_recovery' 或普通复制通道即可——MySQL 会自动将导入的事务纳入本地 gtid_executed，后续复制从 Executed_Gtid_Set 的最新位置继续。
- 验证方式：
SELECT * FROM mysql.gtid_executed;应显示导入事务对应的 GTID 范围 - 若看到
GTID_SET为空，说明导入未被识别为 GTID 事务，检查是否漏了--single-transaction或用了不兼容语句（如CREATE TABLE SELECT） - 严禁在从库执行
RESET MASTER——这会清空gtid_executed，导致后续复制找不到起点
CHANGE MASTER TO 时要不要指定 MASTER_AUTO_POSITION = 1？
要，而且必须设为 1。这是 GTID 复制的核心开关，告诉从库“别管 binlog 文件名和 position，按 GTID 自动对齐”。设为 0 会导致复制线程拒绝启动，并报错 Master must be configured with --log-bin and --log-slave-updates（即使已配置也会报）。
- 完整命令示例：
CHANGE MASTER TO MASTER_HOST='192.168.1.10', MASTER_PORT=3306, MASTER_USER='repl', MASTER_PASSWORD='xxx', MASTER_AUTO_POSITION = 1 FOR CHANNEL ''; - 注意：主库必须开启
log_slave_updates=ON（从库也建议开），否则级联复制会断链 - 如果复制定向多个通道（如多源复制），每个
FOR CHANNEL 'xxx'都要单独设MASTER_AUTO_POSITION = 1
最容易被忽略的是：主库 server_uuid 必须唯一，且从库不能复用主库镜像的 auto.cnf——删掉它再重启，否则两个节点 UUID 相同，GTID 会冲突，复制看似运行实则跳过所有事务。
