开始时，我使用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，因此我现在需要研究提高性能。

拜托，请赐教。

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

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

改善pg转储和还原

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

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

PG_RESTORE | 始终对postgres.conf和format-directory和-joptions使用调整

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/

两个问题/想法：

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

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

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

对于大型数据库的备份，应设置连续归档而不是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一样简单。而且速度会更快。

zcat dumpfile.gz | pg_restore -d db_name

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

正如您可能只是通过压缩备份可以提高性能来猜测那样，备份受I / O约束。毫不奇怪，因为备份几乎总是受I / O约束的。压缩数据将I / O负载换为CPU负载，并且由于大多数CPU在怪兽数据传输期间处于空闲状态，因此压缩是最终的胜利。

因此，为了加快备份/还原时间，您需要更快的I / O。除了将数据库重组为一个巨大的单一实例之外，您几乎可以做的所有事情。