Slony和PGPool用于故障转移

Question

我们正在考虑将Slony和PGPool作为在我们的应用程序中处理故障转移的替代方案-and似乎因为我们至少需要两个DB服务器，所以我们也可以利用负载平衡。

在什么情况下Slony比PGPool更好，反之亦然？

Answer 1

这只是传闻，所以对此持保留态度。

PGPool和流式WAL复制(有没有热备份)按照数据库复制应该的方式工作。您的应用程序不需要知道任何关于复制的信息，也不需要知道它是不是集群的一部分，它只需要像与其他数据库通信一样与数据库通信即可。流复制功能强大，并且能够在流中断时回切到WAL发货。PGPool使管理这一过程变得容易，并提供良好的心跳和监控信息。

另一方面，Slony是一个管理焦油坑，它需要向数据库添加触发器函数和许多其他对象才能工作。此外，Slony不像复制普通的插入/更新/删除类型操作(DML)那样(容易地)支持复制模式更改(DDL)的能力。总的来说，这些特征意味着，在许多情况下，您的应用程序需要有特殊情况来处理Slony的怪癖。在我看来，这很糟糕:应用程序不应该知道/进行更改来处理它运行的数据库复制解决方案。我花了一年多的时间来破解Slony，使其成为一个稳定的复制解决方案，最终得出的结论是，它是一个糟糕的想法/糟糕的复制机制，以一种迟钝、难以辨认的方式实现，根本不是稳定的或企业就绪的。DDL :DDL9.3您可以在对象上安装触发器( Slony用来检测更改)，这可能允许Slony复制数据库的更多方面。

也就是说，Slony确实比流复制(通过PGPool或no管理)做了两件更好的事情：

• Slony允许按表或按数据库复制。流式复制仅支持整个Postgres实例的复制。如果这种粒度对你很重要，你可能需要Slony。
• Slony允许级联(主->从->从)复制。流复制只允许一个级别。EDIT: This is now supported in PostgreSQL native streaming replication，从Postgres版本9.2开始。

在几乎所有其他方面，流复制都更好、更稳定。

但你不仅仅是在问关于流复制的问题: PGPool做的远不止这些。它允许在只读的从数据库和主数据库之间平衡读写负载，实现备份计划，以及许多其他事情。特别是与Slony晦涩难懂的命令语法和糟糕的管理脚本相比，PGPool几乎在每一个实例中都胜出。

特别是在故障转移方面，PGPool具有心跳监视器和在集群中自动路由数据库流量的能力。Slony只有一个"fail to slave now“命令，把所有的监控和应用程序端的路由都留给你。

TL;DR: PGPool good。Slony bad。