故障切换、选主与脑裂与跨地域容灾

• 故障检测的方法与指标
• 切换决策与选主
• 切换后的路由更新与恢复

故障切换的完整流程通常分为四步：其一，检测——通过心跳、探活、复制延迟、连接数等指标判断主库是否故障，通常需要多轮确认（如连续 N 次心跳丢包）避免误判；其二，决策——根据故障类型（计划内/计划外）和一致性要求决定是否切换、切换候选（选主），并计算 RPO 达成情况；其三，切换——提升候选从库为新主、让其他从库重挂到新主、更新 VIP/域名/路由配置，使应用连接到新主；其四，恢复——原主恢复后作为从库重挂回新主，补拉日志，必要时做数据校验与业务验证。

故障切换的关键在于"检测的准确性"与"切换的幂等性"。检测要避免误判（防止不必要的切换），切换要保证新主数据最新（选主优先级、日志补拉）。自动切换工具（如 MHA、Patroni、Orchestrator）会封装这些环节，但人工介入的 Runbook 仍是计划外故障的兜底。切换后要验证业务连通与数据一致性。

• Patroni 基于 DCS 的选主与切换
• MHA 的日志补偿与切换
• Orchestrator 的拓扑探测与自动切换

自动故障切换工具通过持续监控主库健康状态，检测到故障后自动完成选主与切换。Patroni（PostgreSQL）基于分布式协调服务（DCS，如 etcd、Consul、ZooKeeper）做选主与领导权租约，主库故障时从库通过 DCS 竞争成为新主，Patroni 负责提升、更新配置并通知负载均衡器。MHA（MySQL）通过 master 节点的健康检查判断故障，选择数据最全的从库作为新主，先从各从库 binlog 补拉缺失日志再切换，避免数据丢失。Orchestrator（MySQL）通过探测复制拓扑，维护各节点状态，支持自动切换与从库重挂，并可用 Raft 模式保证协调器本身的高可用。

这些工具的核心差异在于"选主方式"与"数据保护手段"。Patroni 用 DCS 租约避免选主冲突；MHA 用日志补偿保证数据尽量不丢；Orchestrator 以拓扑探测和自动重挂见长。选型需结合数据库类型、一致性要求与运维复杂度。自动切换能降低 RTO，但需配合演练验证其可靠性。

• Raft 的 Leader 选举（任期、投票）
• Paxos 的提议者/接受者角色
• 两者在选举与工程实现上的差异

选主算法用于在分布式系统中选出一个唯一的 Leader 以保证一致性。Raft 采用明确的 Leader 选举：节点有 Leader、Follower、Candidate 三种角色，通过任期（term）和随机超时触发选举，获得多数派投票的候选者成为 Leader，Leader 通过心跳维持权威。Paxos 则更抽象，通过多轮 Prepare/Accept 阶段（Proposer、Acceptor、Learner 角色）在多数派上达成值一致，其选举过程通常由基本 Paxos 的"选出一个值"派生。工程上 Raft 因更易理解、显式 Leader 和日志复制而更流行（etcd、Consul、TiKV 等使用）。

两者都依赖"多数派"保证一致性，区别在于 Raft 把选举显式化、强 Leader 化、日志复制按序推进，工程实现简单；Paxos 更通用但难实现，实践中多用 Multi-Paxos 或其变体。理解"多数派定值"是理解两者共通核心的前提。

• RTO 的定义与度量
• RTO 与 RPO 的区别
• RTO 对容灾架构设计的影响

RTO（Recovery Time Objective，恢复时间目标）指系统发生故障后，从故障发生到业务恢复可接受的最长时间，即"可容忍的恢复时间"。它衡量的是系统可用性在故障后的恢复速度，是容灾设计的重要指标。RTO 越小，要求恢复越快，对应的架构代价越高（如同城双活、自动切换、热备）。RTO 与 RPO（可容忍的数据丢失量）是两个正交指标：RTO 关注"多久恢复"，RPO 关注"丢失多少数据"。核心业务通常要求低 RTO（分钟级），日志类业务可容忍较长 RTO。

RTO 决定容灾方案的投资和架构复杂度。例如 RTO=0 需要真双活，RTO=分钟级可用自动切换 + 热备，RTO=小时级可用冷备 + 归档恢复。RTO 的设定需结合业务价值与成本，并要通过演练验证实际可达。

• PostgreSQL WAL 跨地域传输
• MySQL binlog 异地归档与同步
• 异地复制与本地复制的区别

异地复制用于跨地域容灾，实现方式取决于数据库：PostgreSQL 通过 WAL 流复制或归档把 WAL 段传到异地从库，异地从库接收并重放；MySQL 通过 binlog 流式复制或把 binlog 归档到异地存储（如对象存储）后由异地从库拉取重放。异地复制通常采用异步或半同步，因为跨地域网络延迟高，同步复制会严重影响主库性能。异地复制是"两地三中心"等容灾架构的基础，目的保证主中心故障时异地能接管。

异地复制的核心挑战是网络延迟与带宽，以及由此产生的数据滞后。异地的 RPO 通常大于本地（异步复制），因此异地容灾更多是"防区域性灾难"的兜底，而非热备。实现上要权衡复制模式（同步/异步）、压缩传输、归档策略。异地从库同样需要复制槽/位点保留机制防止日志被回收。

• WAN 延迟对复制的影响
• 大 RTT 与带宽瓶颈
• 缓解手段（异步、压缩、就近节点）

跨地域复制中，广域网（WAN）的物理距离带来高网络往返延迟（RTT）和有限的带宽，直接影响复制延迟：同步复制下每个事务都要等跨地域 ACK，延迟等于 RTT，会严重拖慢主库；异步复制下，虽然主库不等待，但 binlog/WAL 传输受限于带宽，大事务或大流量下会积压，导致异地从库滞后加剧。缓解手段包括：使用异步复制（降低主库延迟）、压缩传输减少带宽、采用就近中转节点（如异地复制经过两地三中心的中转）、提升带宽、对大事务进行拆分。跨地域复制通常对 RPO 有明确容忍，不做严格同步。

跨地域复制的本质是"用延迟换可用性"。物理距离决定光速时延，无法消除，只能通过架构来缓解其影响。因此异地复制重在"保证数据最终能过去、业务不因跨地域而阻塞"，而非追求实时同步。设计异地容灾时，要明确 RPO 容忍度，用异步 + 带宽规划 + 归档兜底。

• 脑裂的产生条件与危害
• Quorum 仲裁机制
• Fencing 与 STONITH 的隔离原理

脑裂（Split-Brain）指分布式系统中因网络分区，原本的集群被分成多个各自独立、都认为自己拥有主库/领导权的部分，导致多个节点同时对外提供写服务，数据产生冲突和丢失。其产生常因网络分区使节点间心跳中断，且仲裁失败（无法达到多数派）时节点仍擅自杀入主库。防脑裂靠三者的配合：Quorum（仲裁）——只有获得多数派（超过半数）支持的节点才能成为主库，分区后只有能集合多数派的那一侧能继续当主，另一侧退化为只读；Fencing（隔离）——通过租约、锁或强制下线，把被剥夺主权的节点隔离，防止其继续写；STONITH（Shoot The Other Node In The Head）——通过强制断电/重启来杀掉可能失控的节点，是 Fencing 的物理级手段。三者配合：Quorum 决定谁能当主，Fencing/STONITH 保证落选者无法继续写，从而避免脑裂。

脑裂的根因是"分区后两侧都认为自己有资格当主"。Quorum 用多数派仲裁保证任意时刻最多一个领导权被认可；Fencing 用物理或逻辑隔离保证落选节点无法写入共享资源。STONITH 是最后手段，直接断电。大部分数据库高可用系统（Patroni、etcd、Raft 系）都依赖多数派仲裁 + 租约/隔离来防脑裂。

• RPO 与 RTO 的业务绑定
• 核心交易的低 RPO/RTO 要求
• 日志类业务的高容忍度

RPO 与 RTO 的设定应结合业务对数据丢失和中断的容忍度。核心交易（支付、订单、账户）通常要求 RPO 接近 0（尽量不丢数据）和低 RTO（分钟级恢复），因为数据丢失或长时间中断会造成资金损失和严重业务影响，因此需要同步/半同步复制、同城双活、自动切换等高成本方案。日志类业务（访问日志、监控数据、历史归档）对数据丢失和恢复时间容忍度高，RPO 可允许小时级，RTO 可允许小时到天级，常采用异步复制 + 归档 + 冷备的低成本方案。设定 RPO/RTO 需权衡业务价值与成本，并分层设计。

RPO/RTO 是"业务价值"与"成本"之间权衡的量化表达。核心交易投入高成本换低 RPO/RTO，日志业务用低成本换高容忍。同一系统内不同数据可分级设定，这就是"分级容灾"。设定后的 RPO/RTO 需通过演练验证是否真实可达。

• RPO 的定义与度量
• RPO 与数据丢失的量化
• RPO 对复制模式选择的影响

RPO（Recovery Point Objective，恢复点目标）指系统故障后可容忍的数据丢失量，通常以时间量度（如 RPO=0 表示不丢数据，RPO=1 小时表示最多丢失 1 小时的数据）。它代表故障恢复后，数据恢复到哪个时间点，即"丢失了多少数据可接受"。RPO 决定了复制模式的选择：RPO=0 需要同步复制或多数派确认；RPO 接近 0 可用半同步复制；RPO 允许分钟/小时级可用异步复制。RPO 与 RTO 是容灾设计的两个核心指标，RPO 关注数据，RTO 关注时间。

RPO 本质是"数据丢失的容忍上限"。它不是一个绝对的"不丢"，而是量化"可接受丢多少"。设得越低，需要的复制同步程度越高、成本越高。理解 RPO 才能正确选择同步/半同步/异步复制策略，并评估容灾方案的可靠性。

• 跨地域切换的检测与决策
• 异地流量切换与数据一致性
• 切换后的回切与验证

跨地域切换（Geo Failover）指主可用区/地域故障时，将业务流量切换到异地备用地域的过程。流程包括：其一，检测主地域故障并经多级确认后决策切换；其二，在异地确认新主数据状态（评估 RPO，检查异地从库是否追平到可接受点），必要时做数据补齐；其三，提升异地节点为主，将域名/DNS/路由/负载均衡流量切到异地，应用重连；其四，验证异地业务可用性与数据一致性；其五，运营恢复后准备回切。跨地域切换的关键风险是数据丢失（异步复制的 RPO 窗口）与 DNS/路由传播延迟，以及新主业务连续性。

跨地域切换比本地切换更复杂，因为涉及广域网流量调度、两地数据状态和业务依赖（如异地本地资源）。切换决策要基于明确的 RPO 容忍，避免为了切换而接受不可接受的数据丢失。切换前要有演练，回切要确认旧主追平、双写窗口关闭。这是"两地三中心"容灾的核心操作。

• 两地三中心架构
• 同城双活架构
• 不同容灾级别的取舍

跨地域容灾的常见架构包括：其一，两地三中心——同城两个数据中心双活（同城双活，一个作主、一个热备，或双活），异地再设一个灾备中心，形成"同城双活 + 异地灾备"的格局，兼顾本地快速切换与异地兜底；其二，同城双活——两个数据中心同时对外提供服务，通过同步复制保证数据一致，故障时自动切换，RPO 接近 0、RTO 分钟级；其三，异地灾备——异地一个中心做异步复制冷备/温备，用于区域性灾难兜底，RPO 分钟级到小时级。不同架构对应不同 RPO/RTO 与成本。

容灾架构是"成本"与"RPO/RTO"的权衡。同城双活投入高、恢复快；异地灾备投入低、恢复慢。两地三中心是业界常见折中，兼顾同城快速恢复与异地兜底。选择架构需结合业务关键性、预算与合规要求，并配合演练验证。

• 回滚/回切的时机
• 旧主追平校验
• 双写窗口与冲突规避

切换后的回滚（回切）策略指在故障恢复后，把业务从临时新主切回原主（或重新规划架构）的过程。回切步骤包括：其一，确认原主已恢复并完成数据追平（把原主挂为临时新主的从库，补拉日志至一致）；其二，校验新旧主数据一致性（比对复制位点、校验和）；其三，在低峰期执行切换，将流量切回，期间关闭双写窗口，避免两侧同时写入产生冲突；其四，回切后验证业务与数据。回滚要避免"双写"导致数据冲突，因此回切前必须停写或通过单点写保证一致性。

回滚/回切的关键是"数据一致性校验"与"避免双写窗口"。回切本质上是一次反向切换，同样要遵守选主、追平、路由切换、验证的流程。若原主在故障期间已被新主写入而无法追平，可能需要数据合并或重新规划。因此回切前必须做充分的追平与校验。

• RTO 的环节拆解
• 各环节优化手段
• 复制模式对 RTO 的影响

故障切换的 RTO 由多个环节累加：故障检测时间（心跳/探活间隔，可用快速探测与多轮确认平衡误判）、选主时间（多数派投票、候选排序）、日志补拉时间（从库追平主库缺失日志，取决于落后量）、路由切换时间（VIP/域名/DNS/注册中心更新，应用重连）。优化手段：缩短检测间隔、预选候选主、预热从库、减少日志积压、用自动切换工具、提前更新路由与重连配置。复制模式影响：半同步复制下从库数据较新，日志补拉量小，RTO 更短；异步复制下从库可能落后较多，补拉时间长，RTO 更长。因此同步/半同步复制不仅降低 RPO，也有利于缩短 RTO。

RTO 是各环节时间的总和，优化要从"减少故障检测时间、缩短补拉时间、加速路由切换"入手。半同步/同步复制让从库数据更接近主库，补拉更快，从而缩短 RTO。但也要注意同步复制可能增加主库可用性风险（主库等待从库）。RTO 优化需端到端拆解并演练验证。

• RPO/RTO 的测量方法
• 故障演练的步骤
• 演练发现的问题与改进

RPO/RTO 的实测与演练是验证容灾方案有效性的关键。演练流程：设计故障场景（主库宕机、网络分区、机房故障），在测试环境或低峰期注入故障，观察自动切换/手动切换是否按预期执行，测量实际 RTO（从故障到恢复的时间）与 RPO（切换后丢失的数据量），并验证业务可用性。演练要点：演练前明确场景与预期指标、演练中记录各环节耗时、演练后复盘改进（如检测灵敏度、切换脚本、补拉速度）。通过演练能发现配置错误、脚本缺陷、依赖缺失等问题，逐步逼近目标 RPO/RTO。

纸上谈兵的 RPO/RTO 不可信，必须靠演练验证。演练暴露的问题（如切换脚本不完善、从库未追平、路由未更新）是优化的依据。演练应从"可控场景"逐步到"复杂场景"，并定期进行以保持预案有效。这是运维成熟度的体现。

• MHA 的故障切换机制
• 半同步复制与日志补偿
• 与 MGR、Orchestrator 的对比

MHA（Master High Availability）是 MySQL 的经典高可用方案。它通过监控主库健康，主库故障时，MHA 选择数据最全的从库作为候选新主，并从各从库的 relay log/binlog 中补拉缺失的 binlog 事件，尽量把候选从库补齐到与主库一致，再提升为新主，最后让其他从库重挂到新主。结合半同步复制可减少数据丢失（从库有较新数据，补拉量小）。与传统 MGR 相比，MHA 是"外部协调"型方案，不改变复制引擎，适用传统主从复制架构，但需要独立部署管理节点、且切换有一定窗口；Orchestrator 更侧重拓扑探测与自动重挂、可视化，且支持 Raft 协调器；MGR 是内置组复制，自带多数派共识与自动故障转移，但依赖 InnoDB 和组复制约束。MHA 的局限在于不支持多主、需要外部脚本、对新兴复制特性支持有限。

MHA 的价值在于"日志补偿 + 半同步"降低了数据丢失，适用于已有传统主从复制、需要低成本自动切换的 MySQL 场景。它的局限是单主、需外部协调、切换有窗口。对比 MGR/Orchestrator 可帮助选型：追求自动化与拓扑管理选 Orchestrator，追求内置共识与自动故障转移选 MGR，传统主从快速接管选 MHA。

• Orchestrator 的拓扑探测
• 自动切换与从库重挂
• Raft 协调器与脑裂防护

Orchestrator 是 MySQL 集群管理工具，通过持续探测各节点的复制状态构建实时拓扑图。它自动发现主从关系、检测复制故障，并支持自动切换（把合适的从库提升为新主）与从库重挂（把其他从库重新挂到新主）。Orchestrator 支持以 Raft 模式运行多个 Orchestrator 节点，通过 Raft 共识保证协调器本身的高可用与一致性，避免多个协调器同时决策造成脑裂；同时它通过对外暴露的 leader 与故障判断，配合外部协调器（如 VIP 管理、DNS 切换）共同完成流量切换。脑裂防护的关键是多个 Orchestrator 节点通过 Raft 选主保证只有一个协调者能执行切换决策。

Orchestrator 的强项是"拓扑可见性 + 自动化重挂"，其 Raft 模式解决协调器自身的高可用与防脑裂。相比单点 MHA，Orchestrator 的 Raft 协调器保证任意时刻只有一个协调者做决策，从而避免多个协调器同时触发切换造成脑裂。结合外部协调器（VIP/域名）完成最终流量切换。

• Patroni 基于 DCS 的选主
• 租约与防脑裂
• 与负载均衡器的配合

Patroni 是 PostgreSQL 的高可用方案，通过分布式协调服务（DCS，如 etcd、Consul、ZooKeeper）做分布式选主：每个 PG 节点在 DCS 中竞争 leader 锁，主节点持有租约并定期续约，从节点通过租约判断主节点是否存活。主节点故障时，租约过期，从节点在 DCS 中竞争成为新主，Patroni 更新配置并通知负载均衡器。防脑裂机制：DCS 的锁/租约保证任意时刻只有一个节点持有 leader 权，分区后只有能续约租约的那一侧能当主，另一侧退化为只读。与负载均衡器配合的流程：Patroni 通过 REST API 或健康检查暴露主/从状态，负载均衡器（如 HAProxy、PgBouncer 的读写分离）根据标记把写流量引到主、读流量引到从，切换后负载均衡器自动感知新主并重定向写流量。

Patroni 的核心是"用 DCS 的分布式锁 + 租约实现选主与防脑裂"，它把"谁能当主"这个决策放到分布式协调服务上，保证共识。负载均衡器依赖 Patroni 暴露的状态做路由，切换后自动感知。这套机制是 PG 高可用的标准做法，兼顾自动切换与防脑裂。

• Raft 的领导者选举与日志复制
• Raft 的安全性保证
• 与 Paxos 的工程差异

Raft 通过三个机制保证一致性：选举（Leader Election）——通过任期与随机超时选出唯一 Leader，保证任意任期只有一个 Leader；日志复制（Log Replication）——Leader 把日志条目复制到多数派节点，多数派确认后提交，保证日志一致；安全性（Safety）——通过"选举时只允许拥有最新日志的节点成为 Leader"、"Leader 只追加不覆盖"、"提交只能通过 Leader 传达"等规则，保证已提交日志不会被覆盖。与 Paxos 的工程差异：Paxos 没有显式 Leader，通过多轮 Prepare/Accept 达成共识，难以理解和实现；Raft 把 Leader 显式化、日志复制线性化、选举定时化，工程实现更简单，因此 etcd、Consul、TiKV 等广泛采用 Raft。两者都基于多数派保证一致性。

Raft 的核心贡献是"把共识过程分解为可理解的模块（选举、日志复制、安全性）"，并显式化 Leader 角色，降低实现难度。安全性规则防止了"日志被覆盖"和"选举出旧 Leader"两类问题。理解 Raft 的三机制与 Paxos 的差异，是理解分布式数据库高可用与一致性基础的关键。