我目前的任务是改进数据库结构。为此，我们希望有效地转储和恢复一个巨大的数据库。（大约 1TB 并且还在增长）
为了测试这个数据库，我们想把这个数据库转移到另一个服务器节点，并通过pg_dumpand pg_restore.
我们正在运行 v10 ( https://www.postgresql.org/docs/10/app-pgdump.html ) 服务器，因此我们仅限于它们可能的参数。还需要转储整个数据库，而不仅仅是部分。
为此，我尝试了几种方法，这些来源有很大帮助：
最重要的是：
问题是，您几乎只能改进其中一项任务，但不能同时改进两者。
情况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" "./"
这种恢复方法的问题是，即使我为它分配了多个核心，它也只使用一个，服务器核心上使用的 CPU 几乎没有 4%。
案例2
以自定义格式转储非常慢，服务器甚至无法在一夜之间完成（会话超时）。
pg_dump --blobs --compress=9 --dbname="$dbname" --file="$DUMPDIR/db.dump" --format=custom --host=$SERVERHOSTNAME --port=$SERVERPORT --username=$SERVERUSERNAME
所以我想到了不同的方法：
- 用方法 #1 转储它，然后转换它（如何？）并使用更快的恢复方法（变体 #2？）
- 在不同的核心上同时创建多个转储但具有不同的模式（总共有 6 个），然后将它们合并回来（如何？）
根据上述作者的说法，管道似乎是一种无效的倾销方式。
有没有人在这方面有更多经验？我的方法想法有用吗，还是您有完全不同的解决方案？
哦，在我忘记之前：我们目前在外部服务器上限制为 5TB，运行 db 的内部服务器不应该因为数据片段而变得臃肿，即使是暂时的。