使用 PGPool-ii 在 Amazon EC2 上部署高可用性 Postresql 9.0答案

【问题标题】：Deploying a high availability Postresql 9.0 on Amazon EC2 with PGPool-ii使用 PGPool-ii 在 Amazon EC2 上部署高可用性 Postresql 9.0
【发布时间】：2011-10-19 21:29:19
【问题描述】：

我们有一个使用 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 实例是一种好习惯吗？

如果没有，是否有任何其他/更好的架构来避免使用亚马逊的 SPOF？

非常感谢您的回复。

【问题讨论】：

标签： postgresql amazon-ec2 failover pgpool

【解决方案1】：

几个想法。首先，我们通过使用 Heartbeat、Pacemaker 和 ElasticIP 来避免像 PGPool 这样的 SPOF。运行两个（或更多）专用于 PGPool 的实例。将 ElasticIP 分配给其中一个。设置 Heartbeat 和 Pacemaker 来监控 PGPool。在故障转移时，让 Pacemaker 运行一个脚本，将 ElasticIP 分配给新的主节点（Pacemaker 术语中的 DC）。如果您只运行两个节点，请确保禁用 Pacemaker 中的仲裁功能，因为如果一个节点在总共两个节点中出现故障，您将无法拥有仲裁。

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

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

另外，虽然我没有尝试在每个应用服务器上运行 PGPool-ii，但我不确定这是否可行。如果主数据库发生故障，我认为每个 PGPool 实例都会竞争处理故障转移。也许我只是对 PGPool-ii 不够熟悉，无法理解处理它的最佳方法。

就提到 plproxy 的人而言，我认为他们将它与 PGBouncer 混淆了，推荐与 plproxy 一起使用。 plproxy 是一个分区系统，而不是负载均衡器。也就是说，PGBouncer 也不是负载均衡器——它是一个连接池系统。 PGBouncer 不提供负载平衡功能。事实上，PGBouncer 的常见问题解答明确建议使用 TCP 负载均衡器，如 HAProxy。

此外，关于亚马逊存在 Rackspace 解决的垂直可扩展性问题的说法是不正确的。使用 Amazon EC2 实例，您始终可以停止实例并将其升级到更大的实例类型。 Amazon 和 Rackspace 都不支持动态更改实例类型。

【讨论】：

【解决方案2】：

虽然，我对 pgPool 没有一个清晰的概念，但我一直在对可扩展性领域进行大量研究，但由于某些我现在不记得的原因而忽略了 pgPool。

我建议看看 plproxy。这提供了一种负载平衡的方法。

另外，由于亚马逊存在垂直可扩展性问题，我不会成为亚马逊的重度买家。当您想要增加服务器的配置时，您不会获得开箱即用的升级。因此，如果您升级到更高的实例，您最终将再次实施所有服务器设置。

这样，Rackspace 令人信服，您只需要求他们从 1 GB 内存升级到 2 GB 或更多，只需重启您的实例即可完成。

Amazon 和 Rackspace 都提供 (99%) 可靠的托管解决方案，剩下的 1% 我们必须注意适当的备份和分发到不同区域等，

【讨论】：

正如我在回答中提到的，您提出了几个错误的陈述。首先，plproxy 不是 Postgres 的负载均衡器——它是一个分区系统。其次，亚马逊允许您停止实例并将其升级到更大的大小。 Rackspace 在这方面并不是独一无二的。
请您再次阅读我的回答。我提到了“plproxy 提供了一种负载平衡的方法”，但我没有提到它是一个负载平衡器。 Skype 使用了这种方法，但我无法立即放置链接。另外，我提到的关于亚马逊的问题是，如果您想将容量增加到更大的实例（例如从小实例到大实例等），则必须进行整个设置。如果您知道无需复制或快照还原即可无缝垂直升级的更好方法，请告诉我。
对不起，我确实看错了你的说法。尽管 plproxy 不适合我的组织作为更传统的负载平衡方法的替代方案，但我可以看到它对某些人来说是一种选择。就垂直扩展 Amazon EC2 实例而言，您无需复制或使用快照即可轻松完成此操作。事实上，它直接内置在管理控制台中。如果您停止 EC2 实例，您可以更改实例类型。唯一也适用于 Rackspace 的警告是，您不能从 32 位实例转到 64 位实例，反之亦然。
啊，我是多么粗心。几个月来一直在使用亚马逊并没有注意到该选项只是因为它被隐藏在上下文菜单中！感谢您的回复！今天的一些学习:)