我们正在考虑将Slony和PGPool作为在我们的应用程序中处理故障转移的替代方案，而且似乎因为我们需要至少两个DB服务器，所以我们也可以利用负载平衡-
在什么情况下斯隆比PGPool和维切弗萨好？
最佳答案
这是奇闻轶事，所以要小心谨慎。
PGPool和流式WAL复制（无论是否具有热备份）的工作方式应该是数据库复制。您的应用程序不需要知道任何关于复制的信息，也不需要知道它是否是集群的一部分或什么，它只需要像与其他应用程序一样与数据库进行对话。流复制是健壮的，并且能够在流中断时故障恢复到WAL shipping。PGPool使管理这个过程变得简单，并提供良好的心跳和监控信息。
另一方面，Slony是一个管理tar pit，它需要向数据库中添加触发器函数和许多其他对象才能工作。此外，Slony不（容易）支持复制模式更改（DDL）的能力，就像它复制普通的插入/更新/删除类型操作（DML）一样。总的来说，这些特性意味着，在许多情况下，您的应用程序需要有特殊的情况来处理Slony的古怪。在我看来，这很糟糕：应用程序不应该知道/进行更改来处理它运行的数据库复制解决方案。我花了一年的大部分时间来攻击Slony作为一个稳定的复制解决方案，最终得出结论，这是一个坏主意/以一种迟钝、难以理解的方式实现的糟糕的复制机制，根本不是稳定的或企业准备的。编辑：从PostgreSQL 9.3开始，您可以在DDL对象上安装触发器（Slony使用它来检测更改），这可能允许Slony复制数据库的更多方面。
也就是说，Slony确实比流式复制（通过PGPool或no管理）做得更好：
Slony允许按表或按数据库复制。流式复制只允许复制整个Postgres实例。如果这种粒度对您很重要，那么您可能需要Slony。
Slony允许级联（master->slave->slave）复制。流式复制只允许一个级别。编辑：这是从Postgres9.2版开始的PostgreSQL本机流式复制中的now supported。
从字面上讲，流式复制是更好和更稳定的。
但你不仅仅是问流复制：PGPool做的远远不止这些。它允许在只读从数据库和主数据库之间平衡读写负载，实现备份计划，以及一整套其他东西。尤其是与斯罗尼晦涩难懂的命令语法和糟糕的管理脚本相比，PGPool几乎在每一个实例中都获胜。
特别是在故障转移方面，PGPool具有心跳监视器和在集群中自动路由数据库通信的能力。Slony只有一个“fail-over to slave now”命令，所有的监控和应用程序端路由都由您决定。
医生：很好。斯隆很坏。