# 1. PostgreSQL synchronous_commit 的级别，off、local、on、remote_write、remote_apply？ A synchronous_commit 各级别从 off 到 remote_apply 同步程度递增，remote_apply 要求从库已回放事务，主库提交延迟最高 ✓ 正确答案 B remote_apply 表示从库已收到但未回放 WAL，主库即可返回 C off 级别等待本地和从库都刷盘后才返回 D local 级别会等待从库刷盘，保证数据同步到从库
# 2. 半同步复制（Semi-Sync），MySQL after sync、after commit？ A after_sync 等从库 ACK 后再提交事务，消除主库崩溃时丢失已确认事务的窗口，但提交延迟略高 ✓ 正确答案 B after_commit 在等待从库 ACK 之后才提交事务，没有丢失窗口 C 半同步复制能保证 RPO 恒为 0，任何情况下都不丢数据 D after_commit 与 after_sync 只是命名不同，实现完全相同
# 3. 同步复制（Sync Replication），RPO=0 但性能下降？ A 同步复制从库故障时主库性能反而提升 B 同步复制不等待从库，性能最好但 RPO 大 C 同步复制的 RPO 与异步复制相同 D 同步复制要求主库提交前等待从库确认，RPO=0，但每个事务都要等待从库 ACK，提交延迟和吞吐受限 ✓ 正确答案
# 4. 异步复制（Async Replication），性能高但 RPO 可能丢失数据？ A 异步复制主库提交前必须等待所有从库确认 B 异步复制保证 RPO=0，因为从库总能追平 C 异步复制主库不等待从库确认，提交延迟低、吞吐高，但主库在日志未传到从库时崩溃会丢失最近事务，RPO 大于 0 ✓ 正确答案 D 异步复制的性能通常比同步复制差
# 5. 主从切换（Primary-Replica Switchover）的 Runbook 编写？ A Runbook 只需列出切换命令，无需验证和回滚步骤 B 主从切换 Runbook 应包含切换前准备、执行步骤、验证与回滚步骤，并定期演练 ✓ 正确答案 C Runbook 是同一次性的，写好后无需更新 D 计划内切换不需要 Runbook，直接执行即可
# 6. 紧急切换（Emergency Failover）的步骤？ A 紧急切换不需要评估从库数据状态，直接切换 B 紧急切换与计划内切换完全一样，没有区别 C 紧急切换必须先完整验证所有数据，再切换 D 紧急切换优先保证 RTO，可能接受受 RPO 约束的数据丢失，需快速提升新主并切换流量 ✓ 正确答案
# 7. 分片（Sharding）复制拓扑，每分片独立主从？ A 分片复制拓扑所有分片共享同一个主从复制链 B 分片复制拓扑中每个分片独立主从，实现故障隔离与水平扩展 ✓ 正确答案 C 分片后不需要复制，因为数据已分散 D 分片复制拓扑只影响读，不影响主从切换
# 8. 双主复制（Master-Master）的冲突解决，MySQL 双写、PostgreSQL BDR？ A MySQL 传统双主复制内置完善的冲突解决机制，无需额外处理 B BDR 无法处理多主写入，只能单主 C 双主复制不会产生冲突，因为主从自动分配写入 D 双主复制引入写冲突，MySQL 双写需应用层规避，PostgreSQL BDR 通过逻辑复制提供冲突检测与解决策略 ✓ 正确答案
# 9. 级联复制（Cascading Replication），主 → 中继 → 从？ A 级联复制中主库直接连接所有从库 B 级联复制能降低下游延迟，因为中继节点加速转发 C 级联复制通过中继节点转发日志，减轻主库连接压力，但会放大延迟且中继故障影响下游 ✓ 正确答案 D 级联复制的主要缺点是增加主库连接数
# 10. MySQL Group Replication（MGR）如何通过 XCom（Paxos 变体）做事务认证（certification）保证全局有序？单主与多主模式在冲突检测与写吞吐上有何差异？ A MGR 通过 XCom 共识提供全局总序，事务认证用写集合做冲突检测；单主模式无写冲突吞吐稳定，多主模式冲突检测开销大 ✓ 正确答案 B MGR 多主模式无冲突检测，写吞吐始终高于单主 C XCom 是 MySQL 的 binlog 同步协议，与共识无关 D MGR 不支持自动故障转移
# 11. Galera Cluster 的写集认证（writeset certification）如何在提交前检测跨节点冲突？流控（Flow Control）与状态传输（SST/IST）分别在何时触发？ A SST 用于增量传输，IST 用于全量传输 B Galera 的认证在提交后执行，冲突事务直接丢弃 C 流控在节点性能过剩时触发，用于加速提交 D Galera 在提交前用写集认证做跨节点冲突检测，流控在慢节点落后时触发，SST 全量/IST 增量用于节点入群或追平 ✓ 正确答案
# 12. 复制过滤（replicate-do-db/replicate-ignore-db）为何容易导致主从不一致（基于 USE 的库语义、跨库语句被漏放）？如何用 replicate-wild-do-table 基于表名过滤替代？ A 复制过滤不会导致主从不一致，可放心使用 B replicate-do-db 基于语句实际影响的表过滤，语义精确 C replicate-wild-do-table 只能过滤库，不能过滤表 D replicate-do-db 基于 USE 的库语义判断是否过滤，跨库语句可能被漏放导致主从不一致 ✓ 正确答案
# 13. 分片键（Sharding Key）的选择准则，高基数、均匀分布、业务边界？ A 分片键只要基数高即可，无需考虑分布和业务边界 B 分片键应选择高基数、均匀分布、契合业务边界，使数据均衡且查询友好 ✓ 正确答案 C 分片键的值可以频繁变化，不影响性能 D 分片键的选择与跨分片查询无关
# 14. 计划内切换（Planned Switchover）的步骤？ A 计划内切换不需要停止写流量，直接提升从库 B 计划内切换与紧急切换无区别，都是故障时快速切换 C 计划内切换从容准备、先确认从库追平、可验证可回滚，通常数据零丢失 ✓ 正确答案 D 计划内切换无法回滚，一旦执行必须完成
# 15. 一主多从（Master-Slave）拓扑的应用场景？ A 一主多从适合读多写少的业务，通过多个从库扩展读并互为容灾，但写仍是单点 ✓ 正确答案 B 一主多从能水平扩展写，写入压力可分散到多个从库 C 一主多从从库之间没有复制延迟 D 一主多从从库越多，主库发送压力越小
# 16. 再平衡（Rebalance）的实现，双倍扩容、在线迁移？ A 再平衡只需简单加机器，无需迁移数据 B 双倍扩容把分片翻倍、每片只迁移一半数据，在线迁移在不中断服务下平滑搬迁并校验 ✓ 正确答案 C 双倍扩容会迁移全部数据，影响巨大 D 在线迁移会中断服务，无法用于生产
# 17. 热点分片（Hot Shard）的检测与应对？ A 热点分片不影响整体可用性，无需处理 B 热点分片指某分片流量远超平均成为瓶颈，可通过 key 拆分、缓存、动态分片等应对 ✓ 正确答案 C 热点分片只能通过增加机器解决，无法分散 D 热点分片的检测与分片键无关
# 18. Leaf（美团点评）的号段模式与雪花模式？ A 两种模式都生成完全随机的 ID，顺序无关 B 号段模式 ID 完全不连续，需每次访问数据库 C 雪花模式依赖数据库，性能低于号段模式 D 号段模式从数据库批量取号段、ID 连续但依赖数据库；雪花模式本地生成 64 位 ID、性能高但不连续 ✓ 正确答案
# 19. 分布式全局 ID 的需求，唯一性、趋势递增、低延迟？ A 全局 ID 只需唯一，无需考虑是否递增 B 分布式全局 ID 需全局唯一、趋势递增（利于有序索引）、低延迟高可用，不同方案各有取舍 ✓ 正确答案 C UUID 生成趋势递增且有序，最适合做数据库主键 D 分布式 ID 生成必须依赖数据库，否则无法保证唯一
# 20. 雪花 ID（Snowflake）的 64 位结构与实现？ A 雪花 ID 的序列号是全局唯一的，无需机器 ID B 雪花 ID 的 41 位时间戳表示秒级，仅能使用数秒 C 雪花 ID 由 1 位符号位 + 41 位时间戳 + 10 位机器 ID + 12 位序列号组成，本地生成、趋势递增、需处理时钟回拨 ✓ 正确答案 D 雪花 ID 依赖数据库，无法本地生成
# 21. MySQL 半同步复制 after_commit 模式下主库崩溃可能丢失已确认事务？ A after_commit 与 after_sync 的崩溃行为完全相同 B after_commit 模式先等 ACK 再提交，绝不会丢数据 C 半同步复制在任何模式下都保证已确认事务不丢失 D after_commit 模式先提交再等 ACK，主库在 commit 后 ACK 前崩溃会丢失已确认事务，after_sync 消除了该窗口 ✓ 正确答案
