25.3. 失效切换

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

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

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

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

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

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

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

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