java - 如何为 JavaEE 应用程序中的 PostgreSQL 热备设置配置连接故障转移？

Question

我有两台安装了 PostgreSQL 9.5 数据库的 Linux 服务器(A 和 B)。我按照 documentation 中的描述配置了 热备用 模式。 .在此设置中，A 配置为主，B 处于热备模式。这运行良好并且行为符合预期。

现在，我想通过 Hibernate/JDBC 通过 连接一个独立的 Java EE 应用程序(在不同的机器上运行) >TomEE 数据库设置的数据源。

PostgreSQL driver文档指出，可以在 jdbc 连接 url 中指定多个主机:

jdbc:postgresql://host1:port1,host2:port2/database

所以我的问题是:

1. 如果 A 已关闭并且 B 手动切换到正常操作模式，我的应用程序是否仍然能够使用上述 jdbc 连接 url 进行数据库操作？
2. 是否必须配置其他参数/​​库？

注意:从我了解到的各种来源，PostgreSQL 不支持自动故障转移(除非该过程涉及第三方软件 - 请参阅下面的评论)。出于这个原因，故障转移需要手动执行，这对于这个特定的用例来说是可以的。

EDIT-1:

我决定测试 pgBouncer(如评论中的建议)以寻求解决方法。它适用于我的用例。我写了一个看门狗脚本，它可以自动执行手动步骤:

1. 持续检查 A 是否还活着并监听传入的连接。
2. 如果发生故障转移，将B切换到正常运行模式，让它成为新的master并重启服务。
3. 将 pgBouncer 设置更改为指向 B 而不是 A 并重新启动服务。

但是，如果有人有没有使用第三方软件的经验，我仍然很感兴趣？

Answer 1

在这种情况下，最好进行测试和测量。

我没有 PostrgeSQL 热备用模式的“实践”经验，但我已经为 Java 应用程序完成了数据库故障转移。

首先，测试 PostgreSQL driver 上的声明文档页面关于 ?targetServerType=master 参数(在页面底部提到)。
编写一个小的Java“PgHsm”类，其主方法通过DriverManager.getConnection使用PostgreSQL JDBC驱动程序并运行一个简单的更新查询。
它应该使用服务器A进行更新查询。在服务器 A 上停止 PostgreSQL，运行 PgHsm:它应该无法连接，因为服务器 B 不是主服务器。
将服务器B设为master，运行PgHsm:它应该运行正常。

数据源由 TomEE 中的数据库连接池提供支持。 This page列出了在 TomEE 中可用的那些。但并非所有数据库连接池都是平等的，我现在更喜欢 HikariCP，因为根据我的经验，它可以更可预测地处理“数据库关闭”场景。另请参阅 HikariCP 的 handling database down 上的测试结果。页面。

不幸的是，HikariCP 使用 JDBC 的 get/setNetworkTimeout行为可预测和 PostgreSQL JDBC 驱动程序 does not implement this (*)。因此，要确保(JavaEE)应用程序线程不会在数据库操作上永远挂起，您需要设置 connectTimeout 和 socketTimeout JDBC 驱动程序选项。设置 socketTimeout 是不稳定的，因为它会自动设置对数据库的所有查询的时间限制。

(*) 更新:由于版本 42.2.x 网络超时为 implemented .

要执行的第二个测试涉及更新 Java“PgHsm”类以使用您选择的数据库连接池实现并启动(至少)两个在循环中不断运行简单更新查询的线程(在循环中，从池中获取数据库连接并在提交/回滚后返回到池中)。当您关闭服务器 A 并将服务器 B 切换到“主”模式时，监视“PgHsm”记录的异常以及线程在执行数据库操作时等待/挂起的时间。
测试结果可用于更新 JDBC 驱动程序选项和池设置。关注结果:

• 尽快从池中删除无效连接，以便应用程序从池中获取大部分有效连接
• 当数据库出现故障时，尽可能少的应用程序线程挂起(在最短的时间内)

第二个测试依赖于服务器 A 不可用，因此连接测试查询(由数据库连接池执行)失败。在两台服务器保持可用，但主从切换的情况下，连接测试查询将无济于事并且数据库连接池将为应用程序提供错误的(现在是只读的)数据库连接。在这种情况下，需要人工干预。描述了 HikariCP 的“故障转移模式”here(仅适用于 configuration 页面中描述的选项 allowPoolSuspension):

• suspendPool()
• softEvictConnections()
• 等到 activeConnections 变为 0。
• resumePool()

第三个测试将是 JavaEE 应用程序，到现在为止，您应该很清楚会出现什么问题。在这些测试之后更新应用程序以改进处理“数据库关闭”场景的情况并不少见(例如设置(默认)query-timeouts)。在您的情况下，在手动故障转移期间使用“挂起、刷新和恢复数据库连接池”功能(上述模式)也是可取的。