# 1. MySQL 中 Seconds_Behind_Master 的局限？ A 当从库 SQL 线程空闲时该值会变为 0，即使从库实际仍有未追平的数据（主库暂时无新写入时） ✓ 正确答案 B 它能精确反映从库落后主库的绝对字节数 C 该指标不依赖主从时钟，因此时钟不同步不影响其准确性 D 在多线程复制下它能精确反映每个 worker 的独立进度
# 2. PostgreSQL 中 replication lag 的监控，pg_stat_replication？ A 它通过比较主从时钟来计算复制延迟，所以时钟不同步会导致结果偏差 B 其中 replay_lag 反映的是从库到主库的网络往返耗时 C 该视图只能显示同步复制的从库状态 D write_lag、flush_lag、replay_lag 分别反映 WAL 在从库的写入、刷盘、回放三个阶段的延迟 ✓ 正确答案
# 3. 主从复制的实现，WAL 归档（PG）、binlog 复制（MySQL）？ A MySQL 的 binlog 是物理日志，记录页面级别的变更 B MySQL 复制只支持基于语句的复制，不支持行级复制 C PostgreSQL 的 WAL 归档和流复制是同一回事，没有区别 D PostgreSQL 的 WAL 是物理日志，从库通过流复制协议实时接收并重放 ✓ 正确答案
# 4. 复制延迟（Replication Lag）的成因，大事务、长 DDL、网络？ A 复制延迟只会由网络问题引起，与主库写入量无关 B 长 DDL 在主库执行后会立即完成，不会影响从库 C 主库并发写入越高，从库回放越快，永远不会出现延迟 D 大事务在从库需要逐行回放，耗时长，是导致回放延迟的常见原因 ✓ 正确答案
# 5. 逻辑复制槽（Replication Slot）的作用与失效风险？ A 复制槽在主库上保留下游所需的 WAL，防止被提前回收，但可能造成 WAL 无限堆积 ✓ 正确答案 B 复制槽用于加速从库的查询性能 C 复制槽一旦创建就永久生效，不会带来任何磁盘风险 D 复制槽只在逻辑复制中使用，物理复制不需要
# 6. 半同步复制在从库不可用时的降级（rpl_semi_sync_master_timeout）与数据丢失窗口 A 半同步复制保证事务提交后绝不丢失，RPO 恒为 0 B 当从库应答超时，主库等待 rpl_semi_sync_master_timeout 后降级为异步复制继续服务，期间存在数据丢失窗口 ✓ 正确答案 C rpl_semi_sync_master_timeout 设置越大，数据丢失窗口越小 D 半同步复制从库故障时主库会直接停止服务，不会降级
# 7. GTID 与 binlog 位点（file:pos）在故障恢复上有何本质差异？为什么 GTID 模式能避免找错位点或重复执行？ A 位点复制基于全局唯一事务标识，能自动对齐已执行事务 B GTID 模式从库通过已执行事务集合自动跳过重复事务，避免找错位点或重复执行 ✓ 正确答案 C GTID 与位点复制在故障恢复上没有任何区别 D 位点复制比 GTID 更安全，因为位点永不变化
# 8. MySQL 并行复制（MTS）如何通过事务依赖分析（writeset）提升从库回放吞吐？相比单线程 SQL 线程延迟降低的原理是什么？ A 基于 writeset 的并行复制通过判断事务写集合是否相交，让无冲突事务并发回放以提高吞吐 ✓ 正确答案 B 并行复制只支持按数据库并行，无法在单个库内并行 C 并行复制会降低从库吞吐，通常不推荐开启 D 并行复制没有依赖分析，任何事务都能随意并行
# 9. 会话亲和性（Session Affinity），同一会话路由同一从库？ A 会话亲和性把同一会话的请求固定路由到同一从库，避免会话内读到不一致数据 ✓ 正确答案 B 会话亲和性要求每个请求都轮询到不同的从库 C 会话亲和性只适用于同步复制，不适用于异步复制 D 会话亲和性能完全消除跨会话的复制延迟
# 10. 复制延迟超过业务容忍阈值时的路由降级（读主）与告警设计？ A 延迟超标时应把该从库继续保留在路由池中，以保证读扩展性 B 读主会显著提升从库压力，应尽量避免 C 延迟超过阈值时把高风险读请求降级读主，并配合分级告警 ✓ 正确答案 D 告警只需记录一次，不需要分级
# 11. 强制读主（Read Master）的应用，支付、库存强一致？ A 强制读主用于所有读请求，以保证最终一致 B 强制读主会降低一致性，只在低并发场景使用 C 支付、库存等强一致场景强制读主，避免读到从库的过期数据导致超卖或重复操作 ✓ 正确答案 D 强制读主与读从库没有区别，只是命名不同
# 12. 读写分离（Read-Write Splitting）的路由策略？ A 事务内的读操作也可以路由到从库，不影响一致性 B 读写分离不需要任何路由策略，主从自动分配 C 写操作路由到主库，读操作按类型路由到从库；事务内和强一致读应走主库 ✓ 正确答案 D 所有读请求都必须走主库，否则无法保证性能
# 13. 读写分离的延迟应对，等 GTID、读已提交延迟窗口？ A 等 GTID 会降低从库的复制速度，通常不推荐 B 延迟窗口读要求所有读都必须等待窗口结束，性能极差 C 等 GTID 通过等待指定事务在从库执行完毕，保证读己之所写 ✓ 正确答案 D 读写分离无法应对复制延迟，只能读主
# 14. 半同步复制，after_commit 与 after_sync 的区别？ A 两者没有区别，只是叫法不同 B after_sync 模式在主库提交事务之前等待从库 ACK，消除了主库崩溃时丢失已确认事务的窗口 ✓ 正确答案 C after_commit 模式延迟更低，但数据丢失窗口更大 D after_sync 只适用于异步复制，不适用于半同步
# 15. 复制中断的常见原因与恢复（SQL 线程报错、跳过事务的风险、GTID 模式下的处理） A 跳过事务可能导致主从不一致，应确认事务可安全忽略后再处理 ✓ 正确答案 B 遇到 SQL 线程报错应无条件跳过事务，越早跳过越好 C GTID 模式下不需要核对已执行事务，可直接重连 D 复制中断只能通过重建从库解决，没有其他方式
# 16. Seconds_Behind_Master 在从库空闲或时钟不同步时为何不准？pt-heartbeat 如何用心跳表实现精确延迟测量？ A pt-heartbeat 通过比较主从时钟计算延迟，时钟不同步时不准 B pt-heartbeat 在主库写入带时间戳的心跳行，从库读取该行与本地时间比较，从而精确测得复制延迟 ✓ 正确答案 C Seconds_Behind_Master 在从库空闲时依然精确 D pt-heartbeat 会干扰业务数据，不适合生产环境
# 17. 级联复制（A→B→C）为何会放大延迟？中间节点故障或重启对下游复制位点与数据追平的影响是什么？ A 级联复制中下游从库延迟会逐级叠加放大，且中间节点故障会同时影响下游所有从库 ✓ 正确答案 B 级联复制不会放大延迟，因为每级复制互不影响 C 级联复制主要用于降低读取延迟 D 中间节点重启不会影响下游复制位点
# 18. 主从数据一致性校验（pt-table-checksum 等）如何发现复制漂移并修复？ A pt-table-checksum 按主键切分块计算校验和并对比，定位差异后可用 pt-table-sync 以主库为基准修复 ✓ 正确答案 B pt-table-checksum 直接修改从库数据来修复漂移 C 复制漂移只能通过重建从库解决，无法校验 D pt-table-checksum 会全表加锁，不适用于生产
# 19. 在从库执行备份（逻辑/物理）的 IO 影响与调度 A 从库备份不会影响从库的复制回放 B 备份只能在主库执行，从库无法备份 C 从库备份会与复制回放争抢 IO，应错峰调度并适当限速 ✓ 正确答案 D 物理备份不会占额外空间，总比逻辑备份好
