复制postgresql数据库的快捷方式(或最好的方法)

Question

我做了一个数据库的pg_dump,现在我正在尝试将生成的.sql文件安装到另一台服务器上.

我正在使用以下命令.

psql -f databasedump.sql

我今天早些时候启动了数据库安装,现在7小时后数据库仍在填充.我不知道这是不是应该花多长时间,但我继续监视它,到目前为止我已经看到超过12万次插入和计数.我怀疑有更快的方法来做到这一点.

Answer 1

使用创建转储

pg_dump -Fc -Z 9  --file=file.dump myDb

Fc:输出适合输入到pg_restore的自定义存档.这是最灵活的格式,它允许重新排序加载数据和对象定义.默认情况下也会压缩此格式.

Z 9: --compress=0..9
指定要使用的压缩级别.零意味着没有压缩.对于自定义归档格式,它指定单个表数据段的压缩,默认值为中等压缩.对于纯文本输出,设置非零压缩级别会导致整个输出文件被压缩,就好像它是通过gzip提供的一样; 但默认情况下不压缩.tar存档格式目前根本不支持压缩.

并用它恢复它

pg_restore -Fc -j 8  file.dump

-j: --jobs=number-of-jobs
使用多个并发作业运行pg_restore中最耗时的部分 - 那些加载数据,创建索引或创建约束的部分.此选项可以显着减少将大型数据库还原到在多处理器计算机上运行的服务器的时间.

每个作业都是一个进程或一个线程,具体取决于操作系统,并使用与服务器的单独连接.

此选项的最佳值取决于服务器,客户端和网络的硬件设置.因素包括CPU核心数和磁盘设置.一个好的起点是服务器上的CPU核心数量,但是大于这个数值的值在很多情况下也会导致更快的恢复时间.当然,过高的值会导致性能下降,因为颠簸.

此选项仅支持自定义存档格式.输入文件必须是常规文件(例如,管道).发出脚本而不是直接连接到数据库服务器时,将忽略此选项.此外,多个作业不能与该选项一起使用Fc.

链接:

pg_dump的

那么pg_restore

Answer 2

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

有关更多信息

https://gitlab.com/yanar/Tuning/wikis/improve-pg-dump&restore

Answer 3

为什么要生成原始的.sql转储？pg_dump的开头描述推荐"自定义"格式-Fc.

然后你可以使用pg_restore来恢复你的数据(或它的选定部分).有一个"工作数"选项-j可以使用多个核心(假设您的磁盘不是限制因素).在大多数情况下,在现代机器上,您至少可以获得一些收益.

现在你说"我不知道应该花多长时间".好吧,直到你做了一些恢复,你才会知道.监控系统正在执行的操作以及是否受cpu或磁盘I/O的限制.

最后,要还原数据库所需的配置设置不是您要运行它的配置设置.一些有用的先行者:

1. 增加maintenance_work_mem,以便您可以在更大的块中构建索引
2. 在还原期间关闭fsync.如果您的机器崩溃,无论如何都会从头开始.

请记住在恢复后重置它们.

Answer 4

pg_dump通常建议将的用法与配对使用pg_restore，而不是psql。可以通过以下方式将该--jobs标志分配给各个内核，以加快加载过程：

$ pg_restore --jobs=8 dump.sql

Postgres本身有关于批量加载数据的指南。

我还建议大力调整您postgresql.conf的配置文件，并设置适当的高值maintenance_work_mem和checkpoint_segments值; 较高的值可能会大大提高您的写入性能。