postgresql – 用于故障转移的Slony和PGPool

PGPool和流式WAL复制(热备份与否)的工作方式与数据库复制的方式相同.您的应用程序不需要了解有关复制的任何信息,或者它是否是群集的一部分或诸如此类的东西,它只是与数据库进行任何其他操作.流式复制非常强大,并且能够在流式传输中断时返回WAL运输. PGPool使这个过程变得简单易行,并提供良好的心跳和监控信息.

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

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

> Slony允许每表或每数据库复制.流复制仅允许复制整个Postgres实例.如果这种粒度对您很重要,您可能需要Slony.
> Slony允许级联(master – > slave – > slave)复制.流复制只允许一个级别.编辑：从Postgres版本9.2开始,这是PostgreSQL本地流复制中的now supported.

从字面上看,其他一切,流式复制更好,更稳定.

但是你不仅仅是在询问流式复制：PGPool还有很多功能.它允许在只读从数据库和主服务器之间平衡读写负载,以及备份计划的实现,以及许多其他事情.特别是与Slony的奥术命令语法和神奇的管理脚本相比,PGPool几乎在所有实例中都获胜.

特别是在故障转移方面,PGPool具有心跳监视器以及在群集中自动路由数据库流量的能力. Slony只有一个“故障转移到奴隶现在”命令,将所有监控和应用程序端路由保留给您.

TL; DR：PGPool好.邋坏.