PostgreSQL物理备份与流复制从库搭建实战指南

1. PostgreSQL物理备份与从库搭建核心原理

PostgreSQL作为企业级关系型数据库，其高可用方案的核心在于可靠的备份机制和主从复制能力。物理备份不同于逻辑备份，它直接复制数据库文件的二进制格式，具有恢复速度快、一致性强的特点，特别适合TB级大型数据库的灾备场景。

WAL(Write-Ahead Logging)机制是物理备份的基石。所有数据修改都会先写入WAL日志，再应用到数据文件。这种设计使得我们可以基于某个时间点的文件快照，配合后续的WAL日志，实现任意时间点恢复(PITR)。

流复制(Streaming Replication)则是构建从库的技术核心。主库持续将WAL记录发送给从库，从库重放这些日志来保持数据同步。这种机制下，从库的延迟通常可以控制在毫秒级，是实现读写分离和高可用的基础架构。

2. 物理备份全流程实操

2.1 基础环境准备

首先确保主库已开启归档模式：

sql复制ALTER SYSTEM SET wal_level = 'replica';
ALTER SYSTEM SET archive_mode = on;
ALTER SYSTEM SET archive_command = 'test ! -f /var/lib/pgsql/archive/%f && cp %p /var/lib/pgsql/archive/%f';

重启PostgreSQL服务使配置生效。建议创建专用归档目录并设置权限：

bash复制mkdir -p /var/lib/pgsql/archive
chown postgres:postgres /var/lib/pgsql/archive

2.2 使用pg_basebackup进行全量备份

pg_basebackup是PostgreSQL自带的物理备份工具，执行时会创建整个数据库集群的二进制副本：

bash复制pg_basebackup -D /var/lib/pgsql/backup -Ft -z -P -U replicator -h 主库IP -p 5432

关键参数说明：

• -D 指定备份目录
• -Ft 生成tar格式备份
• -z 启用gzip压缩
• -P 显示进度
• -U 使用具有复制权限的用户

重要提示：执行前需在主库创建专用复制用户：

sql复制CREATE ROLE replicator WITH REPLICATION LOGIN PASSWORD 'securepassword';

2.3 备份验证与恢复测试

备份完成后建议立即验证完整性：

bash复制pg_restore --list /var/lib/pgsql/backup/base.tar.gz | head -n 10

模拟恢复流程：

bash复制mkdir -p /var/lib/pgsql/restore
tar -xzf /var/lib/pgsql/backup/base.tar.gz -C /var/lib/pgsql/restore
chown -R postgres:postgres /var/lib/pgsql/restore

3. 流复制从库搭建详解

3.1 主库配置调整

在主库postgresql.conf中确保以下参数：

ini复制wal_level = replica
max_wal_senders = 10
wal_keep_size = 1GB

在pg_hba.conf中添加从库连接权限：

ini复制host    replication     replicator     从库IP/32        md5

3.2 从库初始化

使用之前创建的备份初始化从库：

bash复制pg_basebackup -h 主库IP -U replicator -D /var/lib/pgsql/standby -P -R

-R参数会自动生成standby.signal文件并在postgresql.auto.conf中添加主库连接信息。

3.3 从库关键配置

从库postgresql.conf需要特殊配置：

ini复制hot_standby = on
primary_conninfo = 'host=主库IP port=5432 user=replicator password=securepassword'
recovery_target_timeline = 'latest'

启动从库服务后，通过以下SQL验证复制状态：

sql复制SELECT client_addr, state, sync_state, replay_lag 
FROM pg_stat_replication;

4. 生产环境优化与监控

4.1 性能调优参数

主库关键参数：

ini复制max_wal_senders = 5  # 根据从库数量调整
wal_compression = on  # 减少网络传输
synchronous_commit = remote_apply  # 关键业务可启用同步复制

从库推荐配置：

ini复制max_standby_streaming_delay = 30s
hot_standby_feedback = on

4.2 监控指标与告警

核心监控指标：

• 复制延迟：SELECT pg_wal_lsn_diff(pg_current_wal_lsn(), replay_lsn) FROM pg_stat_replication;
• 同步状态：SELECT sync_state FROM pg_stat_replication;
• 备库查询冲突：SELECT confl_tablespace, confl_lock FROM pg_stat_database_conflicts;

推荐配置Prometheus监控模板：

yaml复制- name: PostgreSQL Replication
  rules:
  - alert: HighReplicationLag
    expr: pg_replication_lag_seconds > 30
    for: 5m

5. 常见故障处理手册

5.1 复制中断恢复

当出现复制中断时，首先检查主从日志。常见修复步骤：

1. 确认网络连通性
2. 检查主库wal日志是否已清理：

   sql复制SELECT pg_walfile_name_offset(pg_current_wal_lsn());
   

3. 如需重新同步，在从库执行：

   bash复制pg_rewind --target-pgdata=/var/lib/pgsql/standby --source-server="host=主库IP user=postgres"
   

5.2 主从切换演练

计划内切换流程：

1. 提升从库为独立主库：

   bash复制pg_ctl promote -D /var/lib/pgsql/standby
   

2. 原主库配置为从库：

   bash复制touch /var/lib/pgsql/primary/standby.signal
   

5.3 备份恢复实战案例

某次磁盘损坏后的恢复过程：

1. 停止PostgreSQL服务
2. 清空数据目录：

   bash复制rm -rf /var/lib/pgsql/data/*
   

3. 从最近备份恢复：

   bash复制tar -xzf /backup/base.tar.gz -C /var/lib/pgsql/data
   

4. 配置恢复点：

   ini复制restore_command = 'cp /var/lib/pgsql/archive/%f %p'
   recovery_target_time = '2023-06-01 14:00:00'
   

5. 启动服务自动完成恢复

6. 高级应用场景扩展

6.1 级联复制架构

构建主→从→从的级联结构，减轻主库压力。关键配置：

ini复制# 中间从库配置
wal_level = replica
hot_standby = on
max_wal_senders = 3

6.2 延迟从库实现

创建固定延迟的从库用于误操作恢复：

ini复制recovery_min_apply_delay = 1h  # 延迟1小时应用

6.3 逻辑解码与CDC

结合pgoutput插件实现变更数据捕获：

sql复制CREATE PUBLICATION mypub FOR ALL TABLES;
SELECT * FROM pg_create_logical_replication_slot('myslot', 'pgoutput');

实际部署中，我们曾遇到一个典型问题：当主库频繁执行大事务时，从库可能出现apply延迟。解决方案是调整：

ini复制max_standby_archive_delay = 10min
max_standby_streaming_delay = 10min

同时建议将大事务拆分为小批次操作。