巨型数据库上的pg_dump和pg_restore

时间:2019-03-14 13:48:12

标签: postgresql pg-dump database-cloning

我目前有一项任务是改善数据库结构。 为此,我们希望有效地转储和还原单个巨型数据库。 (大约1TB,并且还在不断增长

为了测试该数据库的性能,我们希望将此数据库通过pg_dumppg_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. 使用方法1转储它,然后进行转换(如何?)并使用更快的恢复方法(变体2?)
  2. 在不同的内核上使用不同的模式(总共有6个)同时创建多个转储,然后将它们合并回去(如何?)

根据上述作者所述,管道似乎是一种无效的转储方式。

有人在这方面有更多经验吗?我的方法思想有用吗,还是您有一个完全不同的解决方案?

哦,在我忘记之前:我们目前在外部服务器上限制为5TB,并且运行数据库的内部服务器不应因数据碎片而-肿,甚至是暂时的。

1 个答案:

答案 0 :(得分:0)

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

如果没有,我怀疑很多数据都在一个大表中,pg_restore(和pg_dump)无法并行化。

确保禁用压缩(-z 0)以提高速度(除非网络较弱)。

使用在线文件系统备份可能会更快:

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