9

我们正在考虑将 Slony 和 PGPool 作为在我们的应用程序中处理故障转移的替代方案——看起来因为我们至少需要两个数据库服务器，所以我们也可以利用负载平衡——

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

4

1 回答 1

13

这是轶事，因此请谨慎对待。

PGPool 和流式 WAL 复制（是否有热备份）按照数据库复制应有的方式工作。您的应用程序不需要了解有关复制的任何信息，或者它是否是集群的一部分或其他什么，它只是像与其他数据库一样与数据库通信。流复制是健壮的，并且能够在流中断时故障回复到 WAL 传送。PGPool 使管理此过程变得容易，并提供良好的心跳和监控信息。

另一方面，Slony 是一个管理 tar-pit，它需要向数据库添加触发器函数和许多其他对象才能工作。此外，Slony 不（容易）支持复制模式更改（DDL）的能力，就像它复制普通的插入/更新/删除类型操作（DML）一样。总的来说，这些特征意味着，在许多情况下，您的应用程序需要有特殊情况来处理 Slony 的怪癖。在我看来，这很糟糕：应用程序不必知道/进行更改来处理它运行的数据库复制解决方案。我花了一年的大部分时间来破解 Slony 作为一个稳定的复制解决方案，最终得出结论，这是一个糟糕的想法/糟糕的复制机制，以一种迟钝、难以辨认的方式实现，编辑：从 PostgreSQL 9.3 开始，您可以在 DDL 对象上安装触发器（Slony 用于检测更改），这可能允许 Slony 复制数据库的更多方面。

也就是说，Slony 确实比流式复制做得更好（通过 PGPool 管理或不管理）：

  • Slony 允许按表或按数据库复制。流复制只允许复制整个 Postgres 实例。如果这种粒度对您很重要，您可能需要 Slony。
  • Slony 允许级联（主 -> 从 -> 从）复制。流式复制只允许一个级别。编辑：从 Postgres 9.2 版开始，PostgreSQL 本机流复制现在支持这一点。

从字面上看，流复制更好，更稳定。

但您不仅仅是在询问流式复制：PGPool 的作用远不止于此。它允许在只读的从数据库和主数据库之间平衡读写负载，以及备份计划的实施，以及许多其他事情。尤其是与 Slony 晦涩难懂的命令语法和糟糕的管理脚本相比，PGPool 几乎在所有情况下都胜出。

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

TL;DR：PGPool 不错。懒惰坏。

于 2012-05-02T13:58:49.977 回答