mysql使用基于GTID的复制进行事务同步与恢复

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 STATUSG 中 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 STATUSG → 找 Retrieved_Gtid_Set 和 Executed_Gtid_Set，出错事务通常在前者中但不在后者中
• 假设要跳过的 GTID 是 e1e2f3a4-……:101，执行：

  BEGIN;
  COMMIT;
  SET GTID_NEXT = 'e1e2f3a4-5678-90ab-cdef-1234567890ab:101';
  BEGIN;
  COMMIT;
  SET GTID_NEXT = 'AUTOMATIC';

  这相当于“伪造”执行了一次该 GTID 的空事务，MySQL 就不会再尝试重放它

• 然后 START SLAVE; 即可继续同步

注意：跳过操作必须在从库上执行，且 GTID_NEXT 值必须与出错事务完全一致（包括 source_id 和 transaction_id），大小写和连字符都不能错；跳过多个事务需逐个注入，不能合并。