适用场景

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

配置步骤（部署与参数规范）

# 1) 目录与权限
mkdir -p /data/pg/{data,wal,archive}
chown -R postgres:postgres /data/pg
chmod 700 /data/pg/data

# 2) 初始化
su - postgres -c "/usr/pgsql-16/bin/initdb -D /data/pg/data -E UTF8 --locale=C"

# 3) 关键参数（postgresql.conf 片段）
# listen_addresses = '172.16.1.30'
# max_connections = 300
# shared_buffers = 8GB                # 约物理内存 25%
# effective_cache_size = 24GB         # 约物理内存 75%
# work_mem = 16MB                     # 按并发评估，过大会 OOM
# maintenance_work_mem = 1GB
# wal_level = replica
# archive_mode = on
# archive_command = 'test ! -f /data/pg/archive/%f && cp %p /data/pg/archive/%f'
# wal_keep_size = 2GB

# 4) 启动与校验
systemctl enable --now postgresql-16
su - postgres -c "psql -c 'select version();'"

关键参数与建议

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

容易踩的坑

  • 数据目录与 WAL 同盘，磁盘 IO 竞争严重
  • shared_buffers 设成物理内存 70%，系统缓存被挤占
  • work_mem 设很大，高并发时 OOM
  • 没开 WAL 归档，出故障只能恢复到昨天的全备
  • 归档目录没清理策略，磁盘被 WAL 写满导致库挂起
  • 业务用 postgres 超级用户连接

验证与巡检

su - postgres -c "psql -c 'show archive_mode;' -c 'show shared_buffers;'"
ls -lh /data/pg/archive | tail -5
df -h /data/pg

# 巡检：归档成功、归档目录水位 < 70%、参数与内存匹配、业务账号非超级用户
  • 巡检：归档无失败、磁盘水位正常、连接数水位 < 70%、参数与规格匹配

小结

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

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