MySQL

MySQL GTID 主从故障排查

·7 分钟阅读·2533 字
mysqlgtidreplicationtroubleshooting
📋 目录

一、GTID基础概念

1.GTID组成

GTID = server_uuid:transaction_id

  • server_uuid：实例唯一标识（auto.cnf）
  • transaction_id：本机事务自增序号，从1开始

全局唯一，一个事务在全集群只对应一个GTID。

2.核心优势（对比传统点位file+pos）

  1. 不用记录binlog文件名+偏移量，change master to master_auto_position=1自动找位点；
  2. 故障切换、主从重建不用人工找pos；
  3. 精准跳过指定事务，摒弃sql_slave_skip_counter粗放跳事务；
  4. 规避因binlog分段、日志清理导致点位错乱。

3.开启前置参数（my.cnf）

gtid_mode=ON
enforce_gtid_consistency=ON
log_bin=ON
log_slave_updates=ON 级联复制(主→从→从)必须开启

4.GTID集合

  1. gtid_executed：本机已经执行完、写入binlog的事务集合；
  2. gtid_purged：binlog被purge删除，磁盘不存在的事务；
  3. Retrieved_Gtid_Set：IO线程拉取完毕的GTID；
  4. Executed_Gtid_Set：SQL线程回放完成的GTID。

二、GTID主从同步流程

  1. 从库change master开启auto_position=1；
  2. 从库把自身Executed_Gtid_Set发给主库；
  3. 主库对比：只发送主存在、从没有的GTID对应的binlog；
  4. IO拉取binlog→relaylog，记录Retrieved_Gtid_Set；
  5. SQL线程按GTID顺序回放，写入Executed_Gtid_Set。

关键：GTID事务只会被执行一次，天然防重复回放。

三、GTID模式建主从标准语句

stop slave;reset slave all;
CHANGE MASTER TO
MASTER_HOST='ip',MASTER_USER='repl',MASTER_PASSWORD='xxx',
MASTER_PORT=3306,MASTER_AUTO_POSITION=1;
start slave;

四、GTID高频故障&排查（面试高频）

故障1：SQL报错主键冲突(1062)，需要跳过单个事务

传统sql_slave_skip_counter在GTID开启下禁用。

stop slave;
# 指定要跳过的冲突GTID
SET gtid_next='UUID:N';
BEGIN;COMMIT; 空事务占位占用该 GTID
SET gtid_next=AUTOMATIC;
start slave;

原理：主动消费掉报错GTID，从库认为该事务已执行，不再回放。

故障2：从库Executed_Gtid大于主库，auto_position找不到起始binlog

场景：从库曾经当过主，存在主库没有的GTID，搭建主从IO报错。
原因：从库本地gtid_executed里包含主库不存在的事务，主库无法回溯日志。
修复：

# 清空本机已执行GTID（重做全量备份导入后使用）
reset master;

故障3：主库purge binlog，从库缺失中间一段GTID

报错：主找不到从缺失区间的binlog。

  1. 临时：全量mysqldump/xtrabackup重做主从；
  2. 规范：主库expire_logs_days保留时长>全量备份周期。

故障4：级联复制（A→B→C）B没开log_slave_updates

B接收A的GTID，但不落地binlog，C无法拉取B的binlog，IO失败。

多级从库必须开启log_slave_updates=ON。

故障5：主从gtid_mode配置不一致，IO线程起不来

一边ON一边OFF，握手失败。
规范：集群所有实例统一GTID开关。

故障6：Seconds_Behind_Master持续上涨（GTID主从延迟）

  1. 从库单SQL线程回放瓶颈→5.7开启并行复制slave_parallel_type=LOGICAL_CLOCK；
  2. 主超大事务，一个GTID包含海量DML；
  3. 从库业务查询占用IO。

五、常用GTID查询命令

# 查看本机已执行GTID
select @@gtid_executed;
# 查看被清理的GTID
select @@gtid_purged;
# 从库状态查看两套GTID集合
show slave status\G

六、Obsidian面试卡片

tags: #MySQL #GTID #主从复制 #故障排查 #面试
题型:原理+实操
难度:高级
题目：简述GTID主从原理，以及主键冲突时GTID如何跳过事务？
精简答案：
1.GTID=server_uuid+事务ID，全局唯一；主从自动比对GTID集合，auto_position自动定位同步位点；
2.开启GTID后废弃sql_slave_skip_counter，冲突时通过set gtid_next指定故障GTID，空事务占用后继续同步；
3.三大集合：gtid_executed(已执行)、gtid_purged(日志已删除)、Retrieved/Executed_Gtid_Set(从库同步标记)。
拓展：级联复制需开启log_slave_updates，否则下级从库无法同步。
易错点：GTID环境不能使用sql_slave_skip_counter。
关联:[[../MySQL 主从同步故障排查|MySQL 传统主从故障]]

下一章节可选

  1. MySQL并行复制原理
  2. Xtrabackup物理备份+GTID搭建主从实操

关联文档 -../GTID 集合详解 — GTID 原理 -../MySQL 复制原理与配置 — 复制原理

  • ../面试题/MySQL 日志与复制 — 面试题
返回首页订阅更新