是否可以或者建议将 pg_dump 输出流式传输/管道到 S3？
我们正在将大型数据集转储到我们的实例中，数据库大小很大。因此尝试优化本地磁盘空间（避免转储临时空间）并直接在 S3 上创建备份。
我们在 Ubuntu 16.04 上有一个 PostgreSQL v9.6.3。
答案1
您可以使用 s3分段上传功能在生成转储时对其进行流式传输。但是，这很容易出错，而且不太可靠。更好的方法是创建一个临时 EBS 卷，将数据库转储到其中。然后将压缩备份上传到 s3/Glacier（如果需要的话）。
如果您想要针对时间点恢复进行备份，那么pg_basebackup对 EBS 卷执行备份并从备份后的点存档 WAL 流意味着您可以缩短恢复时间而无需保留完整的副本节点。如果您关心的是可用性，那么设置复制是可行的方法。尽管您仍然需要备份。
复制不是备份，如果有人在原点删除一个表，它也会在副本上被删除；所以您仍然需要 PITR 或检查点备份。
答案2
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 转储。我无法在那里使用自定义格式，因为这会创建无法（可能？）通过管道传输的目录。
最后以相同的方式恢复，无需保存中间文件。请注意，我必须在 psql 之前使用 zcat 解压缩数据：
wget -O - 'https://S3-URL/BUCKET/DB_NAME.dump.gz' |zcat |sudo -u postgres psql DB_NAME
恢复似乎花费与转储大约相同的时间（~8 小时），可能取决于您的服务器在哪里以及有多大（AWS 或其他地方，我的在 AWS 之外）。
答案3
不，这不是明智的做法。相反，实际复制PostgreSQL 支持。我会使用订阅者模型，但你也可以使用 WAL 日志传送到 s3archive_command。
但是，这基本上是不必要的。除非我有更特殊的用例，否则我不会考虑它。
我会升级到10.1 进入逻辑复制使用订阅者模型。