Recovery未完成时正常停机为何会阻塞并触发检查点？

Question

在 PostgreSQL 中，当实例因崩溃重启后处于 recovery 状态（即正在回放 WAL 日志、恢复一致性），此时若执行 `pg_ctl stop -m fast` 或 `SIGTERM` 正常停机，进程会**阻塞等待 recovery 完成**，而非立即终止。这是因为：PostgreSQL 要求 shutdown 前必须确保数据状态可持久化且无未决重做操作；若 recovery 未完成，系统尚处于“非一致性但正在趋向一致”的中间态，直接停机会导致下一次启动仍需从更早位置重放 WAL，甚至引发恢复失败或数据不一致风险。因此，主控进程会主动等待 recovery 结束，并在退出前强制触发一次 **checkpoint**——确保所有已恢复的脏页刷盘、更新控制文件中的检查点记录，使 shutdown 后的状态具备完整可恢复性。该行为虽保障了数据安全性，但在长 recovery 场景（如大量 WAL 积压）下易被误判为“卡死”。可通过 `pg_stat_progress_recovery` 视图监控进度，避免误操作。

Answer 1

```html

一、现象层：为什么 pg_ctl stop -m fast 在 recovery 中“卡住”？

当 PostgreSQL 因崩溃重启进入 recovery 状态（即 WAL 日志回放阶段），执行 pg_ctl stop -m fast 或向主进程发送 SIGTERM 时，不会立即终止，而是阻塞等待 recovery 完成。这不是 bug，而是设计契约——PostgreSQL 将“shutdown 可恢复性”置于操作响应性之上。该行为在 postmaster 主控进程中硬编码实现：ShutdownSignalHandler() 检测到 RecoveryInProgress() 为真时，自动转入等待循环，直至 RecoveryIsComplete() 返回 true。

二、机制层：阻塞背后的三重保障逻辑

• 一致性守门人：recovery 是从崩溃点重建事务一致性的唯一路径；中断将导致控制文件中 checkpoint_location 与实际数据页状态错位；
• 持久化兜底策略：shutdown 前强制触发 CreateCheckPoint(CHECKPOINT_IMMEDIATE | CHECKPOINT_WAIT)，确保所有已 replay 的缓冲区脏页落盘，并更新 pg_control 中的 checkPointCopy.redo；
• WAL 连续性锚点：checkpoint 记录定义了下一次启动的最小恢复起点；若跳过，新启动可能从更早 WAL 位置重放，引发 invalid record length 或 could not locate a valid checkpoint record 错误。

三、可观测性：如何确认是否真在“卡死”还是正常等待？

使用以下系统视图实时诊断：

视图	关键字段	用途
pg_stat_progress_recovery	phase, total_records, records_done, percent_done	显示当前 recovery 阶段（如 reading WAL, applying WAL）、已处理/总量 WAL 记录数及进度百分比
pg_stat_replication	state, recovery_mode	仅对 standby 有效，但可交叉验证 recovery_mode = t 表明处于恢复态

四、实操验证：模拟长 recovery 并观察 shutdown 行为

-- 步骤1：人为制造大量 WAL（例如批量插入 1000 万行并禁用 checkpoint）
SET synchronous_commit = 'off';
INSERT INTO big_table SELECT generate_series(1,10000000);

-- 步骤2：kill -9 postmaster 强制崩溃
-- 步骤3：重启，观察日志中 "database system was interrupted; last known up at ..."
-- 步骤4：另起终端执行：pg_ctl stop -m fast && echo "sent"
-- 步骤5：同时监控：SELECT * FROM pg_stat_progress_recovery;

五、深度解析：源码级行为链路（PostgreSQL 15+）

flowchart LR
A[收到 SIGTERM] --> B{RecoveryInProgress?}
B -- Yes --> C[进入 WaitForRecoveryToEnd]
C --> D[轮询 CheckForRecoveryEnding]
D --> E{RecoveryIsComplete?}
E -- No --> D
E -- Yes --> F[CreateCheckPoint\nCHECKPOINT_IMMEDIATE|WAIT]
F --> G[更新 pg_control\n写入最新 redo LSN]
G --> H[退出进程]

六、风险警示：绕过等待的“伪解决方案”及其后果

• 错误做法：用 kill -9 强杀 postmaster —— 导致 pg_control 中 state = IN_CRASH_RECOVERY 残留，下次启动仍需全量 recovery，且可能因 WAL 断链失败；
• 错误做法：修改 recovery.conf（或 postgresql.auto.conf）删除 standby_mode = on 后 reload —— 触发 promote，但此时数据未完全 replay，产生逻辑不一致；
• 正确前提：任何干预必须以 pg_stat_progress_recovery.percent_done 持续增长为依据，而非单纯等待时间。

七、高阶调优：缩短 recovery 时间的生产级策略

避免“等待焦虑”的根本在于压缩 recovery 时长：

• WAL 归档优化：启用 wal_compression = on 减少磁盘 I/O 压力；
• Checkpoint 调优：增大 max_wal_size（如 4GB）+ 降低 checkpoint_timeout（如 15min），使崩溃前 checkpoint 更密集，缩小 recovery 起点偏移；
• 并行 replay：PostgreSQL 12+ 支持 max_worker_processes 和 max_parallel_workers 提升 WAL 应用并发度（需配合 wal_level = replica）；
• 硬件协同：将 pg_wal 和数据目录置于不同高速 NVMe 设备，消除 I/O 争用。

八、架构启示：recovery-shutdown 耦合体现的 ACID 工程哲学

PostgreSQL 将 shutdown 视为 recovery 生命周期的自然终点，而非独立操作——这本质是 原子性（Atomicity）与持久性（Durability）在运维接口层的具象化。它拒绝用“可用性妥协”换取“操作便捷性”，要求 DBA 必须理解：数据库不是黑盒服务，而是状态机。每一次 pg_ctl stop 都是对当前物理一致性的最终确认签名。这种设计使 PG 在金融核心账务等场景中获得信任，但也要求团队具备 WAL 生命周期建模能力。

```