9.3 9.4 9.5 9.6 10 11 12 13 14 15
阿里云PostgreSQL 问题报告 纠错本页面

25.3. 失效切换

如果主服务器失败,则备服务器应该开始失效切换处理。

如果备服务器失败,则没有失效切换需要考虑。如果可以重启备用服务器, 甚至一段时间后,也可以立即重启恢复进程,发挥重启恢复的优势。 如果不能重启备服务器,则应该创建一个全新的备服务器实例。

如果主服务器失败,并且备服务器成为新主服务器,然后旧主服务器重启, 你必须有一个通知旧主服务器,其不再是主服务器的机制。 这有时被称为STONITH(在头去掉其它节点), 这是必要的,以避免系统都认为它们是主服务器的情况下, 这将导致混乱和最终数据丢失。

许多失效切换系统只使用两个系统,主备服务器,通过某种心跳机制, 不断验证两者连接和主服务器的活力。 也可以使用一个第三方的系统 (称为“证人服务器”),以防止某些情况下不适当的失效切换, 但额外的复杂性可能是不值得的,除非设置它为充分仔细和严格的测试。

PostgreSQL不提供所需的用来确定主服务器失败, 并通知备用数据库服务器的系统软件。 存在许多这样的工具和成功失效切换所需的集成操作系统的工具,如IP地址迁移。

一旦发生失效切换到备服务器,仅有一台服务器运行。这就是所谓的退化状态。 前者备服务器现在是主服务器,但前者主服务器是可能会停留下来。 要返回正常运行,必须重建一个备服务器,无论是在以前的服务器, 或在第三,可能是新的系统。一旦完成主备服务器,可以考虑转换角色。 有些人选择使用第三方服务器,提供新主服务器的备份直到新备服务器重建, 尽管清楚这个复杂的系统配置和操作流程。

所以从主到备服务器可以快速切换,但需要一些时间重新准备失败切换集群。 定期主备服务器切换是有用的,因为它允许定期停机进行每个系统的维修。 这也是作为一个测试,以确保故失效切换机制,当你需要时会真的工作。 建议写管理操作流程。

要触发日志传送备服务器的失效切换,运行pg_ctl promote或者创建一个触发文件, 这个文件是通过在recovery.conf文件中trigger_file设置指定的文件名和路径。 如果你计划使用pg_ctl promote进行失效切换,则不需要trigger_file。 如果你设置报告服务器仅仅用于卸载主服务器的只读查询, 而不是针对高可用性的目的,那么你不需要推动它。

<
/BODY >