跳转到主要内容

archive_mode

archive_mode：允许使用 archive_command 归档 WAL 文件。实测在档范围为 PG9.0–19 Beta 3；最后在档的 PG19 Beta 3 启动默认值为 off，context 为 postmaster。这是测试版快照事实，PostgreSQL 19 正式发布前仍可能变化。
说明

Fact — 官方简述译文：允许使用 archive_command 归档 WAL 文件。

身份

类型 值enum
上游 pg_settings 类型
Context 值postmaster
修改后需要重启数据库
单位 值—
原始单位
范围 值—
最后在档版本的原始上下限
枚举值 值always, on, off
非枚举类型记为 —
分类 值Write-Ahead Log / Archiving
上游分类
最后 boot 值 值off
off

生命周期

Fact 值
首次观测 PG9.0（研究下界）
在档版本 PG9.0–19 Beta 3
移除版本 否
引入提交 不作断言：早于 PG9.0 研究边界
提交日期 —
Discussion —

默认值变迁

PG9.0–19 Beta 3 实测 boot 默认值
版本 原始 boot_val 单位 人类可读值
PG9.0–19 Beta 3 off — off

机制详解

启用后，PostgreSQL 会运行 WAL 归档进程，并在段文件可被回收之前将每个已完成段交给 archive_command，或在支持版本中交给 archive_library。模式与命令或库相互独立，因此归档逻辑可以重载而无需退出归档模式。

在普通主库运行期间，on 与 always 没有区别。在恢复或备库模式下，on 不归档收到的 WAL，而 always 还会归档从归档恢复或通过流复制收到的段。

打开该模式并不能证明归档健康或可恢复。命令失败会让 WAL 在 pg_wal 中积累；错误地返回成功会造成不可恢复的 WAL 链。时间点恢复还需要合适的基础备份和经过验证的恢复流程。

调优建议

提示

Advice。 以下建议是工作负载起点，必须用真实测量验证。

场景 建议
OLTP 只为明确的 PITR 或日志传送需求启用，并使用可靠、幂等的归档实现。监控 pg_stat_archiver 失败、最新归档时间和 pg_wal 增长；恢复演练比命令返回成功更有说服力。
OLAP 按批量导入的 WAL 峰值规划归档带宽和目标容量。归档跟不上时，应节流或错峰批任务，而不是放任 pg_wal 写满。
小规格 只有理解保留策略和恢复步骤时才使用 pgBackRest 等托管工具。对于可随时重建的数据库，应保持关闭，而不是配置一个占位归档命令。

Pigsty 取值

以下值来自固定 8 核、32 GiB、100 GiB SSD 夹具，并按 PG19 Beta 3 渲染当前 Pigsty 模板；这不表示 Pigsty 当前支持该历史或测试版本。

模板 有效值 与上游 boot 比较 源表达式
OLTP on 不同于 boot 值 'on'
OLAP on 不同于 boot 值 'on'
CRIT on 不同于 boot 值 'on'
TINY on 不同于 boot 值 'on'
注意

Advice — 待人工复核。 当前 Pigsty 模板投影事实：OLTP: PG9.0–19 Beta 3 = on (dcs)；OLAP: PG9.0–19 Beta 3 = on (dcs)；CRIT: PG9.0–19 Beta 3 = on (dcs)；TINY: PG9.0–19 Beta 3 = on (dcs)。 建议（待人工复核）——发布前应结合当前 Pigsty 模板及其实际支持的 PostgreSQL 版本确认运维意图。

常见坑

  • 启用 archive_mode 却使用空命令或失败命令，最终写满 pg_wal。
  • 使用 /bin/true 一类虚假成功命令，破坏可恢复的 WAL 链。
  • 误以为 archive_mode 可重载；修改它需要重启服务器。
  • 把 WAL 归档当作基础备份和恢复演练的替代品。
  • always 模式写共享归档时没有处理重复文件和并发竞态。

archive_command · archive_library · archive_timeout · wal_level · restore_command · max_wal_size

参考资料

最后修改 2026-09-11