对于这类应用程序,我真的很喜欢Amazon 的 Dynamo设计。链接的文档很大,但值得一读。事实上,有些应用程序已经实现了这种方法:
也许其他人,但我不知道。Cassandra 从 Facebook 开始,Voldemort 是 LinkedIn 使用的。使事物分布式并在数据分布中添加冗余,您将远离传统的主从复制方法。
如果您想继续使用 PostgreSQL,那么实施这种方法应该没什么大不了的。您将需要实现一个额外的层(代理),它将根据预先配置的选项决定如何检索/保存数据。
代理层可以实现在:
- 应用程序(需要大量的工作恕我直言);
- 数据库;
- 作为中间件。
您可以在中间件层使用PL/Proxy,该项目起源于 Skype。它已深度集成到 PostgreSQL 中,所以我会说它是选项 2 和 3 的组合。PL/Proxy 将要求您使用函数对数据库进行各种查询。如果您遇到性能问题,可以使用PgBouncer 。
最后一点:无论您决定采用哪种方式,都需要进行已知数量的开发。
编辑:
这完全取决于您所说的“故障”以及您认为系统处于中断状态的原因。
让我们看看pgpool的特性。
连接池PostgreSQL 每个会话使用一个进程(fork)。显然,如果您有一个非常繁忙的站点,您将达到操作系统限制。为了克服这个问题,使用了连接池。它们还允许您均匀地使用资源,因此通常最好在数据库之前使用 pooler 。
如果 pgpool 中断,您将面临大量无法访问您的数据库的客户端。如果您将它们直接指向数据库,避免使用 pooler,您将面临性能问题。
复制您的所有查询都将自动复制到从属实例。这对 DML 和 DDL 查询有意义。
如果 pgpool 中断,您的复制将停止并且从属服务器将无法赶上主服务器,因为在 pgpool 之外没有进行任何更改跟踪(据我所知)。
负载平衡您的只读查询将分布在多个实例中,从而实现良好的响应时间,从而使您可以在系统上增加更多带宽。
在 pgpool 中断的情况下,如果系统能够处理这样的负载,您的查询将突然运行得更慢。这是在 master 数据库将追赶而不是失败的 pgpool 的情况下。
限制超出的连接pgpool 会将连接排队,以防它们无法立即处理。
在 pgpool 中断的情况下,所有此类连接都将被中止,这可能会破坏 DB/应用程序协议,即应用程序被设计为永远不会中止连接。
并行查询在多个节点上执行单个查询以减少响应时间。
在 pgpool 中断的情况下,将无法进行此类查询,从而导致处理时间更长。
如果你可以面对这样的情况并且你不认为它们是失败的,那么 pgpool 可以很好地为你服务。如果 5 分钟的中断将使您的公司损失数千美元,那么您应该寻求更可靠的解决方案。
中断的成本越高,故障转移系统的调整就应该越精细。通常,它不仅仅是用于实现故障转移自动化的单一工具。在每次失败中,您都必须进行调整:
- DNS,除非您想要所有客户端的重新配置;
- 重新初始化备份和故障转移程序;
- 确保老主人不会试图为它的角色而战,以防万一它回来(STONITH);
- 根据我的经验,我们是来自 DBA、系统管理员、架构师和运营部门的人,他们决定适当的策略。
最后,在我看来,pgpool 是一个很好的工具,我确实使用它。但它并非设计为一个完整的故障转移解决方案,并非没有额外的思考、采取的措施、编写的脚本。因此,我提供了分布式数据库的链接,它们提供了更高级别的可用性。
并且由于它的可扩展性,PostgreSQL 可以很容易地分发。