PostgreSQL 从库也有检查点, 只不过它叫restartpoint

本期播客

PostgreSQL 从库也有检查点, 只不过它叫restartpoint

你知道吗? PG 从库也有检查点, 它叫restartpoint, 让我们来深入了解一下.

物理从库（standby）没有自己的检查点（checkpoint），但有类似的机制称为重启点（restartpoint）  。

从库需要做restartpoints的原因

从库需要执行restartpoints主要有以下几个原因：

1. 控制WAL文件增长：restartpoints会回收不再需要的WAL段文件，防止pg_wal目录无限增长

2. 优化恢复性能：通过定期将状态刷新到磁盘并更新pg_control文件，避免在崩溃恢复时需要重新扫描大量WAL数据

3. 资源管理：与主库的checkpoint类似，restartpoints也会触发脏缓冲区的刷新和同步操作

设计原因

这种设计的原因是：

• 恢复模式限制：在恢复模式下，不能创建新的checkpoint记录，只能在现有的checkpoint记录位置执行restartpoint

• 保持一致性：restartpoints确保从库的状态与主库的checkpoint保持同步，同时允许从库独立管理本地资源

主库checkpoint与从库回放的关系

主库的checkpoint在从库回放时，从库不一定会同时执行checkpoint：

1. 时机不同步：从库只有在回放到主库的checkpoint记录时，才能执行restartpoint

2. 触发条件：restartpoints由时间调度或WAL大小触发，但受限于可用的checkpoint记录位置

3. 性能考虑：频繁的restartpoints会影响恢复性能，因此从库会根据实际情况调整执行频率

在恢复期间，checkpointer进程仍然活跃并执行restartpoints，但执行的是restartpoint而非新的checkpoint   。

Notes

• restartpoints的频率受checkpoint_timeout参数控制，但实际执行频率可能低于主库的checkpoint频率
• 从库的restartpoints不会创建新的WAL记录，只是更新本地状态和回收WAL文件
• 在备份场景中，从库的增量备份依赖于最近的restartpoint位置

另外, restartpoint必须对应主库的某个checkpoint记录，但不是一一对应的关系。从库的restartpoint数量通常少于主库的checkpoint数量   。

Restartpoint与Checkpoint的关系

1. 依赖关系

Restartpoint只能在主库的checkpoint记录位置执行，这意味着从库必须先回放到主库的checkpoint记录才能执行restartpoint   。

2. 执行条件

即使回放到checkpoint记录，从库也可能跳过restartpoint执行：

• 时间条件：必须距离上次restartpoint至少checkpoint_timeout秒
• 重复检查：如果上次restartpoint已经基于当前checkpoint记录，则跳过
• 失败重试：如果上次restartpoint失败，15秒后重试

3. 统计计数

从库的统计视图区分了不同类型的restartpoint计数：

• restartpoints_timed：按时间调度的restartpoint
• restartpoints_req：按请求触发的restartpoint
• restartpoints_done：实际执行的restartpoint

实际场景示例

主库发生3次checkpoint，从库可能只执行1次restartpoint的情况：

1. 第一次checkpoint：从库回放并执行restartpoint
2. 第二次checkpoint：从库回放但时间未到checkpoint_timeout，跳过
3. 第三次checkpoint：从库回放且时间已到，执行restartpoint

这种设计确保从库既能控制WAL增长，又避免过于频繁的磁盘操作   。

Notes

• 从库的CHECKPOINT命令实际执行的是restartpoint而非新的checkpoint
• 在高WAL生成场景下，restartpoints_req计数可能快速增长，但实际执行的restartpoints_done较少