# 1. 故障切换（Failover）的流程，检测、决策、切换、恢复？ A 故障切换流程包括检测、决策、切换、恢复，其中检测需避免误判以降低不必要的切换 ✓ 正确答案 B 故障切换只需检测到主库不可用就立即切换，无需多轮确认 C 切换后原主不需要任何处理，直接丢弃即可 D 故障切换与选主无关，任何从库都能直接成为新主
# 2. 自动故障切换的实现，Patroni（PG）、MHA/Orchestrator（MySQL）？ A Patroni 不需要任何协调服务，直接在从库间随机选主 B 自动故障切换工具都不需要健康检查，直接切换即可 C Orchestrator 只能手动切换，无法自动探测复制拓扑 D MHA 通过日志补偿从各从库补拉缺失 binlog 再切换，尽量降低数据丢失 ✓ 正确答案
# 3. 选主（Leader Election）的算法，Raft、Paxos？ A Raft 主要用于 Paxos 无法使用的场景，两者核心机制完全不同 B Paxos 总是显式选出一个 Leader，并依靠 Leader 维持心跳 C Raft 和 Paxos 都不需要多数派参与 D Raft 通过随机超时和任期机制选举 Leader，获得多数派投票后成为 Leader ✓ 正确答案
# 4. RTO（Recovery Time Objective）的定义，可容忍的恢复时间？ A RTO 指系统故障后可容忍的数据丢失量 B RTO 与 RPO 是同一个概念的不同叫法 C RTO 指系统故障后从发生到业务恢复可接受的最长时间，衡量恢复速度 ✓ 正确答案 D RTO 越小，容灾架构成本越低
# 5. 异地复制的实现，WAL 跨地域传输、binlog 异地归档？ A 异地复制通常采用同步复制，以保证 RPO=0 B 异地复制只能手动触发，无法自动完成 C 异地复制与本地复制没有任何区别 D PostgreSQL 通过 WAL 传输、MySQL 通过 binlog 传输实现异地复制，异地通常用异步以降低网络延迟影响 ✓ 正确答案
# 6. 跨地域复制的延迟，广域网（WAN）延迟影响？ A 广域网高 RTT 和有限带宽会放大异地复制延迟，常用异步复制并配合压缩传输来缓解 ✓ 正确答案 B 跨地域同步复制不会增加主库延迟，因为事务在本地提交 C 跨地域复制延迟与物理距离无关 D 提高主库单机性能即可完全消除跨地域复制延迟
# 7. 脑裂（Split-Brain）的产生与防止，网络分区与仲裁失败如何导致脑裂，Quorum、Fencing 与 STONITH 等防脑裂机制如何配合？ A 脑裂可以通过提高节点间心跳频率来彻底消除 B 网络分区时所有节点都能安全地继续当主 C Quorum 用多数派仲裁决定谁能当主，Fencing/STONITH 负责隔离落选节点使其无法继续写，共同防止脑裂 ✓ 正确答案 D STONITH 是指主节点自动重启自己的机制，用于加快恢复
# 8. RPO 与 RTO 的业务设定，核心交易 vs 日志？ A 核心交易要求低 RPO 和低 RTO，日志类业务可容忍较高 RPO/RTO，应分级设定 ✓ 正确答案 B 所有业务都应要求 RPO=0，RTO 尽量小 C RPO/RTO 只与硬件成本有关，与业务价值无关 D 日志业务也必须用同步复制保证数据不丢
# 9. RPO（Recovery Point Objective）的定义，可容忍的数据丢失？ A RPO 指系统故障后恢复业务所需的最长时间 B RPO 与复制模式无关，任何复制都能满足 RPO=0 C RPO 指故障后可容忍的数据丢失量，RPO=0 表示不丢数据，需要同步复制保障 ✓ 正确答案 D RPO 越大，容灾方案越昂贵
# 10. 跨地域切换（Geo Failover）的流程？ A 跨地域切换无需评估异地数据状态，可直接切换 B 跨地域切换需评估异地 RPO 达成情况，切换流量并验证，回切前需确认旧主追平与双写窗口关闭 ✓ 正确答案 C 跨地域切换只涉及数据库，不涉及 DNS 和路由 D 跨地域切换可以随时随意触发，不需要演练
# 11. 跨地域容灾（Cross-Region DR）的架构，两地三中心、同城双活？ A 容灾架构只有一种，没有多种选择 B 同城双活使用异步复制，RPO 较大 C 异地灾备必须用同步复制，否则无法容灾 D 两地三中心是"同城双活 + 异地灾备"的组合，兼顾快速切换与异地兜底 ✓ 正确答案
# 12. 切换后的回滚（Rollback）策略？ A 回切期间允许新旧主同时写入，以保证可用性 B 回切不需要任何数据校验，直接切回即可 C 回切前必须先确认旧主追平数据并校验一致性，切换时关闭双写窗口避免冲突 ✓ 正确答案 D 回滚与故障切换无关，是独立操作
# 13. 数据库故障切换的 RTO 如何评估与优化，从故障检测、选主、日志补拉、路由切换各环节拆解，半同步/异步复制对 RTO 目标的影响？ A RTO 只取决于故障检测时间，与其他环节无关 B 异步复制通常比同步复制 RTO 更短 C 半同步复制一定会增加 RTO，因为要等从库确认 D RTO 由检测、选主、日志补拉、路由切换等环节累加，半同步复制让从库数据较新，可缩短补拉时间从而降低 RTO ✓ 正确答案
# 14. RPO/RTO 的实测与演练？ A RPO/RTO 是设计值，无需演练验证 B 演练只需进行一次，无需定期 C 通过故障演练实测 RTO/RPO，能发现切换脚本、补拉、路由等环节存在的问题并改进 ✓ 正确答案 D 演练目标 RTO/RPO 达不到也没关系，不影响可靠性
# 15. MHA 在 MySQL 高可用中的典型应用，它如何基于半同步复制与从库日志补偿实现自动故障切换？与 MGR、Orchestrator 相比其适用边界与局限是什么？ A MHA 是 MySQL 内置的组复制方案，无需外部协调 B MHA 通过从各从库补拉缺失 binlog 补偿日志，再提升新主，配合半同步复制降低数据丢失 ✓ 正确答案 C MHA 支持多主写入，是 MGR 的替代品 D Orchestrator 与 MHA 实现完全相同，没有区别
# 16. Orchestrator 在 MySQL 高可用中的应用，如何探测复制拓扑并执行自动切换与从库重挂，其 Raft 模式与外部协调器配合的脑裂防护设计？ A Orchestrator 通过 Raft 模式运行多个协调器节点，保证只有一个协调者决策，防止协调器层脑裂 ✓ 正确答案 B Orchestrator 不支持自动切换，只能手动操作 C Orchestrator 的 Raft 模式与脑裂防护无关 D Orchestrator 只能管理单主，无法探测复制拓扑
# 17. Patroni 在 PostgreSQL 高可用中的应用，基于 DCS 的分布式选主与防脑裂机制，与负载均衡器配合的故障转移流程如何设计？ A Patroni 通过 DCS 分布式锁和租约实现选主，保证任意时刻只有一个 leader，防止脑裂 ✓ 正确答案 B Patroni 不需要 DCS，直接在节点间随机选主 C Patroni 切换后负载均衡器无法感知，需手动改配置 D Patroni 只支持手动切换，不支持自动故障转移
# 18. Raft 的选举/日志复制/安全性如何保证一致性，与 Paxos 的工程差异是什么？ A Raft 与 Paxos 都不依赖多数派，无法保证一致性 B Raft 通过显式 Leader、任期选举、日志复制到多数派和安全性规则保证一致性，工程实现比 Paxos 更简单 ✓ 正确答案 C Paxos 有显式 Leader，实现比 Raft 简单 D Raft 允许 Leader 覆盖已提交的日志，以保证灵活性
