26.3 故障切换
26.3. 故障转移
如果主服务器失效,则后备服务器应该开始故障转移过程。
如果后备服务器失效,则不会有故障转移发生。如果后备服务器可以被重启 (即使晚一点),由于可重启恢复的优势,那么恢复处理也能被立即重启。 如果后备服务器不能被重启,则一个全新的后备服务器实例应该被创建。
如果主服务器失效并且后备服务器成为了新的主服务器,那么接下来旧的主服务器重启后, 你必须有一种机制来通知旧的主服务器不再成为主服务器。有些时候这被称为 STONITH(Shoot The Other Node In The Head,关闭其他节点), 这对于避免出现两个系统都认为它们是主服务器的情况非常必要, 那种情况将导致混乱并且最终导致数据丢失。
很多故障转移系统仅使用两个系统,主系统和后备系统, 它们由某种心跳机制连接来持续验证两者之间的连接性和主系统的可用性。 也可能会使用第三个系统(称为目击者服务器)来防止某些不当故障转移的情况, 但是除非非常小心地建立它并且经过了严格地测试,否则额外的复杂度可能会使该工作得不偿失。
PostgreSQL 并不提供在主服务器上标识失败并且通知后备数据库服务器所需的系统软件。 现在已有很多这样的工具并且很好地与成功的故障转移所需的操作系统功能整合在一起, 例如 IP 地址迁移。
一旦到后备服务器的故障转移发生,就只有单一的一台服务器在操作。 这被称为一种退化状态。之前的后备服务器现在是主服务器, 但之前的主服务器处于关闭并且可能一直保持关闭。要回到正常的操作, 一个后备服务器必须被重建,要么在之前的主系统起来时使用它重建, 要么使用第三台(可能是全新的)服务器来重建。pg_rewind 工具可以用来在大型集群上加速此进程。一旦完成, 主服务器和后备服务器可以被认为是互换了角色。 某些人选择使用第三台服务器来为新的主服务器提供备份,直到新的后备服务器被重建, 不过显然这会使得系统配置和操作处理更复杂。
因此,从主服务器切换到后备服务器可以很快,但是要求一些时间来重新准备故障转移集群。 从主服务器到后备服务器的定期切换是有用的, 因为它允许每个系统有定期的关闭时间来进行维护。 这也可以作为一种对故障转移机制的测试,以保证在你需要它时它真地能够工作。 我们推荐写一些管理过程来做这些事情。
要触发一台日志传送后备服务器的故障转移,运行pg_ctl promote
或者创建一个触发器文件,其文件名和路径由recovery.conf
中的trigger_file
设置指定。如果你正在规划使用
pg_ctl promote
进行故障转移,trigger_file
就不是必要的。
如果你正在建立只用于从主服务器分流只读查询而不是高可用性目的的报告服务器,
你不需要提升它。
上一篇: 我们如何在考试检查评分场景背后进行再保险可用性测试
下一篇: 功能 - GitBook
推荐阅读
-
CSS-使用伪类制作小箭头(用于旋转图片的左/右切换按钮)
-
Axure 标签页切换功能-3.
-
Macbook Air 升级 Win10 进程和 Fn 键故障修复
-
TabLayout 故障排除:onTabSelected 未被回调
-
API 异常故障排除
-
paramiko 文件传输故障 Sftp 投放方法 坑洞阶梯点
-
Vue3+Nuxt3 从 0 到 1 建立官方网站项目(搜索引擎优化搜索、中英文切换、图片懒加载)
-
CSS 灵活方框模块切换效果
-
技术分享 | OceanBase 查询缓慢故障排除思路--从哪些信息入手?
-
子网划分、可变长度子网掩码和 TCP/IP 故障排除__子网划分、掩码、网络概述