MySQL GTID环境下的主库转移指南

主库转移，通常称为 Failover，是指在当前主库（Master）不可用或需要维护时，将一个从库（Replica）提升为新主库的过程。GTID 复制极大地简化了这一流程。

一、核心前提与优势

1. GTID 复制的优势：

   • 自动定位：无需寻找二进制日志位置，从库通过 MASTER_AUTO_POSITION=1 自动从新主库获取缺失的事务。

   • 一致性：GTID 的全局唯一性避免了重复应用或丢失事务。

   • 拓扑无关性：无论复制拓扑多复杂（级联、多源），切换逻辑都简单一致。

2. 转移前必须满足的条件：

   • 所有节点均已启用 GTID（gtid_mode=ON）。

   • 候选从库（新主库）的数据应尽可能最新（Seconds_Behind_Master 为 0 或极小）。

   • 确保应用程序的数据库连接配置可以通过负载均衡器或配置管理工具动态更新。

二、计划内转移（平滑切换）

计划内转移通常在维护、升级或扩容时进行，目标是零数据丢失和最小服务中断。

操作流程：

1. 准备工作：

   • 通知业务方维护窗口。

   • 暂停监控告警，避免不必要的警报。

   • (可选) 在应用层短暂停止写入，确保所有从库已完全同步。

2. 提升候选从库为新主库：

   • 选择数据最超前的从库（例如 S1）。

   • 在 S1 上执行：

      -- 1. 停止复制线程，清空复制信息
      STOP SLAVE;
      RESET SLAVE ALL;       -- 重要：清除 master.info 和 relay-log.info，断绝旧复制关系
      ​
      -- 2. 取消只读模式，使其可写
      SET @@global.read_only = OFF;
      SET @@global.super_read_only = OFF; -- MySQL 5.7+
      ​
      -- 3. (强烈建议) 清空其自身的 GTID 执行历史，为新开始做准备
      RESET MASTER;

   • 注意：RESET MASTER 会清空 S1 的 gtid_executed 集合。如果 S1 有下级从库，绝对不能执行此操作，否则会破坏复制链。

3. 重新配置其他从库指向新主库：

   • 在所有其他从库（包括旧主库一旦恢复）上执行：

      STOP SLAVE;
      CHANGE MASTER TO
        MASTER_HOST = 'new_master_ip', -- S1 的 IP 地址
        MASTER_USER = 'repl',
        MASTER_PASSWORD = 'password',
        MASTER_AUTO_POSITION = 1;      -- 关键！
      START SLAVE;

   • 检查复制状态：SHOW SLAVE STATUS\G，确保 Slave_IO_Running 和 Slave_SQL_Running 为 Yes。

4. 切换应用流量：

   • 更新应用程序的连接字符串、负载均衡器或 DBLE 等中间件的配置，将写端点从旧主库指向新主库（S1）。

   • 这是业务恢复写的最终步骤。

5. 处理旧主库：

   • 当旧主库修复后，可以将其作为新主库的一个新从库重新加入集群。

    -- 在旧主库上执行
    CHANGE MASTER TO
      MASTER_HOST = 'new_master_ip', -- 指向 S1
      MASTER_USER = 'repl',
      MASTER_PASSWORD = 'password',
      MASTER_AUTO_POSITION = 1;
    START SLAVE;

三、计划外转移（故障切换）

当主库突然宕机（如硬件故障、机房网络中断）时，需要紧急提升从库。目标是在可接受的数据丢失风险下尽快恢复服务。

操作流程：

1. 确认故障：

   • 通过监控系统确认主库确实不可用（网络超时、服务无响应）。

   • 尝试从多个网络路径访问主库，排除网络分区等假象。

2. 选择并提升新主库：

   • 选择数据最超前、最健康的从库（通过对比 SHOW SLAVE STATUS\G 中的 Executed_Gtid_Set，选择集合最大的）。

   • 重要：由于是意外故障，新主库可能缺少最后几个未同步的事务。必须接受这部分数据丢失的风险。

   • 在候选从库上执行：

      STOP SLAVE;
      RESET SLAVE ALL;   -- 清除旧复制关系，防止主库恢复后自动连接
      SET @@global.read_only = OFF;
      -- 此时通常不执行 RESET MASTER，以保留故障前的 GTID 历史用于排查。

3. 重新配置其他从库：

   • 与计划内转移的步骤 3 相同，将所有其他存活的从库指向新主库。

4. 切换应用流量：

   • 与计划内转移的步骤 4 相同，更新应用配置。

5. 数据一致性检查与处理：

   • 故障恢复后，使用 pt-table-checksum 等工具检查新主库与其他从库的数据一致性。

   • 评估丢失的事务是否关键。如果极其重要，需尝试从旧主库的磁盘中恢复最后的二进制日志文件，手动补录数据（操作复杂，成功率不高）。

四、借助高可用工具自动化（推荐）

手动操作容易出错且速度慢。生产环境强烈推荐使用高可用工具自动化整个流程。

1. Orchestrator：

   • 自动检测主库故障。

   • 自动选择数据最先进的从库进行提升。

   • 自动重构整个复制拓扑。

   • 提供 Web UI 和 API，支持手动干预和可视化。

2. MHA (Master High Availability)：

   • 自动监控主库状态。

   • 在故障时尝试从旧主库抢救未同步的二进制日志（减少数据丢失）。

   • 自动提升新主库并重新配置从库。

使用这些工具可以大大减少人工操作，将故障恢复时间（RTO）从分钟级缩短到秒级。

五、总结与最佳实践

项目	计划内转移	计划外转移
目标	零数据丢失，服务平滑	快速恢复服务，容忍部分数据丢失
核心操作	STOP SLAVE; RESET SLAVE ALL; SET read_only=OFF;	STOP SLAVE; RESET SLAVE ALL; SET read_only=OFF;
RESET MASTER	视情况使用（如无下级从库则建议）	通常不使用（保留现场用于排查）
数据风险	极低	有可能丢失最后几个事务
自动化	可通过工具编排	强烈建议使用 Orchestrator/MHA

通用最佳实践：

1. 模拟演练：定期在测试环境进行故障切换演练，熟悉流程并验证工具有效性。

2. 监控告警：严密监控复制延迟和复制状态，提前发现问题。

3. 配置管理：确保应用连接字符串不硬编码，可通过配置中心或负载均衡器快速切换。

4. 文档与流程：将主库转移的步骤写成详细的运维手册，确保任何运维人员都能按章操作。

通过结合 GTID 复制的特性和自动化工具，MySQL 的主库转移可以变得非常高效和可靠，为构建高可用的数据库架构奠定坚实基础。