pg_dump和pg_restore在巨型数据库上

Question

我目前正在完成改进数据库结构的任务。为此，我们希望有效地转储和恢复一个巨大的数据库。 （约1TB并且正在增长）

要使用此数据库进行测试，我们希望将此数据库传输到另一个服务器节点，并通过pg_dump和pg_restore进行传输。

我们正在运行v10（https://www.postgresql.org/docs/10/app-pgdump.html）服务器，因此我们仅限于它们可能的参数。它还需要转储整个数据库，而不仅仅是部分。

为此，我尝试了几种方法，这些来源帮了很多忙：

• Using pg_dump and pg_restore correctly
• PostgreSQL: improving pg_dump, pg_restore performance

最重要的是：

• http://www.databasesoup.com/2014/09/settings-for-fast-pgrestore.html

问题是，你几乎只能改进其中一项任务，但不能同时改进这两项任务。

Case 1

以目录格式转储非常快（约1小时），但恢复不是。

pg_dump --blobs --dbname="$DBNAME" --file=$DUMPDIR --format=directory --host=$SERVERHOSTNAME --jobs=$THREADS --port=$SERVERPORT--username="$SERVERUSERNAME"
pg_restore --clean --create --format=directory --jobs=$THREADS --host=$SERVERHOSTNAME --port=$SERVERPORT --username="$SERVERUSERNAME" "./"

关于这种恢复方法的问题是，即使我为其分配了多个核心，它也只使用一个，在服务器核心上只使用了4％的CPU。

Case 2

以自定义格式转储速度极慢，服务器甚至无法在一夜之间完成（会话超时）。

pg_dump --blobs --compress=9 --dbname="$dbname" --file="$DUMPDIR/db.dump" --format=custom --host=$SERVERHOSTNAME --port=$SERVERPORT --username=$SERVERUSERNAME

所以我有不同的方法：

1. 使用方法＃1转储它，然后转换它（如何？）并使用更快的恢复方法（变体＃2？）
2. 在不同的核心上同时创建多个转储但具有不同的模式（总共有6个），然后将它们合并（如何？）

根据上述作者的说法，管道似乎是一种无效的倾倒方式。

有没有人有这方面的经验？我的方法 - 想法是否有用，或者您是否有一个完全不同的解决方案？

哦，在我忘记之前：我们目前在我们的外部服务器上限制为5TB，并且运行db的内部服务器不应该因数据碎片而变得臃肿，即使是暂时的。

Answer 1

具有目录格式的并行pg_restore应该加快处理速度。

如果没有，我怀疑大部分数据都在一个大表中，pg_restore（和pg_dump）无法并行化。

确保禁用压缩（-z 0）以提高速度（除非您的网络较弱）。

在线文件系统备份可能会快得多：

• pg_basebackup很简单，但不能并行化。
• 使用low-level API，您可以将备份与操作系统或存储技术并行化。

缺点是使用文件系统备份，您只能复制整个数据库集群。