PostgreSQL：物理备份与搭建从库-程序员充电站

文章目录

- 一、物理备份基础概念
- - 1.1 什么是物理备份？
  - 1.2 物理备份的前提条件
- 二、物理备份的两种主流方法
- - 2.1 方法一：使用 pg_basebackup（官方推荐）
  - - 基本语法
    - 常用选项说明
    - 实战：创建物理备份（用于 PITR）
  - 2.2 方法二：文件系统级快照（LVM/ZFS/Btrfs）
  - - 以 LVM 为例
    - 优势与限制
- 三、基于物理备份搭建从库（流复制 Standby）
- - 3.1 环境准备
  - 3.2 主库配置（node1）
  - - 1. 修改 `postgresql.conf`
    - 2. 配置 `pg_hba.conf`
    - 3. 创建复制用户
    - 4. 重载配置
  - 3.3 从库初始化（node2）
  - - 步骤 1：停止 PostgreSQL（如有）
    - 步骤 2：清空数据目录
    - 步骤 3：使用 pg_basebackup 初始化
    - 步骤 4：验证生成的文件
    - 步骤 5：启动从库
  - 3.4 验证从库状态
  - - 在从库执行：
    - 在主库执行：
- 四、物理备份 + WAL 归档实现 PITR
- - 4.1 配置 WAL 归档（主库）
  - 4.2 恢复流程
- 五、高级技巧与最佳实践
- - 5.1 使用复制槽（Replication Slot）保护 WAL
  - 5.2 压缩与远程备份
  - 5.3 自动化脚本示例
  - 5.4 常见问题排查
- 六、物理备份 vs 逻辑备份对比

在 PostgreSQL 中，物理备份（Physical Backup）是 PostgreSQL 高可用、灾难恢复和搭建从库（Standby）的核心手段。

一、物理备份基础概念

1.1 什么是物理备份？

物理备份是指直接复制 PostgreSQL 的数据文件（即$PGDATA目录下的所有文件），包括：

表数据文件（base/）
WAL 日志（pg_wal/）
控制文件（global/pg_control）
配置文件（postgresql.conf,pg_hba.conf等）

与逻辑备份（pg_dump）不同，物理备份：

保留数据库内部结构（如 OID、文件布局）；
恢复速度极快（直接拷贝文件）；
支持时间点恢复（PITR）（配合 WAL 归档）；
可用于搭建流复制从库。

1.2 物理备份的前提条件

要执行有效的物理备份，必须满足：

wal_level >= replica（默认replica即可）；
启用连续归档（Continuous Archiving）或使用pg_basebackup -X stream；
备份期间数据库可正常运行（热备份）；
所有节点 PostgreSQL 版本、操作系统架构一致（主从搭建时）。

二、物理备份的两种主流方法

2.1 方法一：使用 pg_basebackup（官方推荐）

pg_basebackup是 PostgreSQL 自带的工具，专为创建基础备份（Base Backup）设计，支持流式传输 WAL，操作简单、安全可靠。

基本语法

pg_basebackup[选项]-D<目标目录>

常用选项说明

选项	说明
`-h <host>`	主库 IP 或主机名
`-U <user>`	复制用户（需`REPLICATION`权限）
`-D <dir>`	备份输出目录
`-Fp`/`-Ft`	输出格式：plain（默认）或 tar
`-X stream`	同时流式接收 WAL，避免备份期间 WAL 被清理
`-P`	显示进度
`-v`	详细输出
`-R`	自动生成 standby 配置（用于搭建从库）
`-C`	在主库创建复制槽（防止 WAL 过早回收）
`-S <slot_name>`	指定复制槽名称

实战：创建物理备份（用于 PITR）

# 创建备份目录mkdir-p /backup/base_$(date+%Y%m%d)# 执行备份pg_basebackup -h192.168.10.50\-U repuser\-D /backup/base_$(date+%Y%m%d)\-Fp -P -v -X stream

此备份可用于后续 PITR 恢复，但不能直接启动为从库（缺少standby.signal）。

2.2 方法二：文件系统级快照（LVM/ZFS/Btrfs）

适用于支持快照的存储系统，备份速度接近瞬时，对数据库性能影响极小。

以 LVM 为例

创建快照卷
```
lvcreate -L 10G -s -n pgdata_snap /dev/vg0/pgdata
```
快照大小需容纳备份期间的写入量。

挂载快照并拷贝

mkdir/mnt/snapmount/dev/vg0/pgdata_snap /mnt/snaprsync-aHAXx /mnt/snap/ /backup/base_$(date+%Y%m%d)/umount/mnt/snap

删除快照
```
lvremove /dev/vg0/pgdata_snap
```

优势与限制

几乎零停机、低 I/O 压力；
依赖特定存储技术；
需手动处理 WAL 归档一致性（建议配合pg_start_backup()/pg_stop_backup()）。

注意：PostgreSQL 15+ 已弃用pg_start_backup()，推荐使用pg_basebackup或存储快照 + WAL 归档。

三、基于物理备份搭建从库（流复制 Standby）

物理备份是搭建从库最标准、最高效的方式。以下演示如何使用pg_basebackup一键初始化从库。

3.1 环境准备

节点	IP	角色
node1	192.168.10.50	Primary
node2	192.168.10.51	Standby

前提：

主库已配置流复制（见下文）；
从库已安装相同版本 PostgreSQL；
网络互通，SSH 免密（可选，用于文件同步）。

3.2 主库配置（node1）

1. 修改`postgresql.conf`

listen_addresses = '*' wal_level = replica max_wal_senders = 10 wal_keep_size = 1GB # PG 13+，旧版用 wal_keep_segments hot_standby = on

2. 配置`pg_hba.conf`

# 允许复制连接 host replication repuser 192.168.10.51/32 md5

3. 创建复制用户

CREATEUSERrepuserWITHREPLICATIONENCRYPTED PASSWORD'replpass123';

4. 重载配置

pg_ctl reload -D$PGDATA

3.3 从库初始化（node2）

步骤 1：停止 PostgreSQL（如有）

sudosystemctl stop postgresql-14

步骤 2：清空数据目录

rm-rf /var/lib/pgsql/14/data/*

步骤 3：使用 pg_basebackup 初始化

sudo-u postgres pg_basebackup\-h192.168.10.50\-U repuser\-D /var/lib/pgsql/14/data\-P -v -R -X stream -C -S standby_slot_1

关键选项解释：

-R：自动生成standby.signal和postgresql.auto.conf（含primary_conninfo）；
-C -S：在主库创建名为standby_slot_1的复制槽，防止 WAL 被过早清理。

步骤 4：验证生成的文件

/var/lib/pgsql/14/data/standby.signal（空文件，标识为从库）；

postgresql.auto.conf内容示例：

primary_conninfo = 'user=repuser password=replpass123 host=192.168.10.50 port=5432 sslmode=prefer sslcompression=0 gssencmode=prefer krbsrvname=postgres target_session_attrs=any' primary_slot_name = 'standby_slot_1'

步骤 5：启动从库

sudosystemctl start postgresql-14

3.4 验证从库状态

在从库执行：

-- 确认处于恢复模式SELECTpg_is_in_recovery();-- 应返回 true-- 查看是否只读SHOWhot_standby;-- on

在主库执行：

-- 查看复制状态SELECT*FROMpg_stat_replication;

关键字段：

application_name：默认为pg_basebackup，可通过-E指定；
state：streaming表示正常流复制；
sync_state：async（异步）或sync（同步）。

四、物理备份 + WAL 归档实现 PITR

若仅用于灾难恢复（非搭建从库），需配合 WAL 归档实现任意时间点恢复。

4.1 配置 WAL 归档（主库）

# postgresql.conf archive_mode = on archive_command = 'cp %p /archive/wal/%f'

确保/archive/wal/目录存在且 PostgreSQL 有写权限。

4.2 恢复流程

停止 PostgreSQL
```
pg_ctl stop -D$PGDATA
```
清理原数据目录
```
rm-rf$PGDATA/*
```
还原物理备份
```
cp-r /backup/base_20260210/*$PGDATA/
```
创建 recovery.signal
```
touch$PGDATA/recovery.signal
```

配置恢复目标（可选）
在$PGDATA/postgresql.auto.conf中添加：

restore_command = 'cp /archive/wal/%f %p' recovery_target_time = '2026-02-10 18:00:00'

启动数据库
```
pg_ctl start -D$PGDATA
```
数据库将重放 WAL 至目标时间点，然后自动转为主库模式。

五、高级技巧与最佳实践

5.1 使用复制槽（Replication Slot）保护 WAL

复制槽可防止主库在从库断连时清理 WAL，避免从库无法追平。

创建槽（主库）：

SELECTpg_create_physical_replication_slot('standby1');

从库配置中指定槽名（primary_slot_name）。

注意：需监控槽的 lag，避免磁盘爆满。

5.2 压缩与远程备份

压缩备份：
```
pg_basebackup... -Ft|gzip>backup.tar.gz
```

远程备份：

pg_basebackup... -D -|sshuser@remote"cat > backup.tar"

5.3 自动化脚本示例

#!/bin/bashBACKUP_DIR="/backup/base_$(date+%Y%m%d)"pg_basebackup -h192.168.10.50 -U repuser -D"$BACKUP_DIR"-Fp -P -X streamif[$?-eq0];thenecho"Backup succeeded:$BACKUP_DIR"# 清理7天前的备份find/backup -name"base_*"-mtime +7 -execrm-rf{}\;elseecho"Backup failed!"exit1fi

5.4 常见问题排查

问题	原因	解决方案
`pg_basebackup: could not connect to server`	主库未监听、防火墙、认证失败	检查`listen_addresses`、`pg_hba.conf`、网络
从库启动报错 “WAL ends before end of backup”	备份期间主库重启	使用`-X stream`或确保 WAL 归档完整
从库延迟高	网络慢、主库负载高	监控`pg_stat_replication`，优化硬件
无法写入从库	正常行为	从库为只读，需 promote 后才可写

六、物理备份 vs 逻辑备份对比

维度	物理备份	逻辑备份
恢复速度	极快（文件拷贝）	慢（SQL 重放）
备份体积	大（含所有文件）	小（仅数据+DDL）
跨版本迁移	不支持（需相同主版本）	支持（需兼容）
搭建从库	唯一标准方式	不可行
PITR 支持	是（需 WAL）	否
存储开销	高	低

结论：生产环境高可用架构必须依赖物理备份；逻辑备份适用于跨版本迁移或部分表导出。

总结：PostgreSQL 物理备份是构建高可用、实现灾难恢复的基石。通过pg_basebackup，可一键完成：

安全的热备份；
从库的快速初始化；
与 WAL 归档结合实现 PITR。

关键要点：

主库必须配置wal_level = replica和复制权限；
使用-R -X stream -C选项简化从库搭建；
复制槽可防止 WAL 丢失，但需监控；
定期验证备份可恢复性。