我们正在考虑将Slony和PGPool作为我们应用程序中处理故障转移的替代方案 - 似乎因为我们需要至少两台数据库服务器，所以我们也可以利用负载平衡 -
答案 0 :(得分：13)
这是轶事，所以请耐心等待。
PGPool和流式WAL复制（热备份与否）与数据库复制的方式相同。您的应用程序不需要了解有关复制的任何信息，或者它是否是群集的一部分或诸如此类的东西，它只是与数据库中的任何其他内容进行对话。流式复制非常强大，并且能够在流式传输中断时返回WAL运输。 PGPool使管理此过程变得简单，并提供良好的心跳和监控信息。
另一方面，Slony是一个管理tar-pit，它需要将触发器函数和许多其他对象添加到数据库中才能工作。此外，Slony不会（轻松）支持复制模式更改（DDL）的能力，就像复制普通的插入/更新/删除类型操作（DML）一样。总的来说，这些特征意味着，在许多情况下，您的应用程序需要有特殊情况来处理Slony的怪癖。在我看来，这很糟糕：应用程序不应该知道/进行更改以处理它运行的数据库复制解决方案。我花了大约一年的时间来破解Slony作为一个稳定的复制解决方案，并最终得出结论，这是一个糟糕的想法/糟糕的复制机制以一种愚蠢，难以辨认的方式实现，这不是稳定的或企业就绪的。 编辑：从PostgreSQL 9.3开始，您可以在DDL对象上安装触发器（Slony用于检测更改），这可能允许Slony复制数据库的更多方面。那就是说，Slony确实做了两件事比流复制更好（通过PGPool或不通过管理）：
在其他所有方面，流式复制更好，更稳定。
但你不仅仅是在询问流媒体复制：PGPool还有很多功能。它允许在只读从数据库和主服务器之间平衡读取和写入负载，以及备份计划的实现，以及许多其他事情。特别是与Slony的奥术命令语法和神奇的管理脚本相比，PGPool几乎在每个实例中都获胜。
关于故障转移，PGPool具有心跳监视器以及在群集中自动路由数据库流量的能力。 Slony只有一个“故障转移到奴隶现在”命令，将所有监控和应用程序端路由保留给您。
TL; DR：PGPool好。 Slony bad。