流PostgreSQL pg_dump到S3

Question

是否可以或建议将pg_dump输出流/管道传输到S3？

我们正在将大型数据集转储到实例中，而且数据库大小也很大。因此，尝试优化本地磁盘空间(避免转储的临时空间)，并在S3上直接创建备份。

我们在Ubuntu16.04上有一个PostgreSQL v9.6.3。

Answer 1

您可以使用s3's 多部分上传功能在生成转储时对其进行流处理。然而，这很可能容易出错，而且不太可靠。更好的方法是创建一个短暂的EBS卷，将数据库转储到它。然后上传压缩备份到S3/冰川，如果这是它需要去的地方。

如果您想要进行时间点恢复的备份，对EBS卷执行pg_basebackup，并在备份后将WAL流存档，就意味着您可以在不保留完整副本节点的情况下缩短恢复时间。如果您关心的是可用性，那么设置复制是可行的方法。尽管您仍然需要备份。

复制不是备份，如果有人在Origin上删除一个表，它将被删除到副本上；所以您仍然需要PITR或检查点备份。

Answer 2

pg_dump直接流到S3似乎运行良好。我有350 do的数据库，不想创建额外的临时驱动器。您需要确保多部分块的大小足够大，否则我会遇到“太多段”的问题。对于AWS，命令如下：

aws configure set default.s3.multipart_chunksize 200MB 
time sudo -u postgres pg_dump -Z 9 -v DB_NAME |aws s3 cp - s3://BUCKET/DB_NAME.dump.gz

使用我的db，花费了大约8个小时，结果是S3中的130 db文件。现在必须用psql进行恢复，因为pg_restore不喜欢普通的sql转储上面创建的命令。我不能在那里使用自定义格式，因为这需要创建不能(可能吗？)被管道吹走了。

最后，恢复相同的方式，而不保存中间文件。注意，我必须在psql之前使用zcat解压缩数据：

wget -O - 'https://S3-URL/BUCKET/DB_NAME.dump.gz' |zcat |sudo -u postgres psql DB_NAME

恢复似乎需要大约8小时的时间(大约8小时)，可能取决于您的服务器(AWS或其他地方，我的服务器在AWS之外)在哪里和有多大。

Answer 3

不，这不明智。相反，设置实际复制，PostgreSQL支持。我会使用订阅者模型，但如果您想使用s3，也可以使用WAL-log传送到archive_command。

然而，这基本上是不必要的。除非我有更多的特殊用例，否则我不会考虑这个问题。

我将使用订阅服务器模式升级到10.1和跳转逻辑复制。