PostgreSQL：物理备份与搭建从库

文章目录

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

基本语法

bash 复制代码

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）

bash 复制代码

# 创建备份目录
mkdir -p /backup/base_$(date +%Y%m%d)

# 执行备份
pg_basebackup -h 192.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 为例

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

挂载快照并拷贝

bash 复制代码

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

删除快照
bash 复制代码
```
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`

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`

conf 复制代码

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

3. 创建复制用户

sql 复制代码

CREATE USER repuser WITH REPLICATION ENCRYPTED PASSWORD 'replpass123';

4. 重载配置

bash 复制代码

pg_ctl reload -D $PGDATA

3.3 从库初始化（node2）

步骤 1：停止 PostgreSQL（如有）

bash 复制代码

sudo systemctl stop postgresql-14

步骤 2：清空数据目录

bash 复制代码

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

步骤 3：使用 pg_basebackup 初始化

bash 复制代码

sudo -u postgres pg_basebackup \
  -h 192.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 内容示例：

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：启动从库

bash 复制代码

sudo systemctl start postgresql-14

3.4 验证从库状态

在从库执行：

sql 复制代码

-- 确认处于恢复模式
SELECT pg_is_in_recovery();  -- 应返回 true

-- 查看是否只读
SHOW hot_standby;            -- on

在主库执行：

sql 复制代码

-- 查看复制状态
SELECT * FROM pg_stat_replication;

关键字段：

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

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

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

4.1 配置 WAL 归档（主库）

conf 复制代码

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

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

4.2 恢复流程

停止 PostgreSQL
bash 复制代码
```
pg_ctl stop -D $PGDATA
```
清理原数据目录
bash 复制代码
```
rm -rf $PGDATA/*
```
还原物理备份
bash 复制代码
```
cp -r /backup/base_20260210/* $PGDATA/
```
创建 recovery.signal
bash 复制代码
```
touch $PGDATA/recovery.signal
```
配置恢复目标（可选）

在 $PGDATA/postgresql.auto.conf 中添加：
conf 复制代码
```
restore_command = 'cp /archive/wal/%f %p'
recovery_target_time = '2026-02-10 18:00:00'
```
启动数据库
bash 复制代码
```
pg_ctl start -D $PGDATA
```
数据库将重放 WAL 至目标时间点，然后自动转为主库模式。

五、高级技巧与最佳实践

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

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

创建槽（主库）：

sql 复制代码

SELECT pg_create_physical_replication_slot('standby1');

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

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

5.2 压缩与远程备份

压缩备份 ：

bash 复制代码

pg_basebackup ... -Ft | gzip > backup.tar.gz

远程备份 ：

bash 复制代码

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

5.3 自动化脚本示例

bash 复制代码

#!/bin/bash
BACKUP_DIR="/backup/base_$(date +%Y%m%d)"
pg_basebackup -h 192.168.10.50 -U repuser -D "$BACKUP_DIR" -Fp -P -X stream
if [ $? -eq 0 ]; then
  echo "Backup succeeded: $BACKUP_DIR"
  # 清理7天前的备份
  find /backup -name "base_*" -mtime +7 -exec rm -rf {} \;
else
  echo "Backup failed!"
  exit 1
fi

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 丢失，但需监控；
定期验证备份可恢复性。

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 逻辑备份对比

1. 修改 `postgresql.conf`

2. 配置 `pg_hba.conf`