GTID复制要求主从两端必须同时开启gtid_mode=ON且enforce_gtid_consistency=ON，否则START SLAVE必然失败；ERROR 1777是协议级拒绝，非语法错误；log_slave_updates=ON为强制要求，所有参数须写入[mysqld]段并重启生效。
gtid_mode=ON 不是“推荐开启”，而是主从两端必须同时开启，否则 START SLAVE 必然失败。这不是兼容性问题，是协议级拒绝。
START SLAVE 报错 ERROR 1777 的根本原因
MySQL 5.7 的 GTID 复制不是单边开关。只要主库 gtid_mode=ON，而从库是 OFF 或 OFF_PERMISSIVE，执行 CHANGE MASTER TO MASTER_AUTO_POSITION = 1 就会立刻报错：
ERROR 1777 (HY000): CHANGE MASTER TO requires MASTER_AUTO_POSITION = 1 when gtid_mode = ON
- 这不是语法错误，是复制协议在握手阶段就校验失败
- 主库发现从库不支持 GTID 协商，直接中止连接初始化
- 即使你绕开
MASTER_AUTO_POSITION=1，改用传统MASTER_LOG_FILE/MASTER_LOG_POS，后续START SLAVE仍会因 GTID 状态不匹配卡住
enforce_gtid_consistency=ON 是硬性前提，不是可选项
gtid_mode=ON 和 enforce_gtid_consistency=ON 是两个独立变量，但后者是前者的启动闸门：
- 没配
enforce_gtid_consistency=ON，mysqld 启动时会直接拒绝启用 GTID，报错：ERROR 1782 (HY000): You must set enforce_gtid_consistency=ON before enabling GTID mode - 即使忽略报错强行启动，
SHOW VARIABLES LIKE 'gtid_mode'显示为ON，实际复制线程无法初始化，日志里只看到模糊提示：[Warning] Neither --relay-log nor --relay-log-index were used - 该参数必须主从两端都设为
ON，且写入配置文件的[mysqld]段，SET GLOBAL不持久
从库 gtid_executed 为空或不匹配，START SLAVE 会卡死
从库如果之前用传统方式启过复制，即使已改配置，gtid_executed 和 gtid_purged 往往残留旧状态：
- 执行
SELECT @@global.gtid_executed, @@global.gtid_purged;，若返回空或包含主库没有的server_uuid，START SLAVE会卡在 relay log 初始化阶段，报错类似：Slave failed to initialize relay log info structure - 正确做法是：先
RESET SLAVE ALL（注意不是RESET SLAVE，后者不清gtid_purged），再导入带SET @@GLOBAL.GTID_PURGED=...的 dump - 导入 dump 前必须确认从库没执行过任何事务，否则
gtid_executed与 dump 中的GTID_PURGED冲突，START SLAVE必报ERROR 3021
log_slave_updates=ON 在 GTID 下不是可选，是强制要求
传统复制中从库可以关闭 binlog，但 GTID 模式下：
- 从库必须开启
log_slave_updates=ON，否则无法生成自己的 GTID 集 - 后续无法被提升为主库，也无法作为中间节点向下游转发事务
- 即使当前只是末端从库，也得开——因为 GTID 协议依赖每个节点维护完整的
gtid_executed集合
最常被忽略的一点：所有这些参数（gtid_mode、enforce_gtid_consistency、log_slave_updates）都必须写进 [mysqld] 段，重启生效；SET GLOBAL 或写在 [client] 段完全无效。
