我正在研究 PostgreSQL 复制解决方案。我知道有两种这样的解决方案
- 低级 - 涉及 PostgreSQL 9.x 中的流式日志传送、热备用功能
- 高级 - 在 SQL 查询级别工作的 Slony、Londiste
我的数据库不是很繁忙，也不庞大（至少现在不是）。但我想避免由于 Amazon EC2 故障（比如最近发生的故障）而导致的停机。我的解决方案是维护一个位于不同可用区域中的从属服务器，该从属服务器将与我的主数据库实例保持同步。这样，当主服务器发生故障时，我就可以故障转移到它。需要考虑的一点是，这将需要将数据从主服务器连续复制到从属服务器，这将是跨 EC2 可用区域的网络流量。它不是免费的。目前每 GB 的成本为 1 美分，但在阅读了 PostgreSQL 手册中的一些计算后，我了解到即使数据库流量很低，成本也会增长得非常高。例如，在“热物理备份和连续归档”一章中《PostgreSQL 9 管理手册》我读过这个：
如果 archive_timeout 设置为 30 秒，我们每天将至少生成 2*60*24 = 2880 个文件，每个文件大小为 16 MB，因此每天总量为 46 GB（最小值）
[并且我假设数据库上的流量最小]
我唯一的要求是，在主服务器上执行的每个写入 SQL 查询都应在从服务器上重播。如果在事件回调中完成此操作，那么这将是完美的，因为只有在修改数据库时才会在主服务器和从服务器之间传输数据，而不是每 30 秒左右传输一次，即使数据库没有发生任何更改。
因此我认为 Londiste 可能是我的解决方案，但我不能 100% 确定它是否有效。
你有什么建议？
答案1
经过一周的研究，我相信PostgreSQL 实例的Streaming Log Shipping配置Hot Standby可以满足我的即时复制（数据丢失的最小窗口）需求，同时降低网络流量。我写了一篇详细的博客文章关于我如何设置它。
可能还有其他解决方案，使用像 pgpool 这样的第三方工具，但我没有取得太大的成功。
答案2
看一下池。我们在工作中使用它，到目前为止我们非常满意。你显然仍然想做备份，因为它不能保护你免受 SQL 查询错误的影响，但它可以完美地完成同步/复制工作。