# 1. 物理备份（Physical Backup），文件系统级快照、pg_basebackup、Percona XtraBackup？ A 物理备份无法在线执行 B 物理备份导出逻辑数据，粒度小 C 物理备份直接复制数据文件，pg_basebackup/XtraBackup 分别用 WAL/redo 保证一致性，恢复快 ✓ 正确答案 D 物理备份跨平台可移植性最好
# 2. 逻辑备份 vs 物理备份的取舍，粒度、可移植性、恢复速度？ A 两种备份恢复速度完全相同 B 逻辑备份恢复速度比物理备份快 C 物理备份可移植性最好 D 物理备份恢复快但可移植性差，逻辑备份可移植性好但恢复慢，大库以物理备份为主 ✓ 正确答案
# 3. 逻辑备份（Logical Backup），pg_dump、mysqldump 的实现与差异？ A pg_dump 默认 MVCC 快照一致，mysqldump 需 --single-transaction 或 FTWRL 保证一致 ✓ 正确答案 B mysqldump 默认就保证一致，无需选项 C pg_dump 无法导出数据，只能导出结构 D 两者都强制阻塞写入
# 4. MySQL 中基于 binlog 的增量备份，binlog 格式（ROW、STATEMENT、MIXED）？ A MIXED 恒用 STATEMENT，无法用 ROW B STATEMENT 格式记录行级变更，最精确 C ROW 格式记录行级变更最精确，支持闪回/CDC，是增量备份推荐格式 ✓ 正确答案 D binlog 格式与增量备份无关
# 5. PostgreSQL 中基于 WAL 的增量备份，archive_command、pg_receivewal？ A pg_receivewal 依赖服务器 shell 命令 B 两者都只能用于逻辑备份 C archive_command 是服务器推 WAL 归档，pg_receivewal 是客户端流式拉取，都用于增量备份 ✓ 正确答案 D WAL 归档与增量备份无关
# 6. 全量备份（Full Backup）的实现，完整数据快照？ A 全量备份频率应高于增量备份 B 全量备份只备份部分数据，不完整 C 全量备份是数据库完整数据快照，作为恢复基线，频率较低并配合增量备份 ✓ 正确答案 D 全量备份与恢复无关
# 7. 增量备份（Incremental Backup）的实现，基于 WAL、binlog？ A 增量备份基于 WAL/binlog 归档变更日志，恢复 = 全量 + 回放日志，减少备份窗口 ✓ 正确答案 B 增量备份复制全部数据文件 C 增量备份恢复无需全量 D 增量备份比全量备份占用空间更大
# 8. 差异备份（Differential Backup）的实现，基于上次全量？ A 差异备份恢复需要回放所有差异 B 差异备份只包含上次备份后的变更，与增量备份相同 C 差异备份体积随全量间隔增长而减小 D 差异备份累积上次全量以来的所有变更，恢复只需全量+最后一个差异，简单快速 ✓ 正确答案
# 9. MySQL binlog 增量备份？ A 全量备份 + 连续归档 binlog，恢复时回放 binlog 实现增量/时间点恢复 ✓ 正确答案 B binlog 增量备份只需 binlog，无需全量 C binlog 格式与增量备份无关 D binlog 只能用于主从复制，不能用于备份
# 10. PostgreSQL WAL 增量备份？ A 基础备份做基线，WAL 归档记录变更，恢复时回放 WAL 到目标点实现增量恢复 ✓ 正确答案 B WAL 增量备份只需 WAL，无需基线 C WAL 只能用于流式复制，不能用于备份 D WAL 归档与恢复无关
# 11. MySQL Binlog 的作用，复制、恢复、CDC？ A binlog 只用于复制，不用于恢复 B binlog 记录变更，用于复制、增量恢复与 CDC 数据集成 ✓ 正确答案 C binlog 无法用于 CDC D binlog 与逻辑备份无关
# 12. PostgreSQL WAL（Write-Ahead Log）的作用，崩溃恢复、复制、PITR？ A WAL 只用于崩溃恢复，与复制无关 B WAL 先写日志再写数据，支撑崩溃恢复、流式复制与 PITR ✓ 正确答案 C WAL 无法用于 PITR D WAL 级别与功能无关
# 13. Redo Log（MySQL InnoDB）的作用与实现？ A redo log 与数据文件无关 B redo log 是逻辑日志，记录 SQL 语句 C redo log 用于复制，不用于崩溃恢复 D redo log 物理记录页变更用于崩溃恢复，循环写入，与 binlog 的逻辑记录分工不同 ✓ 正确答案
# 14. WAL 与 Binlog 的差异，物理日志 vs 逻辑日志？ A binlog 用于崩溃恢复，WAL 用于复制 B WAL 是逻辑日志，binlog 是物理日志 C 两者都是物理日志，记录完全相同 D WAL 是物理日志记录页变更用于崩溃恢复，binlog 是逻辑日志记录变更用于复制/CDC ✓ 正确答案
# 15. WAL Redo Binlog 在 PostgreSQL、MySQL、Oracle、SQL Server 中的实现差异与兼容性？ A Oracle 与 MySQL 的 redo 完全兼容 B 所有数据库的日志完全相同，可互换 C 物理日志可移植性最好，可跨库使用 D 各库日志物理/逻辑格式与机制不同，物理日志互不兼容，逻辑日志可跨库同步 ✓ 正确答案
# 16. WAL Redo Binlog 的崩溃恢复时间与 checkpoint 频率、wal segment size 的关系？ A checkpoint 频率与恢复时间无关 B checkpoint 越频繁恢复需重放的 WAL 越少恢复越快，但频繁 checkpoint 有性能开销 ✓ 正确答案 C WAL segment size 越大恢复越慢，与 checkpoint 无关 D 恢复时间只取决于数据量，与 checkpoint 无关
# 17. WAL 级别（PostgreSQL），minimal、replica、logical？ A minimal 仅崩溃恢复，replica 支持复制与 PITR，logical 增加逻辑解码/CDC ✓ 正确答案 B 三种级别记录内容完全相同 C minimal 支持流式复制 D logical 级别开销最小
# 18. WAL Redo Binlog 的 page LSN 与 buffer pool dirty page flush 的协调机制？ A checkpoint 不参与 LSN 协调 B LSN 与刷盘无关，只用于日志 C 所有脏页都必须无条件重放 redo D 页 LSN 标记载修改位置，checkpoint 与 flush 推进刷盘，恢复时按 LSN 比对重放未落盘的 redo ✓ 正确答案
# 19. WAL Redo Binlog 的 log sequence 在主从复制（streaming replication）中的应用？ A 从库无法感知落后多少 B 复制不依赖任何位置号 C log sequence 只用于崩溃恢复 D log sequence（LSN/binlog position）是复制进度坐标，主从按它对齐应用顺序与检测滞后 ✓ 正确答案
# 20. WAL Redo Binlog 的 partial page write（torn write）问题与 doublewrite 的解决？ A redo log 可以直接恢复 torn page，无需 doublewrite B doublewrite 导致页更容易撕裂 C torn write 是页写一半导致的撕裂，doublewrite 先写双写缓冲再写数据文件保证页原子性 ✓ 正确答案 D torn write 与崩溃恢复无关
# 21. WAL Redo Binlog 在 InnoDB redo log、PostgreSQL WAL、SQL Server transaction log 的格式差异？ A 三种日志都只记录逻辑变更 B 三种日志格式完全相同 C InnoDB redo 与 PG WAL 记录物理页变更，SQL Server 结合事务与页，格式互不兼容 ✓ 正确答案 D 日志格式差异不影响跨库使用
# 22. WAL Redo Binlog 的 logical decoding（pgoutput、wal2json）在 CDC 场景中的应用？ A 逻辑解码只能用于物理复制，不能用于 CDC B 逻辑解码把 WAL 解析为行级变更事件，pgoutput/wal2json 输出，用于 CDC 实时同步 ✓ 正确答案 C wal2json 是内置插件，用于崩溃恢复 D 逻辑解码不需要 wal_level=logical
# 23. MySQL PITR 的实现，全量备份 + binlog 回放？ A PITR 只需 binlog，无需全量 B PITR 用全量备份恢复基线，再回放 binlog 到目标时间点实现时间点恢复 ✓ 正确答案 C PITR 回放 binlog 到任意时间，无需起止点 D PITR 与误删恢复无关
# 24. PITR 的目标时间（Target Time），如何精确定位？ A PITR 只能恢复到备份时刻，无法定位任意时间 B 可用时间戳、日志位置或事务 ID 精确定位，注意回放到目标事务之前避免恢复过头 ✓ 正确答案 C 目标时间定位与事务边界无关 D 只能按时间戳定位，无法用位置
# 25. PITR（Point-in-Time Recovery）的概念，恢复到任意时间点？ A PITR 无需日志归档 B PITR 只能恢复到最近一次备份 C PITR 用全量备份 + 日志回放到目标时间点，实现恢复到任意时间点 ✓ 正确答案 D PITR 只能用于表结构变更
# 26. PostgreSQL PITR 的实现，base backup + WAL 归档 + PG 12+ 的 recovery.signal/standby.signal？ A PITR 无需 base backup B recovery.signal 与 standby.signal 功能相同 C PG 12+ 仍用 recovery.conf 配置 D base backup 恢复基线，WAL 回放，recovery.signal 触发 PITR 恢复，standby.signal 触发备机模式 ✓ 正确答案
# 27. 误删恢复（DROP TABLE、TRUNCATE）的应急流程？ A 误删后直接继续写入，无需止血 B 先停止写入止血，再用 PITR/备份/闪回到误删前时间点，并校验一致性 ✓ 正确答案 C 误删只能靠重装，无法恢复 D 延迟从库对误删恢复无用
# 28. 如何用延迟从库（MySQL CHANGE REPLICATION SOURCE SOURCE_DELAY、PostgreSQL recovery_min_apply_delay）预留误删恢复窗口？它有哪些局限（延迟期内无法用于读、磁盘仍占用）？ A 延迟从库不占磁盘空间 B 延迟从库不影响读，延迟期数据最新 C 延迟从库用复制滞后提供误删恢复窗口，但延迟期读不可用且磁盘占用、窗口有限 ✓ 正确答案 D 延迟从库可提供无限恢复窗口
# 29. binlog 闪回工具（binlog2sql --flashback、MyFlash）如何把 ROW 事件反向生成回滚 SQL？使用前提（ROW 格式、完整镜像）与上线前验证流程是什么？ A 闪回依赖 ROW 格式的 before/after 镜像反向生成回滚 SQL，前提是 ROW 格式与完整镜像 ✓ 正确答案 B STATEMENT 格式也能支持闪回 C 闪回无需验证，直接在生产执行 D 闪回适合全表 DROP 恢复
# 30. PITR 的性能影响与 RTO/RPO 评估？ A RPO 由全量备份频率决定，与日志无关 B RPO 由日志归档频率决定，RTO 由全量恢复+日志回放速度决定，需平衡性能与目标 ✓ 正确答案 C 归档频率越高性能开销越小 D RTO 与日志回放速度无关
# 31. 如何估算 PITR 恢复时长（全量还原速度 + 日志回放速率）？并行回放（MySQL 基于 logical clock 的 MTS、PostgreSQL 16+ 逻辑复制并行应用）如何缩短 RTO？ A 恢复时长与回放速率无关 B 恢复时长 = 全量还原 + 日志回放，MySQL MTS 与 PG 逻辑复制并行应用加速日志应用缩短 RTO ✓ 正确答案 C 并行回放会降低恢复速度 D 日志回放无法加速
# 32. PITR 的常见误区（在备份恢复与 PITR 范畴内）？ A 常见误区是重备份轻恢复验证，如忽略日志归档、不测恢复、不监控归档连续性 ✓ 正确答案 B 有全量备份即可任意时间点恢复 C 备份无需验证恢复能力 D 日志归档丢失不影响 PITR
# 33. 备份保留策略，3-2-1 原则（3 份副本、2 种介质、1 份异地）？ A 备份只需一份副本，无需多样介质 B 只需 1 份备份即可 C 3-2-1 原则与异地备份无关 D 3 份副本、2 种介质、1 份异地，抵御介质故障与区域故障 ✓ 正确答案
# 34. 备份校验，checksum、pg_verifybackup、xtrabackup --prepare？ A 备份校验只在恢复时进行 B 备份无需校验，直接存放即可 C checksum 只能用于逻辑备份 D checksum 验完整性，pg_verifybackup 校验 PG 备份，xtrabackup --prepare 使备份一致可恢复 ✓ 正确答案
# 35. 备份演练（DR Drill）的必要性，定期恢复测试？ A 备份无需演练，存在即可恢复 B 定期恢复测试验证备份可用性与恢复流程，避免"备份存在但关键时刻无法恢复" ✓ 正确答案 C 演练只需一次，无需定期 D 演练只能验证备份大小，无法验证恢复
# 36. 备份加密（Encryption）的实现，pg_dump 加密、文件系统加密？ A 应用层加密与文件系统加密完全相同 B 备份无需加密，数据不会泄露 C 应用层加密粒度细但需密钥管理，文件系统加密透明，可组合使用，密钥可丢失最重要 ✓ 正确答案 D 密钥丢失不影响备份解密
# 37. 备份压缩（Compression）的实现，gzip、zstd、lz4 的取舍？ A zstd 兼顾压缩率与速度，lz4 快但压缩率低，gzip 兼容性最好但速度慢 ✓ 正确答案 B lz4 压缩率最高 C gzip 压缩速度最快 D 三种算法压缩率与速度完全相同
# 38. 异构数据库迁移的 Schema 转换，数据类型、函数、存储过程？ A 存储过程语法兼容，无需调整 B 各库数据类型完全相同，无需转换 C 函数可原样使用，无需重写 D 数据类型按映射表转换，函数按语义等价重写，存储过程按语法重写，需工具+人工校验 ✓ 正确答案
# 39. 跨平台迁移（Cross-Platform Migration）的实现，Oracle → PostgreSQL、MySQL → PostgreSQL？ A 迁移无需验证即可切换 B 跨平台迁移可直接复制数据文件 C Oracle 与 PostgreSQL 语法完全兼容 D 跨平台迁移经评估、Schema 转换、数据迁移、应用改造、验证切换，工具+人工适配 ✓ 正确答案
# 40. 快照的崩溃恢复，crash-consistent snapshot？ A crash-consistent 快照无需数据库恢复 B crash-consistent 快照保证应用层也一致 C 该快照无法用于数据库备份 D 是存储层一致的快照，数据库靠自身的 WAL/redo 崩溃恢复机制恢复到一致状态 ✓ 正确答案
# 41. 云数据库的快照（Snapshot）机制，AWS RDS、阿里云 RDS？ A 云快照必须停机才能创建 B 云快照是托管存储级备份，支持自动/手动、恢复到新实例、跨区域复制与 PITR ✓ 正确答案 C 云快照只能恢复到原实例 D 云快照无法用于 PITR
# 42. Percona XtraBackup 的应用？ A XtraBackup 在线热备物理备份，应用 redo 保证一致，适合大库快速备份与恢复 ✓ 正确答案 B XtraBackup 必须停库才能备份 C XtraBackup 是逻辑备份工具，恢复慢 D XtraBackup 无法配合 binlog 做 PITR
# 43. AWS Database Migration Service（DMS）的应用？ A DMS 只能用于同构迁移 B DMS 提供全量迁移 + CDC 持续同步，支持同构/异构迁移与 Schema 转换 ✓ 正确答案 C DMS 无法持续同步，只能一次性迁移 D DMS 不需要 Schema 转换工具
# 44. 数据库快照与文件系统快照的协同，frozen filesystem？ A 快照无需任何一致性处理 B 文件系统快照天然应用一致，无需冻结 C frozen filesystem 与数据库一致性无关 D 快照前冻结文件系统（frozen）并配合数据库冻结，得到一致快照，避免捕捉部分写入 ✓ 正确答案
# 45. 文件系统快照（LVM、ZFS、Btrfs）的一致性保证？ A LVM/ZFS/Btrfs 快照保证文件系统一致，但数据库层面需配合冻结/checkpoint 才应用一致 ✓ 正确答案 B 文件系统快照天然保证数据库一致 C COW 快照与应用一致无关 D 文件系统快照无需数据库配合
# 46. mysqldump 的应用边界，--single-transaction 与 FTWRL 的一致性差异，大库为何改用物理备份，异构迁移与逻辑导数据中的适用场景？ A --single-transaction 用 MVCC 快照不阻塞写，FTWRL 全局锁阻塞写，大库因逻辑导出慢改用物理备份 ✓ 正确答案 B mysqldump 适合大库快速备份 C --single-transaction 与 FTWRL 完全等价 D mysqldump 可替代所有备份
# 47. pg_basebackup 的应用？ A pg_basebackup 是逻辑备份工具 B pg_basebackup 必须停库才能执行 C pg_basebackup 在线生成一致的基础备份，用于全量备份、搭从库、PITR 基线 ✓ 正确答案 D pg_basebackup 无法配合 WAL 归档
# 48. pg_dump/pg_dumpall 的应用边界，逻辑备份的一致性快照与并行导出，为什么它不能替代 WAL 归档实现时间点恢复（PITR）？ A pg_dump 强制阻塞写入 B pg_dump 可替代 WAL 归档实现时间点恢复 C pg_dump 用 MVCC 快照导出逻辑数据，但只含备份时刻，无法替代 WAL 归档实现 PITR ✓ 正确答案 D pg_dumpall 与 pg_dump 功能完全相同
# 49. WAL 的写入路径，先写日志再写数据？ A 崩溃恢复不依赖 WAL B 先写数据页再写 WAL，效率更高 C WAL 与数据页写入顺序无关 D 先持久化 WAL 再更新数据页，崩溃时靠 WAL 重放恢复，是持久性与恢复的基础 ✓ 正确答案
# 50. PG 12 移除 recovery.conf 后，恢复/备机配置如何迁移到 postgresql.conf 配合 recovery.signal/standby.signal？ A signal 文件与恢复无关 B PG 12 仍用 recovery.conf 配置 C 恢复参数并入 postgresql.conf，recovery.signal 触发恢复模式，standby.signal 触发备机模式 ✓ 正确答案 D 恢复参数无需迁移，自动生效
# 51. 演练的频率与窗口，月度 vs 季度？ A 所有业务都用同样的低频率 B 演练频率越高越好，不考虑成本 C 演练频率按业务重要性与变更频率权衡，核心业务月度、一般业务季度，演练后复盘整改 ✓ 正确答案 D 演练与业务重要性无关
# 52. 演练的指标，RTO、RPO 的实测？ A 演练实测 RTO（恢复耗时）与 RPO（数据丢失量），与目标对比驱动优化 ✓ 正确答案 B 演练只需确认备份存在，无需测指标 C RTO 与 RPO 无法实测 D 演练指标与容灾能力无关
# 53. Btrfs 快照与子卷的关系，快照写时复制与碎片化的代价如何权衡？ A 快照越多性能越好 B COW 快照不产生任何写放大 C 快照是子卷的 COW 副本，节省空间但带来碎片化与写放大，需权衡保留数量 ✓ 正确答案 D 碎片化与快照无关
# 54. LVM 快照的实现原理（COW）与适用场景，快照空间耗尽的风险如何管理？ A LVM 快照用 COW 保留被修改的旧块，快照区空间取决于修改量，耗尽会失效需监控清理 ✓ 正确答案 B LVM 快照区空间取决于原卷大小，不会耗尽 C COW 快照与原卷修改无关 D 快照失效无需管理
# 55. ZFS 快照的 COW 机制与克隆/回滚能力，快照保留策略如何设定？ A ZFS 快照无法回滚 B ZFS 快照创建时就要复制全部数据 C ZFS 快照 COW 零成本共享数据，支持克隆/回滚，保留策略需平衡空间与恢复需求并定期清理 ✓ 正确答案 D ZFS 快照保留策略无需考虑空间
