[小技巧62]MySQL主从复制从基于点位到基于GTID的切换流程
一、GTID 模式切换的核心流程回顾
在深入影响分析前，先明确标准切换流程（适用于 MySQL 5.7+）：
-- 步骤 1：开启警告模式（观察期）
SET @@GLOBAL.enforce_gtid_consistency = WARN;
-- 步骤 2：强制一致性（阻断不兼容语句）
SET @@GLOBAL.enforce_gtid_consistency = ON;
-- 步骤 3-5：渐进式切换 GTID 模式
SET @@GLOBAL.gtid_mode = OFF_PERMISSIVE;
SET @@GLOBAL.gtid_mode = ON_PERMISSIVE;
SET @@GLOBAL.gtid_mode = ON;
关键原则：上述每一步必须在**所有主从节点上同步完成（即，同一个命令现在主库上执行，再去从库上执行，然后再执行下一个命令）**后，再进行下一步。
| 命令 | 作用 |
|---|---|
enforce_gtid_consistency = WARN | 允许不兼容语句，但记录警告 |
enforce_gtid_consistency = ON | 严格禁止不兼容 GTID 的语句 |
gtid_mode = OFF_PERMISSIVE | 不生成 GTID，但可执行带 GTID 的事务 |
gtid_mode = ON_PERMISSIVE | 生成 GTID，也可执行无 GTID 的事务 |
1. 切换流程图解
2. 切换过程中的关键注意事项
| 项目 | 建议 |
|---|---|
| 操作顺序 | 所有节点（主+从）必须同步、按顺序执行五步切换（WARN → ON → OFF_PERMISSIVE → ON_PERMISSIVE → ON） |
| 停写窗口 | 官方称无需停机，但建议在低峰期操作，并密切监控复制状态 |
| 回滚可能性 | 可逆！只要按相反顺序切换回去（ON → ON_PERMISSIVE → OFF_PERMISSIVE → OFF），但需确保期间无 GTID-only 事务残留 |
| 验证命令 | 切换后检查：SHOW VARIABLES LIKE 'gtid_mode';SHOW SLAVE STATUSG（看 Auto_Position 是否为 1） |
二、GTID 切换对系统的影响分析
1. 对复制（Replication）的影响
| 场景 | 影响 | 风险等级 |
|---|---|---|
| 按规范切换 | 复制短暂延迟，自动恢复 | 低 |
| 主从状态不一致（如主已 ON，从仍 OFF） | 复制线程报错停止，需重建 | 高 |
未使用 MASTER_AUTO_POSITION=1 | 无法利用 GTID 自动定位，失去核心优势 | 中 |
💡 建议：切换完成后，务必执行：
STOP SLAVE; CHANGE MASTER TO MASTER_AUTO_POSITION = 1; START SLAVE;
2. 对应用程序的影响
GTID 要求事务具备确定性，以下语句将被禁止（当 enforce_gtid_consistency=ON）：
CREATE TABLE ... SELECT- 在事务中使用
CREATE TEMPORARY TABLE/DROP TEMPORARY TABLE - 使用非确定性函数（如
UUID(),RAND(),SYSDATE()）的 DML（除非配置--sysdate-is-now） - 多语句事务中混合 DDL 与 DML（部分版本限制）
后果：应用执行上述语句时将直接报错：
ERROR 1786 (HY000): Statement violates GTID consistency...
3. 对性能的影响
| 指标 | 影响程度 | 说明 |
|---|---|---|
| CPU/内存开销 | 可忽略 | GTID 仅在事务提交时生成 UUID+序号 |
| 网络流量 | 微增 | 每个 binlog event 增加少量元数据 |
| 复制效率 | 提升 | 自动位置定位减少人工干预，提升 HA 可靠性 |
4. 对高可用架构的影响
| 架构类型 | 是否依赖 GTID | 说明 |
|---|---|---|
| MHA（Master High Availability） | 推荐 | 新版支持 GTID，切换更精准 |
| MySQL InnoDB Cluster / Group Replication | 强制要求 | 未启用 GTID 无法启动集群 |
| Orchestrator / repmgr | 支持 | 利用 GTID 实现无损故障转移 |
三、GTID 切换的最佳实践
为确保切换安全，建议遵循以下 checklist：
-
预检阶段
- 在测试环境全链路验证
- 使用
grep -i 'gtid' error.log或审计工具扫描不兼容 SQL - 通知开发团队潜在 SQL 改造需求
-
切换窗口选择
- 选择业务低峰期
- 避免大事务或批量作业运行期间
-
操作规范
- 所有节点同步执行五步流程
- 每步间隔 1–2 分钟，观察
SHOW SLAVE STATUS和错误日志
-
回滚预案
- 若需回退，按相反顺序切换：
ON → ON_PERMISSIVE → OFF_PERMISSIVE → OFF - 确保回退前无纯 GTID 事务写入（否则旧模式无法解析）
- 若需回退，按相反顺序切换：
-
验证指标
SELECT @@gtid_mode, @@enforce_gtid_consistency;→ 应为ON, ONSHOW SLAVE STATUSG→Auto_Position: 1- 应用核心链路回归测试通过
四、常见面试题
Q1：为什么不能直接将 gtid_mode 从 OFF 改为 ON？
答：MySQL 要求通过 OFF_PERMISSIVE 和 ON_PERMISSIVE 两个中间状态实现协议兼容。直接跳变会导致主从无法互相解析 binlog 事件，引发复制断裂。
Q2：enforce_gtid_consistency=WARN 和 =ON 的区别是什么？
答：WARN 模式允许执行不兼容 GTID 的语句，但记录警告；ON 模式则直接拒绝执行，返回错误。前者用于风险发现，后者是启用 GTID 的必要前提。
Q3：启用 GTID 后，如何做主从故障切换？
答：因 GTID 全局唯一，新主无需关心从库的 binlog 文件和位置。只需在从库执行：
STOP SLAVE;
CHANGE MASTER TO MASTER_HOST='new_master', ..., MASTER_AUTO_POSITION=1;
START SLAVE;
MySQL 自动根据已执行的 GTID 集合（Executed_Gtid_Set）确定同步起点。
Q4：GTID 模式下能否关闭 binlog？
答：不能。GTID 依赖 binlog 存储事务 ID，若关闭 binlog，GTID 机制失效，且 MySQL 会拒绝启动或报错。
Q5：如何查看当前实例已执行的 GTID 集合？
答：执行：
SHOW MASTER STATUS; -- 查看主库的 GTID_EXECUTED
SHOW SLAVE STATUSG -- 查看从库的 Executed_Gtid_Set
-- 或全局变量
SELECT @@GLOBAL.gtid_executed;
