GTID是MySQL 5.6+的全局事务唯一标识（source_id:transaction_id），替代binlog文件名+位置，确保事务唯一性、自动定位与主从切换可靠性；传统方式在主库重建或日志轮转时易导致重复或丢失，且GTID模式下禁止非GTID的CHANGE MASTER操作。
GTID 是什么，为什么不能直接用 binlog 文件名 + 位置做恢复
GTID（Global Transaction Identifier）是 MySQL 5.6+ 引入的全局事务唯一标识，格式为 source_id:transaction_id（如 e1e2f3a4-5678-90ab-cdef-1234567890ab:1）。它替代了传统基于 binlog filename + position 的复制定位方式，核心优势在于：事务在集群中可被唯一识别、无需人工计算位点、支持自动跳过已执行事务、主从切换后仍能准确定位同步起点。
如果你还在用 CHANGE MASTER TO MASTER_LOG_FILE='mysql-bin.000001', MASTER_LOG_POS=1234 恢复复制，一旦发生主库重建、日志轮转或中间节点故障，就极易出现事务重复或丢失——GTID 模式下，MySQL 会拒绝这种非 GTID 方式的 CHANGE MASTER 操作，并报错：ERROR 1777 (HY000): CHANGE MASTER cannot be executed when @@GLOBAL.GTID_MODE = ON.
启用 GTID 复制前必须满足的 3 个硬性条件
GTID 不是开关一开就能用的功能，MySQL 会严格校验运行时环境。不满足任一条件，START SLAVE 会失败，且错误信息非常隐晦（比如只报 Slave_IO_Running: No，但 SHOW SLAVE STATUS\G 中 Last_IO_Error 显示空或仅提示“Could not find first log file name in binary log index file”）。
-
enforce_gtid_consistency = ON：要求所有事务都兼容 GTID（禁止 CREATE TEMPORARY TABLE、非事务引擎表写入、CREATE TABLE ... SELECT 等语句） -
gtid_mode = ON：必须设为ON，不能是ON_PERMISSIVE或OFF_PERMISSIVE（后者仅用于迁移过渡） - 主从双方都已开启二进制日志（
log_bin = ON），且binlog_format = ROW（STATEMENT 或 MIXED 在 GTID 下不可靠）
检查命令：
SELECT @@enforce_gtid_consistency, @@gtid_mode, @@log_bin, @@binlog_format;任意一项不满足，需修改
my.cnf 并重启 mysqld。
从备份恢复并重连 GTID 复制的正确流程
典型场景：从库宕机，你用 mysqldump --all-databases --single-transaction --set-gtid-purged=ON 或物理备份（如 Percona XtraBackup）恢复数据后，必须让从库知道“我已经有了哪些事务”，否则它会尝试重放全部历史日志，导致主键冲突或重复插入。
关键动作是设置 gtid_purged —— 它告诉从库：“这些 GTID 对应的事务，我本地已经执行过了，别再给我发”。操作分三步：
- 从备份文件头或
xtrabackup_binlog_info中提取原始主库当时的Executed_Gtid_Set（例如e1e2f3a4-...:1-100） - 停止从库：
STOP SLAVE; - 清空并注入已执行集合：
RESET MASTER;
注意：必须先
SET GLOBAL gtid_purged = 'e1e2f3a4-5678-90ab-cdef-1234567890ab:1-100';RESET MASTER，否则gtid_purged无法设置（会报错ERROR 1840 (HY000): @@GLOBAL.GTID_PURGED can only be set when @@GLOBAL.GTID_EXECUTED is empty.） - 重新配置复制源（此时用 GTID 模式）：
CHANGE MASTER TO
MASTER_HOST='master_ip',
MASTER_PORT=3306,
MASTER_USER='repl',
MASTER_PASSWORD='xxx',
MASTER_AUTO_POSITION = 1;MASTER_AUTO_POSITION = 1是关键，它让从库自动向主库请求缺失的 GTID 区间，而不是靠人工指定日志位置
跳过一个出错的 GTID 事务（比如主键冲突）
当从库报错 Last_SQL_Error: Duplicate entry '123' for key 'PRIMARY'，且确认该事务可安全跳过时，不能像传统模式那样用 SET GLOBAL sql_slave_skip_counter=1（GTID 下该变量被禁用，会报错 ERROR 1858 (HY000): sql_slave_skip_counter can not be set when the server is running with @@GLOBAL.GTID_MODE = ON.）。
正确做法是注入一个空事务，手动标记该 GTID 已“执行”：
- 查看当前卡住的 GTID：
SHOW SLAVE STATUS\G→ 找Retrieved_Gtid_Set和Executed_Gtid_Set，出错事务通常在前者中但不在后者中 - 假设要跳过的 GTID 是
e1e2f3a4-...:101，执行：BEGIN;
这相当于“伪造”执行了一次该 GTID 的空事务，MySQL 就不会再尝试重放它
COMMIT;
SET GTID_NEXT = 'e1e2f3a4-5678-90ab-cdef-1234567890ab:101';
BEGIN;
COMMIT;
SET GTID_NEXT = 'AUTOMATIC'; - 然后
START SLAVE;即可继续同步
注意：跳过操作必须在从库上执行，且 GTID_NEXT 值必须与出错事务完全一致（包括 source_id 和 transaction_id），大小写和连字符都不能错；跳过多个事务需逐个注入，不能合并。
