可靠 PostgreSQL 备份 必知的前10个 pg_dump 选项
Source: Dev.to
PostgreSQL 的 pg_dump 实用工具是创建逻辑备份的首选工具,但它真正的威力体现在数十个命令行选项上,这些选项让你可以精确地自定义备份内容和方式。了解何时使用哪些选项,往往决定了备份能否在危机时拯救你的项目,还是在关键时刻失效。本文涵盖了每位开发者和 DBA 都应掌握的最关键的 pg_dump 选项。
1. 使用 -F / --format 选择格式
格式选项决定了备份的存储方式以及恢复时的能力。提前选择合适的格式可以在恢复时节省时间并避免麻烦。此单一选项会影响压缩、并行恢复支持以及文件兼容性。
| 格式 | 标志 | 扩展名 | 压缩 | 并行恢复 | 最佳适用场景 |
|---|---|---|---|---|---|
| Plain | -F p | .sql | 否 | 否 | 小型数据库,手动审查 |
| Custom | -F c | .dump | 是 | 是 | 大多数生产使用场景 |
| Directory | -F d | 文件夹 | 是 | 是 | 超大数据库 |
| Tar | -F t | .tar | 否 | 否 | 归档兼容性 |
# Custom format(大多数情况下推荐)
pg_dump -F c -d myapp -f backup.dump
# Directory format 用于并行操作
pg_dump -F d -d myapp -f backup_dir/
对于 500 GB 以下的数据库,使用自定义格式(-F c)能够在压缩、灵活性和恢复速度之间取得最佳平衡。
2. 使用 -j / --jobs 并行导出
jobs 选项通过指定并发进程数来实现并行导出。对大型数据库而言,它可以通过同时转储多个表显著缩短备份时间。该选项仅在目录格式(-F d)下有效。
# 使用 4 个并行进程进行导出
pg_dump -F d -j 4 -d myapp -f backup_dir/
经验法则是将作业数设为 CPU 核心数,但至少保留一个核心给数据库服务器本身。例如,8 核服务器上使用 -j 6 或 -j 7 通常能在不抢占其他进程的情况下获得最佳性能。
3. 使用 -t / --table 选择表
只备份特定表而不是整个数据库。可以通过重复该标志来指定多个表,或使用通配符进行模式匹配。
# 备份单个表
pg_dump -d myapp -t users -f users_backup.sql
# 备份多个表
pg_dump -d myapp -t users -t orders -t products -f critical_tables.sql
# 使用通配符进行模式匹配
pg_dump -d myapp -t 'public.user_*' -f user_tables.sql
表名区分大小写,使用非 public 模式时应包含模式前缀(例如 -t sales.orders)。
4. 使用 -T / --exclude-table 排除表
从转储中排除特定表(或模式)。对那些可以重新生成的大型日志、会话或临时表非常有用。
# 排除日志和会话表
pg_dump -d myapp -T logs -T sessions -T temp_data -f backup.sql
# 排除匹配模式的表
pg_dump -d myapp -T 'public.*_log' -T 'public.*_temp' -f backup.sql
将 -T 与常规备份结合使用,若数据库中包含大量审计或日志表,可将备份体积减少 50 % 以上。
5. 使用 --schema-only 仅导出模式
只导出数据库结构——表、索引、约束、函数和触发器——不包含任何行数据。非常适合版本控制、文档编写或创建空副本。
# 导出完整模式
pg_dump -d myapp --schema-only -f schema.sql
# 仅导出特定表的模式
pg_dump -d myapp --schema-only -t users -t orders -f tables_schema.sql
无论数据库多大,模式仅备份通常只有几百 KB,十分适合与应用代码一起存放在 Git 仓库中。
6. 使用 --data-only 仅导出数据
只导出行数据,省略模式定义。适用于在已有数据库结构上刷新数据,或为测试创建数据快照。
# 导出所有数据(不含模式)
pg_dump -d myapp --data-only -f data.sql
# 使用 INSERT 语句导出(更具可移植性)
pg_dump -d myapp --data-only --inserts -f data_inserts.sql
使用 --data-only 时,目标数据库必须已经具备正确的模式,包括所有表、约束和序列。
7. 使用 -Z / --compress 设置压缩级别
控制自定义和目录格式的压缩(0 = 不压缩,9 = 最高压缩)。压缩级别越高文件越小,但创建时间越长。
| 级别 | 速度 | 大小缩减 | 最佳适用场景 |
|---|---|---|---|
| 0 | 最快 | 无 | 测试、快速恢复优先 |
| 1‑3 | 快速 | 中等 | 每日备份、平衡方案 |
| 4‑6 | 中等 | 良好 | 标准生产备份 |
| 7‑9 | 缓慢 | 最大 | 长期归档、存储受限 |
# 用于归档的最高压缩
pg_dump -F c -Z 9 -d myapp -f backup.dump
# 用于频繁备份的快速压缩
pg_dump -F c -Z 1 -d myapp -f backup.dump
对大多数生产场景而言,默认的 -Z 6 已提供了极佳的压缩与速度平衡。
8. 使用 -c / --clean 清理对象
在 CREATE 语句前加入 DROP 语句,确保恢复时能够替换已有对象而不是因冲突而失败。配合 --if-exists 使用,可在对象缺失时避免错误。
# 备份时加入 DROP 语句
pg_dump -d myapp -c -f backup.sql
# 与 --if-exists 结合,避免缺失对象时报错
pg_dump -d myapp -c --if-exists -f backup.sql
9. 使用 -C / --create 创建数据库
在备份中包含 CREATE DATABASE 语句和连接命令,使备份完整自包含。恢复时应先连接到维护数据库(如 postgres),而不是目标数据库本身。
# 包含 CREATE DATABASE 语句
pg_dump -d myapp -C -f backup.sql
# 同时使用 clean 和 create 的完整备份
pg_dump -d myapp -C -c --if-exists -f backup.sql 