主库挂了如何快速切换到备库？(VIP 漂移、MHA、Orchestrator、MGR)

考察要点

这道题考察的是候选人对 MySQL 高可用（High Availability, HA）架构的理解深度和广度。面试官想看你是否懂：

1. 高可用的核心指标：RPO（数据丢失容忍度）和 RTO（服务恢复时间目标）的含义及它们在方案选型中的决定性作用。
2. 主流 HA 方案的原理与权衡：你是否了解并能清晰对比手动切换、MHA、Orchestrator、MGR 等方案的实现机制、优缺点和适用场景。
3. 故障切换中的关键难题：你是否意识到并知道如何处理数据一致性、脑裂（Split-Brain）等复杂问题。

核心概念

精准理解以下概念是回答本题的基础。

主流高可用方案对比

方案 1：手动切换 + VIP 漂移

这是最基础的 HA 方式，依赖 DBA 人工介入。

• 切换流程：
  1. 监控告警：DBA 收到主库不可达的告警。
  2. 人工判断：DBA 登录各个备库，通过 SHOW SLAVE STATUS 检查 Seconds_Behind_Master 和已执行的 GTID/Binlog 位置，找出数据最完整的备库。
  3. 提升新主：在该备库上执行 STOP SLAVE; RESET MASTER;，使其成为新主库。
  4. 数据对齐：让其他备库执行 CHANGE MASTER TO 指向新主库。
  5. 漂移 VIP：在新主库上执行脚本，将 VIP 绑定到本机网卡。
• 优点：架构简单，无需额外组件，成本低。
• 缺点：
  • RTO 极高：完全依赖人工，响应和操作时间长（分钟级甚至更长）。
  • 易出错：人工操作复杂，高压下容易犯错。
  • RPO 不确定：依赖 DBA 的判断和备库的延迟情况。
• 适用场景：业务量小、对可用性要求不高的非核心业务。

方案 2：MHA (Master High Availability)

MHA 是一套成熟的、基于 Perl 的 MySQL 故障切换和主从提升解决方案。

• 架构：由一个 MHA Manager 和多个 MHA Node（部署在每个 MySQL 实例上）组成。
• 切换流程（自动化）：
  1. 故障探测：Manager 通过 SSH 持续探测主库健康。
  2. 差异日志补偿：MHA 的核心优势。当主库宕机但 SSH 仍可达时，MHA Manager 会登录所有从库，收集它们已经接收到的 relay log，并对比差异，将最完整的 relay log 中缺失的部分补全到其他从库，最大限度减少数据丢失。
  3. 选举新主：根据配置策略（如延迟最小）选举一个备库。
  4. 提升新主并重定向：在新主上应用完差异日志后，执行 RESET MASTER，并让其他从库指向新主。
  5. 执行外部脚本：调用预设脚本完成 VIP 漂移或 DNS 修改。
• 优点：
  • RTO 较低：全自动切换，通常在 10-30 秒内完成。
  • RPO 极低：独特的差异日志补偿机制，在异步复制下也能做到接近零数据丢失。
• 缺点：
  • 需要部署 Perl 环境和配置节点间 SSH 免密登录。
  • 社区活跃度降低。
  • 对脑裂的防护需要依赖外部 fencing 脚本。

方案 3：Orchestrator

Orchestrator 是一个使用 Go 语言编写的、更现代的 MySQL 拓扑管理器和高可用解决方案。

• 架构：通过持续探测 MySQL 实例，自动发现和维护整个复制拓扑图。
• 切换流程（自动化）：
  1. 拓扑发现：主动、持续地扫描并可视化整个复制拓扑。
  2. 故障探测：通过心跳和实例状态分析来判断故障。
  3. 选举新主：根据拓扑关系和实例状态（如是否为半同步从库、是否有延迟）智能选举。
  4. 拓扑修复：使用 GTID 或 Pseudo-GTID 技术，将其他从库以及原主库（如果恢复）自动挂到新主库下，实现拓扑的“自愈”。
  5. 调用钩子：通过钩子（Hook）机制执行外部脚本，完成 VIP 漂移等操作。
• 优点：
  • 拓扑感知和自愈：功能强大，能处理复杂的复制结构。
  • Web UI：提供直观的拓扑展示和管理界面。
  • 社区活跃：Go 语言栈，更受现代运维团队青睐。
• 缺点：
  • 相较于 MHA，它本身不具备从宕机主库上抢救 binlog 的能力，数据一致性保障略逊于 MHA。

方案 4：MGR (MySQL Group Replication)

MGR 是 MySQL 官方自 5.7.17 版本推出的原生高可用方案，基于 Paxos 协议实现。

• 架构：将多个 MySQL 实例组成一个“组”，数据通过“组通信系统 (GCS)”进行同步。
• 切换流程（原生、内置）：
  1. 成员管理：组成员共同维护一个成员列表和视图。
  2. 故障探测：当主节点（Primary）失联，GCS 会在剩余成员中发现。
  3. 自动选举：剩余成员基于内置的选举协议，从自身中选举出一个新的 Primary。这个过程非常快，且由组内部自动完成。
  4. 应用透明：通常配合 MySQL Router 使用。Router 能感知组内 Primary 的变化，并将写请求自动路由到新的 Primary，对应用完全透明。
• 优点：
  • RPO=0：提供“几乎同步”的数据复制，可以做到零数据丢失。
  • 内置 HA：无需第三方工具，故障切换、节点加入/退出均为全自动。
  • 原生防脑裂：基于 Paxos 的法定人数（Quorum）机制，天然防止脑裂。
• 缺点：
  • 性能开销：所有写事务都需要经过组成员的“认证”，会增加写延迟。
  • 要求苛刻：要求所有表都是 InnoDB、有主键、开启 GTID、网络环境稳定。
  • 网络敏感：对网络延迟和抖动非常敏感，不适合广域网或网络质量差的环境。

常见低分回答

• “手动改应用配置文件”：这是最原始且不可靠的方式。暴露了候选人缺乏自动化运维和高可用架构思维，RTO 会非常高，且操作繁琐、风险大。
• “用 Load Balancer 就行了”：只说对了一半。LVS/F5/HAProxy 等负载均衡器本身不负责数据库的故障判断和主从切换，它们只负责转发流量。它们需要被 HA 工具（如 MHA/Orchestrator）告知新的主库 IP 是什么，才能正确转发。
• “MHA 切换时会丢数据，因为它基于异步复制”：这个说法不准确，暴露了对 MHA 核心原理理解不深。MHA 的最大亮点就是它的“差异日志补偿”机制，恰恰是为了在异步复制架构下最大限度地挽救数据，使得 RPO 非常接近于 0。
• “直接把备库 read_only 改成 0 就行了”：这是一个非常危险的操作。在没有完成拓扑变更（让其他从库指向它）和流量切换（VIP 漂移）之前，直接开放写入会导致数据不一致和后续处理的混乱。这忽略了故障切换的系统性和原子性。
• 忽略“脑裂”问题：在讨论任何非 MGR 的自动化方案时，如果完全不提“脑裂”风险以及如何通过 fencing（隔离）等手段来规避，说明对高可用方案的健壮性考虑不足。

工程实践与优化

• 选择合适的半同步级别：为了在性能和数据一致性之间取得平衡，生产环境通常会开启半同步复制 (rpl_semi_sync_master_wait_for_slave_count=1)，并配合 rpl_semi_sync_master_timeout 设置一个合理的超时时间。这能保证至少有一个从库接收到日志，大大降低 RPO。
• Failover 演练常态化：高可用方案不是部署完就万事大吉。必须在预发布或测试环境定期进行故障演练，确保切换脚本、工具链、告警都是有效的，并让团队熟悉应急流程。
• 监控是生命线：使用 pt-heartbeat 或其他工具精确监控复制延迟。对主库健康、VIP 状态、HA 工具（如 MHA Manager）本身的健康状况进行全方位监控和告警。
• Fencing (隔离) 机制：为防止脑裂，自动化切换脚本必须包含 Fencing 步骤。在提升新主之前，必须确保旧主被彻底隔离，常见方法包括：
  • 电源管理：通过 IPMI/iDRAC 等接口直接关闭旧主服务器电源（STONITH）。
  • 网络隔离：修改交换机端口配置，隔离旧主。
  • 应用层隔离：将旧主库的 read_only 设为 ON 并 KILL 所有连接。
• 使用代理层简化连接管理：引入 MySQL Router（配合 MGR）或 ProxySQL/DBProxy 等数据库中间件。应用只连接代理，由代理负责探测后端主库健康并进行读写分离和写请求路由，可以进一步降低 RTO，使应用层对切换无感知。

常见追问与延伸题目

1. 追问：MHA 和 Orchestrator 都依赖外部脚本做 VIP 切换，这个脚本如果执行失败了怎么办？

   • 回答要点 1 (容错性)：脚本自身需要有重试和幂等性设计。例如，绑定 VIP 前先检查 VIP 是否已存在于本机，解绑时先检查是否存在。所有关键步骤都要有详细日志，方便排查。
   • 回答要点 2 (告警与人工介入)：脚本执行失败必须触发最高优先级的告警，通知 DBA 立即介入。此时数据库的主从切换可能已经完成，只是流量没有切过来，人工执行 VIP 漂移脚本即可快速恢复服务。这虽然降级为手动操作，但比完全手动切换的 RTO 还是要低得多。
   • 回答要点 3 (备用方案)：除了 VIP，还可以有备用的 DNS 切换方案。如果 VIP 漂移持续失败，可以执行 DNS 修改的 Plan B，虽然 DNS 生效有延迟，但可作为最终保障。

2. 追问：如果让你设计一个高可用方案，你怎么在 MHA 和 MGR 之间选择？

   • 回答要点 1 (业务场景)：首先看业务对数据一致性（RPO）和性能的要求。如果业务是金融级或对数据零丢失有强诉求，且能接受一定的写延迟，优先考虑 MGR。如果业务是互联网应用，对写性能更敏感，能容忍极小概率的秒级数据丢失，MHA 是更成熟、对现有架构侵入性更小的选择。
   • 回答要点 2 (技术栈与运维能力)：评估团队的技术栈和运维能力。MGR 是原生方案，但其内部复杂性高，排查问题需要对 Paxos 和组通信有一定理解。MHA 虽然是外部工具，但原理相对直观，社区文档和实践案例丰富，运维门槛相对较低。
   • 回答要点 3 (架构限制)：检查现有架构是否满足 MGR 的苛刻要求（InnoDB、主键、GTID、高质量网络）。如果改造现有架构的成本过高，或者存在跨机房、跨地域的部署，MHA 的灵活性会更高。

3. 追问：MySQL 8.0 推出的 InnoDB Cluster (MGR + MySQL Shell + Router) 相比你提到的这些方案，有什么优势？

   • 回答要点 1 (集成与易用性)：InnoDB Cluster 是一个完整的、官方打包的解决方案。它通过 MySQL Shell 提供了 dba.createCluster()、cluster.addInstance() 等简单的命令，极大地简化了 MGR 集群的部署、管理和监控工作，降低了使用门槛。
   • 回答要点 2 (端到端方案)：它整合了 MGR（数据层 HA）、MySQL Router（路由层 HA）和 MySQL Shell（管理工具），提供了一个从部署到应用连接的端到端高可用方案。Router 能自动感知 MGR 的主从变化，应用无需任何修改，这是 MHA 等方案需要通过自定义脚本才能实现的。
   • 回答要点 3 (官方支持)：作为官方主推的旗舰级高可用方案，它能获得最及时的新功能更新和 Bug 修复，社区和生态也最为活跃，代表了 MySQL 未来的发展方向。相比之下，MHA 等第三方工具的未来发展存在不确定性。