标准答案
- WAL 遵循 write-ahead 原则：相关数据页落盘前，对应的变更记录应先达到要求的持久化位置，崩溃恢复时再按顺序重放。
- 物理复制传输 WAL，让副本在自己的数据文件上重放主库变化；基础备份加连续 WAL 归档，才构成时间点恢复所需的链路。
- WAL 增长可能来自写入量增加、归档失败、复制槽保留、消费者落后或长事务，必须查看各类 LSN 和归档状态确定来源。
- synchronous_commit、同步复制、存储设备和故障范围会影响提交确认的持久性语义；commit 返回不等于所有副本都已确认。
- WAL 不是独立全量备份。恢复还需要可用的基础备份、连续归档、保留策略、密钥和扩展信息，以及真实恢复演练。
题目解析
WAL 把“数据页什么时候写入”和“变更什么时候可以恢复”解耦，换取了更稳定的崩溃恢复和复制路径，但也引入日志保留、归档和复制延迟的运营成本。
线上 WAL 暴涨不能只看写入量。归档失败、复制槽或副本停止消费，都会让主库保留更多日志；不同根因的修复动作可能分别是修归档、恢复消费者或清理无主槽。
恢复能力的验收要以目标时间点能否还原、RPO/RTO 是否达标为准，而不是以“WAL 文件还在”或“副本连接正常”为准。
常见误区
- 误区：把 WAL 当作独立全量备份。改正：WAL 需要基础备份作为恢复起点，并且必须连续、完整、可读取。
- 误区：复制槽保留越久越安全。改正：槽会把消费者故障转化为主库磁盘压力，必须监控滞后并设置处理策略。
- 误区：看到 commit 成功就认为多副本已确认。改正：要结合 synchronous_commit、同步复制配置和实际副本确认位置判断。