postgresql流式数据备份本质是流复制，依赖wal日志实时传输与回放，需主库启用wal_level=replica、max_wal_senders≥从库数、listen_addresses设为'*'或指定ip、hot_standby=on，并在pg_hba.conf中配置replication权限及创建repl_user角色；从库用pg_basebackup初始化并自动生成standby.signal和postgresql.auto.conf；验证时主库查pg_stat_replication状态为streaming，从库查pg_is_in_recovery()为t且wal接收与回放lsn接近，延迟超30秒需排查。
PostgreSQL 流式数据备份本质就是流复制（Streaming Replication），它不依赖外部工具或脚本，而是靠 WAL 日志实时传输与回放实现。配置关键在于主库能正确生成、发送日志，从库能可靠接收、应用日志——不是“备份”动作，而是持续同步状态。
主库必须启用的参数
这些是流复制启动的硬性前提，缺一不可：
- wal_level = replica：不能是 minimal，否则不记录足够事务信息；logical 也可用，但 replica 已满足物理复制需求
- max_wal_senders ≥ 从库数量：每个从库需占用一个 sender 连接，设为 5 比设为 1 更稳妥，避免扩容时反复改配
- listen_addresses = '*' 或指定 IP：确保从库能通过网络连上主库，本地回环（localhost）不够用
- hot_standby = on：让从库在恢复中也能接受只读查询，否则只能“等同步完才可用”
主库认证与权限控制
即使参数全对，没授权也连不上。重点在 pg_hba.conf 中明确声明复制连接：
- 添加一行：
host replication repl_user 192.168.10.20/32 md5（IP 换成真实从库地址） - 该行必须放在所有
host all all ...宽泛规则之前，否则会被拦截 - 复制用户需显式创建：
CREATE ROLE repl_user LOGIN REPLICATION ENCRYPTED PASSWORD 'xxx'; - 改完执行
SELECT pg_reload_conf();生效，无需重启
从库初始化：用 pg_basebackup 一步到位
不要手动拷 data 目录，也不用再写 recovery.conf（v12+ 已废弃）。推荐命令：
pg_basebackup -h 192.168.10.10 -U repl_user -D /var/lib/pgsql/14/data \ -P -v -X stream -C -S standby1 -R
其中：
-
-R：自动生成
standby.signal和postgresql.auto.conf（含 primary_conninfo） - -C：自动在主库创建同名复制槽（standby1），防止 WAL 被过早清理
-
-S：槽名必须唯一，一从一槽，后续可查
pg_replication_slots - 执行前确保从库
data目录为空，且属主为 postgres 用户
验证与日常观察
启动从库后，用以下查询确认状态是否正常：
- 查主库是否收到连接：
SELECT * FROM pg_stat_replication;—— 看state = 'streaming'且sent_lsn与write_lsn接近 - 查从库是否在回放：
SELECT pg_is_in_recovery(), pg_last_wal_receive_lsn(), pg_last_wal_replay_lsn();—— 前者为 t，后两者有值且差值小即健康 - 延迟监控：
SELECT now() - pg_last_xact_replay_timestamp() AS replay_delay;—— 返回秒级延迟，>30s 需排查网络或磁盘 IO
