必须重启mysql才能开启gtid，不存在“在线开启”方案；若gtid_mode仍为off，所有后续复制配置都无效。
必须重启 MySQL 才能开启 GTID，不存在“在线开启”方案；若 gtid_mode 仍为 OFF，所有后续复制配置都无效。
确认 GTID 基础条件是否满足
GTID 不是开关一按就生效的功能，它依赖一组强约束参数。先执行以下三句检查：
SELECT VERSION();<br>SHOW VARIABLES LIKE 'gtid_mode';<br>SHOW VARIABLES LIKE 'enforce_gtid_consistency';
必须同时满足：
-
gtid_mode为ON（不是OFF_PERMISSIVE或ON_PERMISSIVE） -
enforce_gtid_consistency为ON -
binlog_format为ROW（用SHOW VARIABLES LIKE 'binlog_format';验证） -
log_bin为ON（否则无法生成事务日志）
任一不满足，CHANGE MASTER TO ... MASTER_AUTO_POSITION = 1 会直接报错 ERROR 1777 (HY000)，且无法跳过。
主从两端 my.cnf 必须统一写死的参数
MySQL 8.0 不支持动态启用 GTID，所有配置必须写入 [mysqld] 段并重启。主库和从库都要配，且不能只配一边：
-
server_id：全局唯一整数，主库设1，从库设2等，重复会导致复制中断 -
log_bin = mysql-bin：必须开启 binlog，名字可自定义，但路径需有写权限 -
binlog_format = ROW：漏写或写成MIXED会导致 GTID 启用失败 -
gtid_mode = ON：核心开关，仅设此值不够，必须配合下一条 -
enforce_gtid_consistency = ON：禁止不安全语句（如CREATE TABLE ... SELECT），否则复制可能出错 -
log_slave_updates = ON：从库也要写 binlog，否则级联复制或故障切换后无法继续
改完配置后必须执行 systemctl restart mysqld（或对应启动方式），ps aux | grep mysql 确认进程已重启。
初始化 GTID 复制时的关键操作顺序
已有数据的环境不能直接 START SLAVE，否则 GTID 位点错乱、同步中断。正确流程是：
- 主库上用
mysqldump --all-databases --single-transaction --set-gtid-purged=ON导出（=ON是关键，会自动注入SET @@GLOBAL.GTID_PURGED） - 从库导入前先执行
RESET SLAVE ALL;（清空旧 relay log 和 master info） - 导入 SQL 后，立即执行
SET GLOBAL GTID_PURGED = 'xxx-xxx-xxx:1-1000';（值来自 dump 文件头部，或主库SHOW MASTER STATUS的Executed_Gtid_Set） - 再执行
CHANGE MASTER TO MASTER_HOST='x.x.x.x', MASTER_USER='repl', MASTER_PASSWORD='xxx', MASTER_AUTO_POSITION = 1; - 最后
START SLAVE;，检查SHOW SLAVE STATUS\G中Retrieved_Gtid_Set和Executed_Gtid_Set是否持续增长且一致
若跳过 GTID_PURGED 设置，从库会尝试重放全部历史事务，导致主键冲突或重复插入。
容易被忽略的兼容性与行为细节
GTID 开启后，很多习以为常的操作会受限或失效：
-
CHANGE MASTER TO MASTER_LOG_FILE/MASTER_LOG_POS在 GTID 模式下被禁止，必须用MASTER_AUTO_POSITION = 1 -
FLUSH LOGS会强制滚动 binlog，但不会重置 GTID 计数器，server_uuid存在auto.cnf中，不可手动修改，否则 GTID 体系崩溃 - 从库
read_only = 1不能阻止 super 用户写入，如需真正只读，必须加super_read_only = 1（且该参数也需写入配置文件，否则重启失效） - MySQL 8.0.22+ 才完整支持
STOP REPLICA（旧版是STOP SLAVE），语法不兼容会导致脚本失败
GTID 的本质是让复制“自动找位置”，但它不解决数据一致性校验、大事务阻塞、网络分区等问题——这些得靠监控、限流和人工干预。
