改进pg转储和恢复

Question

当我开始时，我使用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，我现在需要考虑提高性能。

拜托，赐教。

Answer 1

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

如果你在8.4上也试验并行恢复，pg_restore的--jobs选项。

Answer 2

两个问题/想法：

通过指定-Fc，pg_dump输出已经压缩。压缩不是最大的，所以你可以通过使用“gzip -9”找到一些空间节省，但我打赌它不足以保证额外的时间（和I / O）使用压缩和解压缩-Fc版本的备份
如果您使用的是PostgreSQL 8.4.x，则可以使用新的pg_restore命令行选项“-jn”来加速从-Fc备份的还原，其中n =要用于还原的并行连接数。这将允许pg_restore加载多个表的数据或同时生成多个索引。

Answer 3

改进pg转储和恢复

PG_DUMP |始终使用带有-j选项

的格式目录

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

PG_RESTORE |始终使用带有-j选项

的格式目录对postgres.conf进行调整

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/`

了解更多信息

https://github.com/YanarAssaf/PostgreSQL/wiki/Improve-pg-dump%7Crestore

Answer 4

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

对于大型数据库的备份，您应该设置continuous archiving而不是pg_dump。

Set up WAL archiving
例如，每天使用
进行基本备份 psql template1 -c "select pg_start_backup('`date +％F-％T``'）“ rsync -a --delete / var / lib / pgsql / data / / var / backups / pgsql / base / {{1 psql template1 -c“select pg_stop_backup（）”`

恢复就像从备份位置恢复不超过时间的数据库和WAL日志并启动Postgres一样简单。它会更快。

Answer 5

zcat dumpfile.gz | pg_restore -d db_name

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

Answer 6

正如您可能已经猜到的那样，压缩备份可以提高性能，您的备份是I / O绑定的。这应该不足为奇，因为备份几乎总是受I / O限制。压缩数据会导致CPU负载的I / O负载，并且由于大多数CPU在怪物数据传输期间处于空闲状态，因此压缩会以净胜利的形式出现。

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

PostgreSQL：改进pg_dump，pg_restore性能

6 个答案:

改进pg转储和恢复