转储postgres DB,时间和.sql文件权重

时间:2015-12-15 15:06:07

标签: postgresql dump

我有一个大数据库(nominatim db,用于地址编码反向),大约是408gb。

现在,为了向客户提供估算,我想知道导出/重新导入过程需要多长时间以及.sql转储文件的大小。 我的postgresql版本是9.4,安装在centOS 6.7虚拟机上,具有16GB RAM和500GB磁盘空间。

你能帮助我吗?

感谢所有人的回答,无论如何要恢复转储的数据库我不使用命令pg_restorepsql -d newdb -f dump.sql(我在官方文档中这样做)。这是因为我必须在另一台机器上设置这个数据库,以避免使用nominatim db索引程序!我不知道是否有人知道nominatim(是一个openstreetmap开源产品),但是在一台拥有16gb内存的CentOS 6.7机器中,欧洲地图(15.8 gb)的数据库索引过程花了我32天...... 比另一个可能的问题应该是:pg_restore等于psql -d -f?哪个更快?

再次感谢

1 个答案:

答案 0 :(得分:3)

正如@a_horse_with_no_name所说,没有人能够为您的环境提供准确的答案。但这是我用来估算的程序。

我一般发现我的数据的压缩备份是实时数据库大小的十分之一或更小。您通常也可以从备份大小中扣除索引的磁盘大小。 Examine the size of things in-database以获得更好的主意。您还可以尝试构建一个更小的数据库子集,并将实时大小与压缩备份进行比较;这可能会给你一个应该在球场的比例。 SQL文件很好用,压缩很好; Postgres使用的磁盘表示似乎更加惹人注目。绩效价格可能。

估计时间的最佳方法就是做一些探索性运行。根据我的经验,这通常需要比预期更长的时间。我有一个~1 TB的数据库,我相当肯定需要一个月才能恢复,但它也是积极索引的。我有几个~20 GB的数据库,可以在大约15分钟内备份/恢复。所以它变化很大,但索引增加了时间。如果您可以设置类似的服务器,则可以尝试备份还原过程并查看需要多长时间。无论如何,我建议你这样做,只是为了建立信心,并在扣动扳机之前解决任何挥之不去的问题。

我还建议您试用pg_dump's "custom format"pg_dump -Fc),它会生成pg_restore易于使用的压缩存档。