mysql 5.7.6+在线开启gtid必须严格按off→off_permissive→on_permissive→on四步单步切换，跳步即报error 1788；主从须同步执行每步，且enforce_gtid_consistency需先warn观察日志无警告再设on；所有节点my.cnf必须持久化配置gtid-mode=on等参数，否则重启退化致隐性数据不同步。
不能跳步，不能漏节点，不能重启后不写配置文件——否则必然触发 ERROR 1788 或复制中断，且故障现象隐蔽（SHOW SLAVE STATUS 看不出异常，但数据已不同步）。
为什么直接 SET GLOBAL gtid_mode = ON 会报错
MySQL 5.7.6+ 强制要求 gtid_mode 必须单步切换：OFF → OFF_PERMISSIVE → ON_PERMISSIVE → ON。跳步（比如从 OFF 直接到 ON_PERMISSIVE）会立刻报 ERROR 1788，且该错误不区分主从，所有节点必须同步执行同一步骤。
每步之间有隐含状态依赖：
-
OFF_PERMISSIVE：新事务仍是匿名的，但从库开始能同时处理匿名和 GTID 事务 -
ON_PERMISSIVE：新事务开始用 GTID，但从库仍兼容两种事务——此时必须等ONGOING_ANONYMOUS_TRANSACTION_COUNT为 0，否则后续切到ON会卡住
enforce_gtid_consistency 必须分两阶段设
直接 SET @@GLOBAL.enforce_gtid_consistency = ON 会让 CREATE TABLE SELECT、非事务引擎操作等语句立即失败，业务写入中断。正确做法是：
- 先全量执行
SET @@GLOBAL.enforce_gtid_consistency = WARN - 持续观察错误日志（如
/data/mysql/error.log），搜索Statement violates GTID consistency、ERROR 1786、ERROR 1787 - 确认无相关报错（建议观察至少 24 小时，覆盖完整业务周期）后，再统一执行
SET @@GLOBAL.enforce_gtid_consistency = ON
从库执行 CHANGE MASTER TO 的时机和写法
必须等主从都完成 gtid_mode = ON 后，才轮到从库操作。顺序错或参数错会导致 IO 线程无法启动：
- 先
STOP SLAVE - 再
CHANGE MASTER TO MASTER_AUTO_POSITION = 1（注意不是MASTER_LOG_FILE+MASTER_LOG_POS） - 最后
START SLAVE
验证是否生效：SHOW SLAVE STATUS\G 中 Auto_Position 显示 1，且 Retrieved_Gtid_Set 和 Executed_Gtid_Set 非空并逐步收敛。
my.cnf 配置遗漏是最容易被忽略的致命点
SET @@GLOBAL.xxx 命令只在当前运行期生效，MySQL 重启后全部还原。一旦忘记补配置，重启即退回到传统复制，但 SHOW SLAVE STATUS 里 IO_Running 和 SQL_Running 仍显示 Yes，Seconds_Behind_Master 可能缓慢增长，极难定位。
必须在所有节点的 my.cnf 中追加：
[mysqld] gtid-mode = ON enforce-gtid-consistency = ON log-slave-updates = 1 binlog_format = ROW
其中 log-slave-updates 是级联复制必备项；binlog_format = ROW 虽非 GTID 强制要求，但可避免 SQL 模式下函数、临时表等引发的不一致风险。
