MySQL 8.0 基于 GTID 的主从复制必须同时满足 gtid_mode=ON、enforce_gtid_consistency=ON、log_bin=ON 三项，缺一不可；否则 START SLAVE 会报错 ERROR 3021 或卡在 Retrieving GTID set 状态。
直接上结论：MySQL 8.0 中基于 GTID 的主从复制必须同时满足 gtid_mode=ON、enforce_gtid_consistency=ON、log_bin=ON 三项，缺一不可；否则 START SLAVE 会报错 ERROR 3021 (HY000): This operation cannot be performed with a running slave 或卡在 Retrieving GTID set 状态。
主从都必须提前验证的三项基础参数
GTID 复制不是“配完重启就通”，很多失败源于启动前未检查状态。以下三步必须在主从两台机器上分别执行：
-
SELECT @@log_bin;返回ON——log_bin必须开启，即使从库也要开（因log_slave_updates依赖它） -
SELECT @@binlog_format;返回ROW—— MySQL 8.0 默认仍是STATEMENT，不显式设为ROW会导致非确定性函数（如NOW()、UUID()）在从库执行结果不一致 -
SELECT @@server_id;确认主从值不同（如主为1，从为2），且不能是默认的1（多实例共存时极易冲突）
配置文件里最容易漏写的两个强制项
仅靠 SET GLOBAL 动态设置无法持久化，且某些参数（如 gtid_mode）必须在配置文件中声明并重启生效。以下两项必须写进 /etc/my.cnf 的 [mysqld] 段：
-
gtid_mode = ON：不能只设ON_PERMISSIVE或OFF_PERMISSIVE，生产环境必须严格ON -
enforce_gtid_consistency = ON：它会拒绝任何不兼容 GTID 的语句（如CREATE TABLE ... SELECT、用户变量赋值），不设此项，后续START SLAVE直接失败
注意：server-id 和 log-bin 虽然也需配置，但它们出错时通常报错更明确；而上面两项漏配，错误信息极其隐晦，常表现为从库 IO 线程反复重连或 SQL 线程报 Could not execute Write_rows event。
从库启动复制前必须清理 auto.cnf
用克隆/镜像方式部署从库时，/var/lib/mysql/auto.cnf 文件会被完整复制，导致主从 server_uuid 相同。此时即使 server-id 不同，从库也会拒绝接收主库 binlog，日志中出现：
安装、修复、更新或打包一个基于 Python 和 PyMySQL 实现的 Windows `mysql` 命令。适用于用户希望在 PowerShell/CMD 中输入 `mysql` 时重定向到 Python 实现、需要交互式输入 MySQL 连接信息、需要同步到当前用户本地 bin 目录，或需要将该能力封装成可公开复用的 Codex skill。
2026-11-04T19:20:15.332178Z 12 [ERROR] Slave I/O for channel '': Got fatal error 1236 from master when reading data from binary log: 'The slave is connecting using CHANGE MASTER TO MASTER_AUTO_POSITION = 1, but the master has purged binary logs containing GTIDs that the slave requires.', Error_code: 1236
解决方法很简单，但极易被跳过：
- 停掉从库：
systemctl stop mysqld - 删掉旧 UUID：
rm -f /var/lib/mysql/auto.cnf - 再启动：
systemctl start mysqld—— 启动时会自动生成新server_uuid - 验证：
SELECT @@server_uuid;确认与主库不同
CHANGE MASTER TO 语句必须用 MASTER_AUTO_POSITION=1
启用 GTID 后，不能再用传统方式指定 MASTER_LOG_FILE 和 MASTER_LOG_POS。正确命令只有一条：
CHANGE MASTER TO MASTER_HOST='10.0.0.101', MASTER_USER='repl', MASTER_PASSWORD='xxx', MASTER_PORT=3306, MASTER_AUTO_POSITION=1;
其中关键点：
-
MASTER_AUTO_POSITION=1是唯一合法方式，设为0或省略会导致复制使用 position 模式，与 GTID 冲突 - 复制账号必须有
REPLICATION SLAVE权限，且主机名要允许从库 IP 连接（例如'repl'@'10.0.0.102'或'repl'@'%'） - 如果主库已运行一段时间，确保其
gtid_purged值未覆盖从库缺失的事务 —— 可通过SHOW MASTER STATUS查看当前Executed_Gtid_Set，再比对从库SELECT * FROM mysql.gtid_executed;
真正容易被忽略的是：GTID 复制一旦启动，gtid_executed 表和 gtid_purged 就成为状态核心，任何手动 RESET MASTER 或误删 binlog 都可能导致从库再也追不回缺失的 GTID，只能重搭。
