MySQL 5.7 GTID 主从切换与故障恢复指南

唐可

发布时间：2026-10-15 | 4人浏览过

原创

在 MySQL 主从架构中，主从切换是保障高可用性的关键操作。本文针对 MySQL 5.7.32 及以上版本（启用 GTID），详细说明主备正常切换的标准流程，以及主库意外宕机时的应急处理与数据恢复方案，重点解决切换过程中的数据一致性问题。

环境准备与切换前校验

本文涉及的操作基于 MySQL-5.7.32+ 且开启 GTID 的环境。在进行任何切换操作前，需明确当前主库（Master）与备库（Slave）的网络拓扑结构。

第一步：切断应用流量并设置只读

为确保切换期间无新写入数据，首先切断应用层对原主库的连接请求。随后，分别在原主库和原备库上执行以下 SQL，将数据库设置为只读模式：

set global read_only=ON;
set global super_read_only=ON;

此步骤目的是防止在切换准备阶段产生新的事务日志，保证数据状态的静态一致性。

第二步：检查备库复制状态

登录原备库，执行 show slave status\G 查看复制线程状态。

确认关键指标如下： 1. Slave_IO_Running 和 Slave_SQL_Running 均为 YES。 2. Seconds_Behind_Master 值为 0，表示备库已完全追平主库数据。

第三步：比对 GTID 执行集合

使用 GTID 机制可快速判断主备数据是否一致。分别获取主库和备库的 gtid_executed 变量值：

select @@global.gtid_executed;

参考截图对比主备两边的 GTID 集合

与

。

执行以下 SQL 进行逻辑比对：

SELECT GTID_SUBSET(master_gtid_executed, slave_gtid_executed);

若返回结果为 1 (TRUE)，说明主库的所有已提交事务（GTID）均已在从库中执行完毕，两边数据严格一致。只有在此条件下，才能安全切换。

计划内正常切换流程

当校验通过后，按以下步骤将备库提升为新主库：

第四步：清理备库复制信息

在备库上停止复制进程并重置所有主从连接配置：

stop slave;
reset slave all;

这将清除备库关于旧主库的配置信息，使其具备独立运行的能力。

第五步：新主库开启读写权限

解除备库的只读限制，使其接受新的写入请求：

set global read_only=OFF;
set global super_read_only=OFF;

此时，该实例已成为新的 Master 。

第六步：旧主库转为新备库

如果旧主库仍健康运行，可将其配置为从属于新主库，实现反向同步。登录旧主库，执行 CHANGE MASTER TO 指向新主库地址，并启用自动位置同步：

CHANGE MASTER TO MASTER_HOST='新主库IP',
MASTER_USER='repl_user',
MASTER_PORT=3306,
MASTER_PASSWORD='password',
master_auto_position=1;
start slave;
show slave status\G;

确认新旧主从关系建立成功。

第七步：应用流量迁移

修改应用配置文件，将所有写请求指向新的主库 IP。至此，正常的主备切换完成。

主库宕机后的应急切换与数据恢复

在主库意外宕机且未开启强一致性同步（如半同步）的情况下，主库可能包含少量未同步到备库的事务。直接切换可能导致数据丢失或冲突。

场景一：旧主库损坏，无法启动

若旧主库彻底损坏，需通过离线分析二进制日志（binlog）来找回可能遗漏的数据。

获取差异 GTID 范围： 记录新主库当前的 @@global.gtid_executed 值，这是数据分界线。
离线解析 Binlog： 使用 mysqlbinlog 工具排除掉新主库已执行的 GTID，提取剩余的事务日志。

情况 A：新主库尚未有大量新写入（仅少量测试数据或未写入）
可以直接将排除了已有 GTID 的 binlog 导入新主库：

mysqlbinlog --exclude-gtids='UUID:START-END,...' 
/opt/mysql/log/binlog.000150 | 
mysql -uroot -p -S /opt/mysql/3306/data/mysql.sock -P3306

情况 B：新主库已有大量生产数据写入
直接导入会导致主键冲突或数据覆盖风险。建议将 binlog 解析为 SQL 语句文件，由开发人员人工比对并选择性补入缺失数据：

mysqlbinlog -vv --base64-output=decode-rows 
--exclude-gtids='UUID:START-END,...' 
/opt/mysql/log/binlog.000150 > /tmp/extra_data.sql;

场景二：旧主库可重启，但与新主库存在数据不一致

若旧主库可以重启，且新主库已有应用写入数据，同样不建议直接做级联复制，因为旧主库可能拥有更新的数据块，直接同步会覆盖新主库的有效数据。

建议使用 my2sql 等在线解析工具，将旧主库的差异 binlog 转换为标准 SQL 文本，供应用层进行数据核对与补录。

示例命令：

my2sql -user root -password pwd -work-type 2sql 
-start-file /opt/mysql/log/binlog.000150 
-start-pos 7940194 
--add-extraInfo 
-output-dir /tmp/my2sql_recover

该工具会生成包含 INSERT、UPDATE、DELETE 操作的 SQL 文件，便于逐条审计。

总结

MySQL 主从切换的核心在于数据一致性的精准判断。对于计划性切换，GTID 比对是最可靠的依据；对于灾难性故障，利用 mysqlbinlog 和 my2sql 进行离线数据挽回是最后的安全网。严格执行上述步骤，可最大程度降低切换带来的数据风险与停机时间。以上就是 MySQL 主从切换详细步骤及故障恢复的详细内容，更多关于 MySQL 高可用运维的资料请关注本站其它相关文章！