我做了一个数据库的 pg_dump，现在正试图将生成的 .sql 文件安装到另一台服务器上。
我正在使用以下命令。
psql -f databasedump.sql
我今天早些时候启动了数据库安装，现在 7 小时后数据库仍在填充。我不知道这是否应该花多长时间，但我继续监视它，到目前为止，我已经看到超过 12 万个插入和计数。我怀疑有一种更快的方法可以做到这一点。
问问题
66160 次
4 回答
116
创建你的转储
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 一起使用。
链接：
于 2014-06-04T23:45:44.507 回答
34
改进 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
于 2016-12-30T15:53:57.777 回答
18
为什么要生成原始 .sql 转储？pg_dump的开头描述推荐“自定义”格式-Fc。
然后您可以使用 pg_restore 来恢复您的数据（或其中的选定部分）。有一个“作业数量”选项-j可以使用多个核心（假设您的磁盘还不是限制因素）。在大多数情况下，在现代机器上，您至少可以从中获得一些收益。
现在你说“我不知道这需要多长时间”。好吧，在您完成一些恢复之前，您不会知道。一定要监控你的系统在做什么，以及你是否受到 CPU 或磁盘 I/O 的限制。
最后，您想要用于恢复数据库的配置设置并不是您想要运行它的那些。几个有用的启动器：
- 增加maintenance_work_mem，以便您可以在更大的块中构建索引
- 在还原期间关闭fsync 。如果你的机器崩溃了，你无论如何都要从头开始。
请记住在恢复后重置它们。
于 2013-03-28T22:31:35.767 回答
8
的用法pg_dump一般建议搭配使用pg_restore，而不是搭配使用psql。--jobs此方法可以在内核之间拆分，以通过传递标志来加速加载过程：
$ pg_restore --jobs=8 dump.sql
Postgres 本身有关于批量加载数据的指南。
我还建议大量调整您的postgresql.conf配置文件并为maintenance_work_mem和值设置适当的高checkpoint_segments值；更高的值可能会显着提高您的写入性能。
于 2013-03-28T22:00:47.100 回答