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