repmgr的见证节点和守护进程

标签：检查   程序   故障转移   角色   strong   恢复操作   不可   str   mamicode   

数据库不可用的常见原因

在PostgreSQL复制中，由于几个原因，主数据库可能变得不可用。例如：

• 主节点的操作系统可能崩溃或变得无响应
• 主节点可能会失去其网络连接
• 主节点中的PostgreSQL服务可能崩溃，停止或意外变得不可用
• 主节点中的PostgreSQL服务可以有意或无意停止

每当主服务器不可用时，备用服务器都不会自动将其自身升级为主角色。备用服务器仍继续为只读查询服务-尽管数据将一直保持最新状态，直到从主服务器接收到的最后一个LSN。任何写操作尝试都将失败。

有两种方法可以减轻这种情况：

• 备用数据库已手动升级为主机。计划内的故障转移或“切换”通常是这种情况
• 备用数据库自动升为主机，由工具连续监视复制并在主数据库不可用时采取恢复操作。repmgr就是这样一种工具

备用数据库自动升级为主机主要有以下挑战：

• 如果有多个备用数据库，repmgr如何确定将哪个数据库升级为主数据库？
  
• 对于多个备用数据库，如果将其中一个升级为主数据库，那么其他节点如何“跟随它”作为新的备用数据库？
• 如果主数据库服务器正常运行，但由于某种原因暂时脱离网络，该怎么办？如果将其中一个备用数据库升级为主要数据库，然后原来的主要数据库重新联机，此时集群中就出现了2个主机（脑裂），那么如何避免出现“脑裂”情况？

repmgr提供的解决方案为提供见证节点和repmgr守护程序

完整的集群架构参考下图：

见证节点 

见证节点主要的工作是帮助备用数据库达到法定的数量

简单来讲，备机连不上主机了，就会连接见证节点，如果也连接不上见证节点，那判断自己网络故障了，如果能连上见证节点，则认为主机故障，见证节点的作用类似于一个信任的网关。

守护程序repmgrd

remgrd启动后会作为常规服务运行并持续监视集群的运行状况。当达到与主机数据库失去联系的法定人数时，它将启动故障转移。它不仅可以自动升级备用数据库，还可以在多节点群集中重新启动其他备用数据库以跟随新的主数据库。

如何仲裁哪台备机升主

• 每个备用数据库检查到主机数据库故障后会进行重试，重试最后一次后，会去询问其他备用数据库。如果其它备用节点的最后一个复制的LSN或与主节点的最后一次通信的时间比当前节点的最后一个复制的LSN或最后一次通信的时间更近，则该节点不执行任何操作，并等待与主节点的通信恢复。
• 如果所有备用数据库都看不到主数据库，则它们将检查见证节点是否可用。如果也无法到达见证节点，则备用服务器会假定主服务器端发生网络中断，因此不会继续选择新的主服务器
• 如果可以联系到见证人，则备用服务器会假定主服务器已关闭，然后继续选择主服务器
• 然后将升级配置为“首选”主节点的节点。每个备用数据库将重新初始化其复制，以跟随新的主数据库。

repmgr的见证节点和守护进程

标签：检查   程序   故障转移   角色   strong   恢复操作   不可   str   mamicode   

原文地址：https://www.cnblogs.com/mingfan/p/12791006.html