25.3. 失效切换

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

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

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

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

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

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

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

要触发日志传送备服务器的失效切换，创建一个触发文件,通过在recovery.conf文件中trigger_file设置文件名和路径。 如果没有给trigger_file，便没有方法在备服务器退出恢复，推进它为主服务器。 这对于例如报告服务器有用的，其仅用于可分载从主服务器的只读查询，而不是针对高可用性的目的。