PostgreSQL物理备份与搭建从库详细过程
在 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 -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 为例
创建快照卷
lvcreate -L 10G -s -n pgdata_snap /dev/vg0/pgdata
快照大小需容纳备份期间的写入量。
挂载快照并拷贝
mkdir /mnt/snap mount /dev/vg0/pgdata_snap /mnt/snap rsync -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. 创建复制用户
CREATE USER repuser WITH REPLICATION ENCRYPTED PASSWORD 'replpass123';
4. 重载配置
pg_ctl reload -D $PGDATA
3.3 从库初始化(node2)
步骤 1:停止 PostgreSQL(如有)
sudo systemctl stop postgresql-14
步骤 2:清空数据目录
rm -rf /var/lib/pgsql/14/data/*
步骤 3:使用 pg_basebackup 初始化
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内容示例:
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:启动从库
sudo systemctl start postgresql-14
3.4 验证从库状态
在从库执行:
-- 确认处于恢复模式 SELECT pg_is_in_recovery(); -- 应返回 true -- 查看是否只读 SHOW hot_standby; -- on
在主库执行:
-- 查看复制状态 SELECT * FROM pg_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,避免从库无法追平。
创建槽(主库):
SELECT pg_create_physical_replication_slot('standby1');- 从库配置中指定槽名(
primary_slot_name)。
注意:需监控槽的 lag,避免磁盘爆满。
5.2 压缩与远程备份
- 压缩备份:
pg_basebackup ... -Ft | gzip > backup.tar.gz
- 远程备份:
pg_basebackup ... -D - | ssh user@remote "cat > backup.tar"
5.3 自动化脚本示例
#!/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
fi5.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 DBA 的必备技能。
到此这篇关于PostgreSQL物理备份与搭建从库的文章就介绍到这了,更多相关PostgreSQL物理备份内容请搜索脚本之家以前的文章或继续浏览下面的相关文章希望大家以后多多支持脚本之家!
相关文章
PostgreSQL 备份与恢复实战操作pg_dump / pg_restore 
本文将带你深入掌握 PostgreSQL 最核心的备份恢复工具 —— pg_dump 和 pg_restore,涵盖逻辑备份、物理备份、增量备份、自动化脚本等企业级实践,感兴趣的朋友跟随小编一起看看吧2025-10-10


最新评论