postgresql - 使用PGPool-ii在Amazon EC2上部署高可用性Postgresql 9.0

我们有一个使用Postgresql 9.0和PGPool-ii的现有Web应用程序。我正在考虑将我们的基础架构迁移到Amazon EC2，并受到以下链接的启发:使用类似架构的http://aws.typepad.com/aws/2008/12/running-everything-on-aws-soocialcom.html。

由于Amazon RDS不支持PGSQL，因此我们将继续使用PGPool-ii来负载均衡不同数据库服务器上的查询，并使它们之间保持同步。

因此，我们计划部署3个前端Web服务器，其中将包含以下内容:
-Web服务器+ PHP代码
-PGPool-ii

然后，我们将在只有PGSQL的单独Amazon实例上拥有2个数据库服务器。这2个PG服务器将由位于3个前端服务器上的PGPool使用。

我的问题是我不知道此解决方案是否足够可靠，因为多个PGPool将访问多个PGSQL服务器。 PGPool的大多数示例都演示了使用N个底层PGSQL服务器的单个PGPool。在每个Web服务器上部署PGPool实例是否是一个好习惯？

如果不是，是否还有其他/更好的架构来避免使用Amazon的SPOF？

非常感谢您的答复。

最佳答案

几个想法。首先，我们通过使用Heartbeat，Pacemaker和ElasticIP来避免针对PGPool之类的SPOF。运行两个(或更多)专用于PGPool的实例。将ElasticIP分配给其中之一。设置心跳和起搏器以监视PGPool。故障转移时，让Pacemaker运行一个脚本，该脚本将ElasticIP分配给新的主服务器(以Pacemaker术语表示为DC)。如果仅运行两个节点，请确保在Pacemaker中禁用仲裁功能，因为如果一个节点总数少于两个节点，则无法进行仲裁。

要利用ElasticIP，请从Amazon外部对ElasticIP进行反向DNS查找。这将为您提供一个DNS名称，该名称映射到应以amazonaws.com结尾的ElasticIP。从EC2实例对以amazonaws.com结尾的域名的DNS查找实际上将解析为已分配了ElasticIP的实例的内部IP地址。您可以将应用程序服务器直接指向ElasticIP的DNS，或者假设您正在运行自己的DNS，则可以创建一个引用ElasticIP DNS的CNAME。

也就是说，使用ElasticIP进行故障转移有一个很大的收获。重新分配ElasticIP最多需要120秒才能生效。大部分时间都花费在等待更改通过Amazon DNS服务器传播。

另外，虽然我没有尝试在每个Application Server上运行PGPool-ii，但是我不确定这样做是否可行。如果主数据库发生故障，我认为每个PGPool实例都将争夺处理故障转移的能力。也许我对PGPool-ii不够熟悉，无法理解处理该问题的最佳方法。

至于提到plproxy的人，我认为他们把它与PGBouncer混淆了，建议将其与plproxy一起使用。 plproxy是一个分区系统，而不是负载均衡器。也就是说，PGBouncer也不是负载平衡器-它是一个连接池系统。 PGBouncer不提供负载平衡功能。实际上，针对PGBouncer的FAQ明确建议使用TCP负载均衡器，例如HAProxy。

此外，有关Rackspace解决的具有垂直可伸缩性问题的Amazon的陈述是不正确的。使用Amazon EC2实例，您始终可以停止实例并将其升级为更大的实例类型。 Amazon和Rackspace都不支持即时更改实例类型。

关于postgresql - 使用PGPool-ii在Amazon EC2上部署高可用性Postgresql 9.0，我们在Stack Overflow上找到一个类似的问题：https://stackoverflow.com/questions/6940265/