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;<br>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<br> MASTER_HOST='master_ip',<br> MASTER_PORT=3306,<br> MASTER_USER='repl',<br> MASTER_PASSWORD='xxx',<br> 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;<br>COMMIT;<br>SET GTID_NEXT = 'e1e2f3a4-5678-90ab-cdef-1234567890ab:101';<br>BEGIN;<br>COMMIT;<br>SET GTID_NEXT = 'AUTOMATIC';这相当于“伪造”执行了一次该 GTID 的空事务，MySQL 就不会再尝试重放它 然后
START SLAVE;即可继续同步
注意：跳过操作必须在从库上执行，且
GTID_NEXT值必须与出错事务完全一致（包括 source_id 和 transaction_id），大小写和连字符都不能错；跳过多个事务需逐个注入，不能合并。
