我做了一个数据库的pg_dump，现在正在尝试将生成的.sql文件安装到另一台服务器上。
我正在使用以下命令。
psql -f databasedump.sql
我今天早些时候启动了数据库安装，现在7小时后数据库仍然被填充。我不知道这是不是应该花多长时间，但我继续监视它，到目前为止我已经看到超过12万次插入和计数。我怀疑有更快的方法来做到这一点。
答案 0 :(得分：52)
使用
创建转储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核心数量，但是大于这个数值的值在很多情况下也会导致更快的恢复时间。当然，过高的价值会因为颠簸而导致性能下降。
此选项仅支持自定义和目录存档格式。输入必须是常规文件或目录（例如，不是管道）。发出脚本而不是直接连接到数据库服务器时，将忽略此选项。此外，多个作业不能与选项--single-transaction一起使用。
链接：
答案 1 :(得分：12)
PG_DUMP |始终使用带有-j选项
time pg_dump -j 8 -Fd -f /tmp/newout.dir fsdcm_external
PG_RESTORE |始终使用带有-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
答案 2 :(得分：11)
为什么要生成原始的.sql转储？ pg_dump的开头说明建议使用“自定义”格式-Fc。
然后你可以使用pg_restore来恢复你的数据（或它的选定部分）。有一个“作业数”选项-j可以使用多个核心（假设您的磁盘不是限制因素）。在大多数情况下，在现代机器上，您至少可以获得一些收益。
现在你说“我不知道应该花多长时间”。好吧，直到你做了一些恢复，你才会知道。监控系统正在执行的操作以及是否受cpu或磁盘I / O的限制。
最后，要还原数据库所需的配置设置不是您要运行它的配置设置。一些有用的开始：
请记住在恢复后重置它们。
答案 3 :(得分：4)
通常建议pg_dump的使用与pg_restore配对，而不是psql。可以在核心之间拆分此方法，以通过传递--jobs标志来加速加载过程：
$ pg_restore --jobs=8 dump.sql
Postgres本身对批量加载数据有guide。
我还建议大量调整postgresql.conf配置文件，并为maintenance_work_mem和checkpoint_segments值设置适当的高值;更高的值可能会显着提高您的写入性能。