Postgres 9.0 和 pgpool 复制：单点故障？

Question

我的应用程序使用 Postgresql 9.0，由一个或多个与全局数据库交互的站组成：它类似于一个普通的客户端服务器应用程序，但为了避免任何额外的硬件，所有站都包括客户端和服务器：主站是提升为也充当服务器，任何其他充当它的客户端。该解决方案允许我进行扩展：用户最初可能需要一个站点，但它可以决定在未来扩展更多站点，而无需在初始阶段使用无用的单独服务器。

如果主站出现故障，我会尽量避免所有其他站停止工作；要做到这一点，最好的解决方案可能是将主数据库连续复制到一个或多个站点上未使用的数据库。

搜索我发现 pgpool 可以满足我的需要，但从所有示例和教程看来，故障点从主数据库转移到运行 pgpool 的服务器。

我阅读了有关多个 pgpool 和心跳工具的信息，但不清楚如何去做。

考虑到我的架构，哪里不存在分离和专门的服务器，有人可以给我一些提示吗？在故障转移的情况下，似乎 pgpool 会自动执行所有操作，我是否可以认为故障转移情况可以由标准用户处理而无需管理员干预？

Answer 1

尝试阅读此博客（包含大量有关 PostgreSQL 和 PgPool-II 的信息）：

https://www.itenlight.com/blog/2016/05/21/PostgreSQL+HA+with+pgpool-II+-+Part+5

在同一个博客上搜索“WATCHDOG”。使用它，您可以配置 PgPool-II 集群。但是，需要同一子网上的两台机器，并且需要同一子网上的虚拟 IP。

希望这对任何尝试相同事情的人有用（即使这个答案很晚）。

Answer 2

PGPool 肯定会成为单点故障，但它比 Postgres 实例小得多。

虽然我还没有尝试过，但应该可以有两台安装了 PGPool 的机器，但只能在其中一台上运行。然后，如果主服务器不可用，您可以使用 Linux-HA 在备用主机上重新启动 PGPool，并在主服务器恢复时可选择再次将其故障恢复。您还可以同时使用 Linux-HA 来移动单个虚拟 IP，以便您的客户端可以连接到单个 IP 以提供其 Postgres 服务。

postgres 服务器的死亡将使 PGPool 向备份 Postgres 发送查询（必要时将其提升为 master）。

PGPool 服务器的死亡将导致短暂的中断（可配置，但可能在

Answer 3

首先，我建议查看pgBouncer 而不是pgpool。接下来，您试图达到什么级别的扩展？您可能只是选择在所有客户端系统上运行连接池（bouncer 足够轻，可以正常工作）。

也就是说，vyegorov 的答案可能是您在当今时代真正应该关注的方向。你确定你真的需要一个数据库吗？

编辑

因此，相当明显的答案是，如果您只有一个机器运行 pgPool，它会产生单点故障。显而易见的解决方案是跨多个盒子运行多个池化程序。然后，您需要设计您的应用程序代码来处理数据库断开连接。这听起来并不容易，但基本上您需要使用两阶段提交来进行非幂等更改。因此，您应该尽最大可能使您的更改具有幂等性。

根据您的 cmets，我猜您可能在处理数据库复制方面的经验有限？ pgPool 执行基于语句的复制。这里有权衡。好处是它很容易设置。缺点是不能保证复制数据库上的数据是相同的。它也（我相信但最近没有检查过）与 2pc 不兼容。

我之前的评论询问您是否真的需要一个数据库，这是因为我认为您设计了一个系统而没有详细介绍这部分的细节。我在处理类似系统的“这部分”方面拥有大约 2 年的经验。我希望您会发现没有现成的解决方案，并且所涉及的问题变得非常复杂。换句话说，我建议你重新考虑你的设计。

Answer 4

对于这类应用程序，我真的很喜欢Amazon's Dynamo 设计。链接的文档很大，但值得一读。事实上，已经有一些应用程序实现了这种方法：

• mongoDB
• Cassandra
• Project Voldemort

也许是其他人，但我不知道。 Cassandra 从 Facebook 开始，Voldemort 是 LinkedIn 使用的。使事物分布式并在您的数据分布中添加冗余，您将远离传统的主从复制方法。

如果您想继续使用 PostgreSQL，那么实施这种方法应该没什么大不了的。您将需要实现一个额外的层（代理），它将根据预先配置的选项决定如何检索/保存数据。

代理层可以实现在：

• 申请（恕我直言，需要大量工作）；
• 数据库；
• 作为中间件。

你可以在中间件层使用PL/Proxy，项目起源于Skype。它已深度集成到 PostgreSQL 中，所以我会说它是选项 2 和 3 的组合。PL/Proxy 将要求您使用函数对数据库进行各种查询。 如果您遇到性能问题，可以使用PgBouncer。

最后一点：无论您决定采用哪种方式，都需要进行已知数量的开发。

编辑：

这完全取决于您所说的“故障”以及您认为系统处于中断状态的原因。

让我们看看pgpool 的功能。

1. 连接池 PostgreSQL 每个会话使用一个进程（分叉）。显然，如果您有一个非常繁忙的站点，您将达到操作系统限制。为了克服这个问题，使用了连接池。它们还允许您均匀地使用您的资源，因此通常最好在您的数据库之前安装 pooler。
   如果 pgpool 中断，您将面临大量无法访问的客户端你的数据库。如果您将它们直接指向数据库，避免使用 pooler，您将面临性能问题。

2. 复制您的所有查询都将自动复制到从属实例。这对 DML 和 DDL 查询有意义。
   如果 pgpool 中断，您的复制将停止并且从属服务器将无法赶上主服务器，因为在 pgpool 之外没有进行任何更改跟踪（据我所知）。

3. 负载平衡您的只读查询将分布在多个实例中，从而实现良好的响应时间，让您可以为系统提供更多带宽。
   万一 pgpool 中断如果系统能够处理这样的负载，您的查询将突然运行得更慢。在这种情况下，主数据库将赶上而不是失败的 pgpool。

4. 限制超出的连接数 pgpool 会将连接排队，以防它们无法立即处理。
   如果 pgpool 中断，所有此类连接都将被中止，这可能会中断DB/Application 协议，即 Application 被设计为永远不会中止连接。

5. 并行查询在多个节点上执行单个查询以减少响应时间。
   如果 pgpool 中断，将无法进行此类查询，从而导致处理时间更长。

如果您可以面对这样的情况并且您不将其视为失败，那么 pgpool 可以为您提供良好的服务。如果 5 分钟的中断将使您的公司损失数千美元，那么您应该寻求更可靠的解决方案。

中断的成本越高，故障转移系统的调整就应该越精细。 通常，它不仅仅是用于实现故障转移自动化的单一工具。 在每次失败中，您都必须进行调整：

• DNS，除非您希望重新配置所有客户端；
• 重新初始化备份和故障转移过程；
• 确保老主人不会试图为它的角色而战，以防万一它回来（STONITH）；
• 根据我的经验，我们是来自 DBA、系统管理员、架构师和运营部门的人，他们决定适当的策略。

最后，在我看来，pgpool 是一个很好的工具，我确实使用它。但它并非设计为一个完整的故障转移解决方案，并非没有额外的思考、采取的措施、编写的脚本。因此，我提供了分布式数据库的链接，它们提供了更高级别的可用性。

而且 PostgreSQL 的可扩展性非常好，只需一点点努力就可以分发出去。