88

开始时，我使用pg_dump默认的纯格式。我没有开悟。

研究向我揭示了使用pg_dump -Fc | gzip -9 -c > dumpfile.gz. 我开悟了。

当需要重新创建数据库时，

# create tablespace dbname location '/SAN/dbname';
# create database dbname tablespace dbname;
# alter database dbname set temp_tablespaces = dbname;

% gunzip dumpfile.gz              # to evaluate restore time without a piped uncompression
% pg_restore -d dbname dumpfile   # into a new, empty database defined above

我感到茫然：还原花了 12 个小时来创建数据库，而这只是它的一小部分：

# select pg_size_pretty(pg_database_size('dbname'));
47 GB

因为有人预测这个数据库会有几 TB，所以我现在需要考虑提高性能。

请赐教。

4

6 回答 6

63

首先检查您是否从磁盘设置中获得了合理的 IO 性能。然后检查您的 PostgreSQL 安装是否经过适当调整。特别是shared_buffers应该设置正确，maintenance_work_mem应该在恢复过程中增加，应该在恢复full_page_writes过程中关闭，应该在恢复过程wal_buffers中增加到16MB，checkpoint_segments应该在恢复过程中增加到16，你不应该有任何不合理的登录（如记录每个执行的语句），auto_vacuum应在恢复期间禁用。

如果您使用的是 8.4，还可以尝试并行恢复，pg_restore 的 --jobs 选项。

于 2010-01-19T17:01:32.430 回答
35

改进 pg 转储和恢复

PG_DUMP | 始终使用格式目录和-j选项

time pg_dump -j 8 -Fd -f /tmp/newout.dir fsdcm_external

PG_RESTORE | 始终对 postgres.conf 和格式目录和-j选项进行调整

work_mem = 32MB
shared_buffers = 4GB
maintenance_work_mem = 2GB
full_page_writes = off
autovacuum = off
wal_buffers = -1

time pg_restore -j 8 --format=d -C -d postgres /tmp/newout.dir/
于 2016-12-30T21:08:09.623 回答
14

两个问题/想法：

  1. 通过指定 -Fc，pg_dump 输出已经被压缩。压缩不是最大的，因此您可能会发现使用“gzip -9”可以节省一些空间，但我敢打赌这不足以保证用于压缩和解压缩 -Fc 版本的备份的额外时间（和 I/O） .

  2. 如果您使用的是 PostgreSQL 8.4.x，您可以使用新的 pg_restore 命令行选项“-j n”加速从 -Fc 备份的恢复，其中 n=用于恢复的并行连接数。这将允许 pg_restore 加载多个表的数据或同时生成多个索引。

于 2010-01-19T16:47:18.100 回答
10

我假设您需要备份，而不是数据库的重大升级。

对于大型数据库的备份，您应该设置连续归档而不是pg_dump.

  1. 设置 WAL 归档。

  2. 例如，每天使用
    psql template1 -c "select pg_start_backup('`date +%F-%T``')" rsync -a --delete /var/lib/pgsql/data/ /var/backups/pgsql/base/ psql template1 进行基本备份 - c“选择 pg_stop_backup()”`

恢复就像从备份位置恢复数据库和不早于pg_start_backup时间的 WAL 日志并启动 Postgres 一样简单。而且它会快得多。

于 2010-01-19T18:15:01.610 回答
7 
zcat dumpfile.gz | pg_restore -d db_name

删除将未压缩数据完整写入磁盘，这是当前的瓶颈。

于 2010-01-22T02:34:03.160 回答
3

您可能已经猜到了压缩备份会带来更快的性能这一事实，您的备份受 I/O 限制。这应该不足为奇，因为备份几乎总是受 I/O 限制。压缩数据以 I/O 负载换取 CPU 负载，并且由于大多数 CPU 在巨量数据传输期间处于空闲状态，因此压缩是一种净赢。

因此，为了加快备份/恢复时间，您需要更快的 I/O。除了将数据库重组为不是一个巨大的单一实例之外，这几乎就是您所能做的。

于 2010-01-19T16:31:47.090 回答