GTID主从复制必须主从两端同时开启gtid_mode=ON、enforce_gtid_consistency=ON、log_slave_updates=ON且server_uuid唯一，否则START SLAVE必然失败；配置须写入my.cnf[mysqld]段并重启生效，仅SET GLOBAL不持久。
GTID主从复制不能直接在已运行的旧实例上“开启就生效”，必须主从两端同时满足配置、状态、数据三重一致性，否则START SLAVE会报错或静默跳过事务。
为什么CHANGE MASTER TO ... MASTER_AUTO_POSITION = 1会失败
这个命令失败通常不是语法问题，而是底层GTID集合不匹配。从库启动复制前会对比自己的gtid_executed和主库的gtid_purged：如果从库已执行的GTID不在主库的已清理集合里，就无法自动定位起点。
- 先在从库查：
SELECT @@global.gtid_executed; - 再连主库查：
SELECT @@global.gtid_purged; - 若前者包含后者没有的GTID（比如从库之前自己写过数据），
MASTER_AUTO_POSITION=1必然拒绝启动 - 此时不能删
gtid_executed硬清空——会导致数据丢失；正确做法是用mysqldump --set-gtid-purged=ON重新导出，并在从库RESET MASTER后再导入
gtid_mode必须分步切换，不能直接SET GLOBAL gtid_mode = ON
MySQL强制要求GTID启用过程必须经过过渡态，否则会报错ERROR 1789 (HY000): Cannot change gtid_mode while @@global.gtid_mode is OFF。
- 先设为
OFF_PERMISSIVE：允许新事务匿名，但复制可接受GTID - 再设为
ON_PERMISSIVE：新事务带GTID，复制仍兼容匿名事务 - 最后设为
ON：彻底禁用匿名事务 - 每一步后都需确认
SHOW VARIABLES LIKE 'gtid_mode';已生效，且SELECT * FROM performance_schema.replication_applier_status_by_coordinator;无错误
从库read_only = ON不是可选项，而是GTID安全底线
GTID复制依赖gtid_executed集合的严格单调递增。一旦从库被手动写入（比如误执行INSERT），就会产生本地GTID，破坏与主库的GTID序列连续性，后续START SLAVE可能跳过本该执行的事务，导致数据不一致。
- 必须在从库配置中显式设置
read_only = ON，且不能仅靠账号权限控制 - 例外情况只有
SUPER用户能绕过，所以生产环境应收回所有账号的SUPER权限 - 验证是否生效：
SELECT @@global.read_only;返回ON，且尝试CREATE TABLE test.t1(id INT);应报错ERROR 1290 (HY000): The MySQL server is running with the --read-only option
真正容易被忽略的是server_uuid冲突——它藏在data/auto.cnf里，重启不改变。两台机器若用相同镜像克隆而来，server_uuid极大概率重复，会导致从库拒绝接收主库的GTID事务，错误日志里只显示模糊的Could not execute Write_rows event on table，不会直接指出UUID问题。
