©
This document uses PHP Chinese website manual Release
如果主服务器失败,则备服务器应该开始失效切换处理。
如果备服务器失败,则没有失效切换需要考虑。如果可以重启备用服务器,甚至一段时间后,也可以立即重启恢复进程,发挥重启恢复的优势。 如果不能重启备服务器,则应该创建一个全新的备服务器实例。
如果主服务器失败,并且备服务器成为新主服务器,然后旧主服务器重启, 你必须有一个通知旧主服务器,其不再是主服务器的机制。这有时被称为STONITH(在头去掉其它节点), 这是必要的,以避免系统都认为它们是主服务器的情况下,这将导致混乱和最终数据丢失。
许多失效切换系统只使用两个系统,主备服务器,通过某种心跳机制,不断验证两者连接和主服务器的活力。 也可以使用一个第三方的系统(称为“证人服务器”),以防止某些情况下不适当的失效切换,但额外的复杂性可能是不值得的, 除非设置它为充分仔细和严格的测试。
PostgreSQL 不提供所需的用来确定主服务器失败,并通知备用数据库服务器的系统软件。 存在许多这样的工具和成功失效切换所需的集成操作系统的工具,如IP地址迁移。
一旦发生失效切换到备服务器,仅有一台服务器运行。这就是所谓的退化状态。 前者备服务器现在是主服务器,但前者主服务器是可能会停留下来。 要返回正常运行,必须重建一个备服务器,无论是在以前的服务器,或在第三,可能是新的系统。 一旦完成主备服务器,可以考虑转换角色。有些人选择使用第三方服务器,提供新主服务器的备份 直到新备服务器重建,尽管清楚这个复杂的系统配置和操作流程。
所以从主到备服务器可以快速切换,但需要一些时间重新准备失败切换集群。 定期主备服务器切换是有用的,因为它允许定期停机进行每个系统的维修。 这也是作为一个测试,以确保故失效切换机制,当你需要时会真的工作。 建议写管理操作流程。
要触发日志传送备服务器的失效切换,创建一个触发文件,通过在recovery.conf文件中trigger_file设置文件名和路径。 如果没有给trigger_file,便没有方法在备服务器退出恢复,推进它为主服务器。 这对于例如报告服务器有用的,其仅用于可分载从主服务器的只读查询,而不是针对高可用性的目的。