GTID复制需主从两端同时配置gtid_mode=ON和enforce_gtid_consistency=ON并重启，且导入数据必须使用mysqldump --set-gtid-purged=ON确保gtid_purged一致，否则START SLAVE必失败。

gtid_mode=ON 不等于 GTID 复制就跑起来了

直接写 gtid_mode = ON 到配置里重启，START SLAVE 依然会失败——这不是配置漏了，而是 GTID 复制根本没真正“激活”。gtid_mode 和 enforce_gtid_consistency 是两个独立开关，缺一不可。前者只是“允许用 GTID”，后者才是“强制所有事务合规”，没有后者，MySQL 会在内部拒绝初始化 GTID 复制流程，日志里只报模糊警告，比如 [Warning] Neither --relay-log nor --relay-log-index were used，容易误判为中继日志配置问题。

• enforce_gtid_consistency = ON 必须在主、从两端都设置，且同样写入 [mysqld] 段，重启生效
• gtid_mode = ON 不能只靠 SET GLOBAL 临时设置，它不持久；5.7.9+ 可用 SET PERSIST，但生产环境仍建议写死在配置文件
• gtid_mode = 1 或 gtid_mode = true 会被 mysqld 启动时静默忽略，只认 ON / OFF / OFF_PERMISSIVE 等合法值
• 配置若错写在 [client] 段或 [mysqld] 外的空白行，完全不生效

MASTER_AUTO_POSITION = 1 报 ERROR 1777 的真实原因

执行 CHANGE MASTER TO MASTER_AUTO_POSITION = 1 时抛出 ERROR 1777 (HY000): CHANGE MASTER TO requires MASTER_AUTO_POSITION = 1 when gtid_mode = ON，这不是语法错误，是协议级拒绝：主库 gtid_mode = ON，但从库还是 OFF（哪怕只是 OFF_PERMISSIVE），复制协议就不允许你用自动定位模式。MySQL 5.7 的 GTID 复制不是“主开就行”，必须主从两端严格一致。

• 必须在主、从上分别执行 SHOW VARIABLES LIKE 'gtid_mode'; 和 SHOW VARIABLES LIKE 'enforce_gtid_consistency';，不能只查一端
• 主从任意一端配置未重启，变量值仍是旧的，START SLAVE 会卡在 relay log 初始化阶段
• 如果从库之前用传统位置（MASTER_LOG_FILE/MASTER_LOG_POS）启动过，即使改了配置，gtid_executed 可能仍为空，需先确认状态再操作

从库 START SLAVE 卡住或报 Slave failed to initialize relay log info structure

常见于从库残留旧状态：比如之前没清空过数据、没重置过 GTID 集合，导致 gtid_purged 包含主库根本没有的 UUID，或者 gtid_executed 为空却直接 START SLAVE。这时复制线程根本没法对齐起点，直接失败。

win可用的mysql指令skill

安装、修复、更新或打包一个基于 Python 和 PyMySQL 实现的 Windows `mysql` 命令。适用于用户希望在 PowerShell/CMD 中输入 `mysql` 时重定向到 Python 实现、需要交互式输入 MySQL 连接信息、需要同步到当前用户本地 bin 目录，或需要将该能力封装成可公开复用的 Codex skill。

下载

• 检查从库当前状态：SELECT @@global.gtid_executed, @@global.gtid_purged;
• 对比主库：SHOW MASTER STATUS; 中的 Executed_Gtid_Set
• 若从库 gtid_executed 为空，说明没执行过任何 GTID 事务，必须先用 mysqldump --set-gtid-purged=ON 导入全量数据，否则无法对接
• 若 gtid_purged 含有主库不存在的 UUID（例如曾作为其他集群的主库），需手动 RESET MASTER 清空（仅限全新从库），再重新导入

mysqldump 导出时 --set-gtid-purged=ON 不是可选项

用传统方式导出再导入，从库的 gtid_purged 会为空，主从 GTID 集合无法对齐，START SLAVE 必然失败。必须加 --set-gtid-purged=ON，让 dump 文件开头包含 SET @@GLOBAL.GTID_PURGED='...' 语句，确保从库导入后 gtid_purged 与主库初始状态一致。

• 漏掉这个参数，即使主从配置全对，复制也起不来
• --set-gtid-purged=OFF 或不加该参数，dump 文件不会设置 GTID_PURGED，从库导入后 gtid_purged 为空
• 导入前确认从库已停掉复制：STOP SLAVE;，避免边导入边同步造成冲突
• 导入完成后，务必验证：SELECT @@global.gtid_executed; 应与主库 SHOW MASTER STATUS 中的 Executed_Gtid_Set 一致

GTID 复制的脆弱点不在配置多难写，而在于“两端状态必须精确对齐”——配置一致、变量值一致、GTID 集合一致、甚至 dump 导入方式也必须带标记。少一个环节，START SLAVE 就不是慢，而是彻底不动。