将 PostgreSQL pg_dump 流式传输到 S3

Question

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

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

我们在 Ubuntu 16.04 上有一个 PostgreSQL v9.6.3。

Answer 1

pg_dump 直接流式传输到 S3 似乎工作正常。我有 350GB 的数据库，不想创建临时附加驱动器。您需要确保多部分块大小足够大，否则我会遇到“段太多”的问题。使用 AWS CLI 命令：

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

我的数据库花了大约 8 个小时，结果是 S3 中的 130GB 文件。现在恢复必须用 psql 完成，因为 pg_restore 不喜欢普通的 sql 转储上面的命令创建的内容。我无法在那里使用自定义格式，因为这要创建无法（可能？）通过管道传输的目录。

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

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

恢复似乎与转储大约需要相同的时间（约 8 小时），可能取决于您的服务器的位置和大小（AWS 或其他地方，我的在 AWS 之外）。

Answer 2

您可以使用 s3 的分段上传功能在生成转储时流式传输转储。然而，这很可能容易出错并且不太可靠。更好的方法是创建一个临时 EBS 卷，将您的数据库转储到它。然后将压缩的备份上传到 s3/Glacier，如果这是它需要去的地方。

如果您想要pg_basebackup对 EBS 卷进行时间点恢复的备份并在备份后从该点归档 WAL 流，这意味着您可以缩短恢复时间，而无需保留完整的副本节点。如果您担心可用性，那么设置复制是可行的方法。尽管您仍然需要备份。

Replication 不是备份，如果有人在 Origin 上删除了一个表，它将被删除到 Replica 上；所以你仍然需要 PITR 或检查点备份。