数据库主备复制中备用服务器刷WAL日志时是否也存在检查点？

主备复制的核心是WAL（预写日志）的同步与回放，全流程如下：

• 主节点收到业务事务请求后，先将事务的所有变更写入WAL日志，遵循WAL先写原则，只有WAL日志成功刷入磁盘后，才会给客户端返回事务提交成功的响应
• 主节点的日志发送进程会实时读取本地已刷盘的WAL日志，按照预设的同步模式（异步/半同步/强同步）发送给关联的备节点
• 备节点的日志接收进程拿到WAL日志后，先写入本地的中继日志（Relay Log）并刷盘，之后根据同步模式要求给主节点返回接收成功的ACK
• 备节点的回放进程顺序读取中继日志中的WAL记录，将对应的变更应用到本地内存的缓冲池中，完成数据同步

首先给出明确结论：PostgreSQL、MySQL等主流关系型数据库的备节点，默认都会执行检查点操作，和主节点的检查点执行逻辑没有强绑定关系

原因是检查点的核心价值在备节点上完全适用：

• 检查点会将内存缓冲池中的脏页批量刷入磁盘数据文件，同时标记已经落盘的最新WAL位点，大幅降低故障重启时需要回放的WAL长度，缩短恢复耗时
• 检查点执行后，位点之前的旧WAL、中继日志就可以被回收，避免无效占用磁盘空间
• 备节点如果长期不执行检查点，除了上述两个问题外，还会导致缓冲池脏页占比过高，影响备节点的查询性能。

备节点的检查点触发逻辑和主节点略有差异：

• 不会被本地事务提交触发：备节点默认是只读状态，没有本地写入的事务（开启可写备节点的特殊场景除外）
• 常见触发条件：检查点间隔时间达到配置阈值、缓冲池脏页占比超过上限、WAL/中继日志占用量达到配置的水位线
• 部分数据库有专属的备节点检查点优化：比如PostgreSQL开启hot_standby_feedback参数后，备节点检查点会延迟清理主节点长查询还需要用到的旧版本数据，避免备节点查询出现快照过旧的报错。

只有极特殊的归档备场景（备节点仅用于留存WAL日志，不对外提供查询、不承担故障切换职责）下，才会手动关闭备节点的自动检查点，生产环境几乎不会用到这种配置。

内容的提问来源于stack exchange，提问作者Puneet