适用场景

PostgreSQL 在政务与行业系统里越来越多。它的运维重点和 MySQL 不同：WAL 归档决定能不能做时间点恢复，VACUUM 决定性能会不会随写入退化，连接数模型决定高峰会不会被打爆。

配置步骤（备份与时间点恢复）

# 1) 基础备份
su - postgres -c "pg_basebackup -D /backup/pg/base_$(date +%Y%m%d) -Ft -z -P -X stream"

# 2) 确认 WAL 归档在跑
su - postgres -c "psql -c 'select * from pg_stat_archiver;'"

# 3) 时间点恢复（在隔离环境）
#    a. 解包基础备份到新数据目录
#    b. 配置 restore_command 指向归档目录
#    c. 设置 recovery_target_time = '2026-09-26 10:00:00'
#    d. 创建 recovery.signal 后启动
#    e. 恢复完成后校验数据，再置为可写

# 4) 逻辑备份兜底（单库/表）
# pg_dump -Fc -d appdb -f /backup/pg/appdb_$(date +%Y%m%d).dump

关键参数与建议

  • 部署：数据目录与 WAL 目录分离，参数按内存设置（shared_buffers、work_mem、effective_cache_size）
  • WAL 归档：开启 archive_mode，归档目录独立并定期清理；没有归档就只能恢复到全备点
  • 备份：pg_basebackup 做基础备份 + WAL 归档 = 时间点恢复；逻辑备份用 pg_dump 兜底
  • 恢复验证：定期用基础备份 + WAL 恢复到指定时间点，验证数据一致
  • 连接管理：连接数按 内存/每连接开销 估算，配合 PgBouncer 连接池
  • 膨胀治理：autovacuum 参数按表调，长事务与准备事务要及时发现
  • 监控：连接数、慢查询、锁等待、复制延迟、表膨胀、WAL 生成速率
  • 权限：应用账号按 schema/表授权，禁止用 postgres 超级用户连业务

容易踩的坑

  • 只做逻辑备份，大库恢复几小时
  • WAL 归档失败没人管，恢复时发现缺文件
  • 恢复演练从没做过，真恢复时参数写错
  • 基础备份用 -X fetch 但归档没开，缺少 WAL
  • 恢复出的实例直接当生产用，没做数据校验
  • 备份文件与实例同机存一份，机器故障数据全丢

验证与巡检

su - postgres -c "psql -c 'select archived_count, failed_count, last_failed_wal from pg_stat_archiver;'"
ls -lh /backup/pg/ | tail -3

# 目标：failed_count = 0；季度恢复演练记录在案
  • 巡检：归档失败 0、备份存在且可读、季度 PITR 演练、异地副本同步

小结

PG 运维验收：能说出备份点与 WAL 归档位置、能实测恢复到指定时间点、慢查询与膨胀有治理记录。

> 说明：文中命令为通用写法，不同型号/版本可能略有差异，落地前请对照设备实际版本的官方文档；带外管理与安全设备变更建议先在测试设备验证。