postgresql - 用于故障转移的 Slony 和 PPGool

Question

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

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

Answer 1

这是轶事，所以请持保留态度。

PGPool 和流式 WAL 复制(有或没有热备份)以数据库复制的方式工作。您的应用程序不需要知道任何关于复制的信息，也不需要知道它是否是集群的一部分或诸如此类的东西，它只是像与其他数据库一样与数据库对话。流复制是健壮的，并且能够在流中断时故障回复到 WAL 传输。 PGPool 使管理这个过程变得容易，并提供良好的心跳和监控信息。

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

也就是说，Slony 确实比流式复制(通过 PPGool 或不通过管理)做了两件事:

• Slony 允许按表或按数据库进行复制。流复制只允许复制整个 Postgres 实例。如果那种粒度对你很重要，你可能需要 Slony。
• Slony 允许级联(master -> slave -> slave)复制。流式复制只允许一层。 编辑:这是now supported在 PostgreSQL 原生流复制中，从 Postgres 版本 9.2 开始。

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

但您不只是在询问流式复制:PGPool 所做的远不止于此。它允许在只读从属数据库和主数据库之间平衡读写负载、备份计划的实现，以及一大堆其他事情。特别是与 Slony 神秘的命令语法和可怕的管理脚本相比，PPGool 几乎在所有情况下都胜出。

特别是关于故障转移，PGPool 具有心跳监视器和自动路由集群中的数据库流量的能力。 Slony 只有一个“立即故障转移到从站”命令，将所有监控和应用程序端路由留给您。

TL;DR:PPGool 很好。 Slony 不好。