我目前有一个任务,需要改进数据库结构。为此,我们想要有效地转储和恢复一个单一的巨大数据库。(约1TB并不断增长)
为了测试这个数据库,我们想将其转移到另一个服务器节点,使用pg_dump
和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" "./"
这个恢复方法存在的问题是,即使我分配了多个核心给它,它仅使用一个核心,在服务器核心上仅使用了不到4%的CPU。
案例2
以自定义格式转储非常缓慢,以至于服务器甚至无法在一夜之间完成(会话超时)。
pg_dump --blobs --compress=9 --dbname="$dbname" --file="$DUMPDIR/db.dump" --format=custom --host=$SERVERHOSTNAME --port=$SERVERPORT --username=$SERVERUSERNAME
我有不同的方法:
- 使用方法1进行转储,之后进行转换(如何?),并使用更快的恢复方法(变体2?)
- 在不同的核心上同时创建具有不同模式的多个转储(共6个),然后将它们合并(如何?)
有人对此有更多经验吗?我的方法是否有用,还是你有完全不同的解决方案?
哦,我忘了说:我们目前在外部服务器上限制为5TB,运行数据库的内部服务器不应该被数据碎片弄得过大,即使是暂时的。
pg_restore
的一个旧版本。现在,它要求指定-f
或-d
。 - Laurenz Albe