【转】PG集群高可用中对脑裂的防止与恢复

杰克牌辣酱

已于 2022-11-17 20:32:32 修改

阅读量720

点赞数

文章标签：数据库 postgresql

于 2022-11-17 11:42:02 首次发布

原文链接：https://www.modb.pro/db/24434

版权

转，原文地址 PG集群高可用中对脑裂的防止与恢复 - 墨天轮

PG集群高可用中对脑裂的防止与恢复

开源软件联盟PostgreSQL分会2020-04-21

原作者：刘世泽中国PostgreSQL分会志愿者高级内核开发工程师

概要

1.流复制集群的脑裂（双主）

1.1形成脑裂的原因

1.2脑裂发生时的人工处理

1.3关于时间线（timeline）

2.集群切换的判断指标和主备监控程序的协同机制

3.Virtual IP的使用与管理

4.Witness 节点的使用

5.数据库启动控制检查逻辑

6.脑裂的实时探测与自动修正

总结

概要

本文探讨了PG流复制集群中脑裂现象的发生原因、影响因素。并提出了一些避免脑裂现象的手段，最后介绍了一种在PG集群的高可用管理中实施脑裂探测和自动修正的思路。

1.流复制集群的脑裂（双主）

流复制集群的脑裂通常是指有两个节点同时认为自己是主节点，并且同时承担业务数据，使得流复制集群中的数据不一致。

1.1形成脑裂的原因

通常造成脑裂现象的原因一是主备之间网络问题导致备库误认为主库故障，切换后造成两主；另一大原因是误操作导致，比如主备切换之后，人为直接用pg_ctl将原主节点拉起，或系统自启动时直接调用pg_ctl启动数据库。

1.2脑裂发生时的人工处理

形成脑裂之后，通常需要人工介入，且介入得越早越好。假如可以忽视脑裂期间由于数据去向分叉造成的部分数据丢失，可以通过pg_rewind将其中一个节点重新作为备节点加入集群，恢复单主的集群状态。

由于执行pg_rewind需要由低timeline向更高的timeline同步，所以需要首先判断脑裂节点各自的时间线timeline。人工判断各节点时间线可以参考数据库data目录的pg_wal目录下 *.history文件，该文件是记录时间线的历史文件，每次时间线切换时都会生成新的时间线历史文件，从最新的历史文件中可以找到节点最新的时间线。确认好脑裂节点各自时间线之后，即可确定pg_rewind的方向，即从低timeline节点向高timeline节点执行rewind.

1.3关于时间线（timeline）

时间线timeline是PG在涉及备份恢复时配合wal日志的一种机制。

下面的例子简要说明了timeline的作用，例如操作人员在周五晚间想要恢复到前一天早晨的状态，而后发现问题又想要回到周五早晨的状态。如果没有时间线，当数据库恢复到周四状态时，随着数据库的运行，原有wal日志文件中周四到周五的文件内容会被覆盖，导致无法恢复到原先周四之后的数据状态。

在加入了时间线 timeline之后，恢复操作会新启一条timeline，在新的timeline上的日志不会覆盖其他timeline日志。

引入时间线能够确保数据库做恢复时不会导致覆盖掉原有的wal日志。PG的wal日志文件的命名中的前8个字节用来标识timeline，比如000000010000000000000002代表timeline1的第二段日志。

另外每次新启timeline都会生成一个timeline.history文件（如下图）。该文件中会记录每个timeline起始时的wal地址，以及timeline切换的说明，在选择基于时间线的恢复时，可以指定恢复到的时间线。

2.集群切换的判断指标和主备监控程序的协同机制

在PG流复制集群高可用的管理中，failover是其基本功能。Failover判断依据的严格性将同时影响高可用的切换效率和造成脑裂的潜在风险，完善的切换判断条件可以尽可能避免误切换造成的脑裂。

备库端的监控程序在判断切换的指标中应当包含下列维度，只有全部维度的检查条件都满足才可以进行备->主的切换操作。

在主库端，针对主库状态的监控程序需要在重连尝试失败并判定可能满足备库切换条件时，在主库节点上第一时间进行vip的解除操作，并可同时强制执行停库操作，确保此时主库处于停库状态。

若主库端主机发生了断电后的重启，高可用管理模块需要在数据库启动前的检查中首先实施解除vip操作，保证启动时不承接业务数据，并同时应当检查当前集群状态，若已经有其他主节点，则不应直接以主库状态启动，而应实施pg_rewind操作重归集群（详见第五章节）。

上述备库的切换检查和主库端的协同检查机制相互配合有利于避免由于主备切换期间造成的脑裂现象。

3.Virtual IP的使用与管理

集群中Virtual IP应当始终只挂载在主节点上，对vip管理的严格性与否同样会影响脑裂可能性。主备切换过程中vip的挂载/卸载容易造成同一vip同时挂载在两台主机上。为避免这种情况，集群高可用对vip的管理可以考虑如下逻辑。

Vip的挂载检查

在备机进行promote操作时，通常需要伴随vip的挂载操作，此时可以在挂载前检查该vip的连通性，如果仍然有连接，说明vip此时并未被前任主库所在节点卸载，应当避免备库立即进行promote行为和vip的挂载操作，此种情形下可在等待超时后进行跨节点解除vip操作。

Vip的卸载

在原主库节点上，高可用监控程序可在如下时机进行vip的卸载操作

1. 监测到主库失联，满足切换条件时

2. 在节点重启，实施开机自启动检查时

但在极端情况下，vip的卸载工作无法自动完成，比如针对原主节点的高可用监控程序失效、异常退出时，此时需要依赖于竞选成功的备节点进行跨节点卸载vip操作。

4.Witness 节点的使用

witness节点是处理集群主库和备库之间可能存在网络拥塞、延迟、路由等问题影响，导致主库还在正常工作，而备库无法联系主库的场景。

通过设置witness节点可以针对主库与备库之间切换的检查完整性，即辅助备节点监控程序实施主节点网络可见性检查，避免因网络问题导致的脑裂现象。

在此场景下，若备库端高可用监控简单依据与主库的失联即实施切换操作，显然不合理，极容易导致脑裂现象。可行的方案是在集群中设置witness节点作为辅助观察点，在备库观察到与主库失联时，可同时查看witness节点的可见性，若witness可见则实施切换。

而如果备节点在与主库失联的情况下，同时无法联系witness节点，此时由于无法满足切换条件中集群可见节点需大于全部节点数1/2的原则，因此不会进行切换。

5.数据库启动控制检查逻辑

形成脑裂的主要因素除了误切换，主要就是在启动数据库时的误操作。

当主库停库或者断电之后进行数据库重启的操作时，需要根据当前集群其他节点的状态决定采取什么样的启动操作。比如当集群中已经有新promote的主节点时，原主节点的数据库不可直接采取强制启动操作（使用pg_ctl），而应执行一系列检查逻辑。否则极容易在人工启动数据库或者系统自启动时形成脑裂。针对此点，高可用可以提供封装好的数据库节点启动接口。下面是一套可行的节点启动逻辑，可以帮助数据库维护人员在节点维护时实施傻瓜式节点启动操作，也可以作为操作系统开机启动数据库的启动服务脚本运行，通过这种封装后的命令作为统一的启动接口，可以有效避免启库瞬间造成的脑裂状态。

6.脑裂的实时探测与自动修正

对于PG的集群高可用监控程序，可以在实时监控进程中增加对集群中所有节点的定期角色状态检查，一旦发生双主节点这种角色互斥问题，可以实施报警提示人工处理或直接由监控程序自我修复。这种探测机制无法完全保证在脑裂发生的第一时间即探测到，因脑裂发生的部分案例是由于各节点之间的网络互通问题，在网络恢复之前，相互失联的各节点之间无法探知对方状态。但仍然可在无人值守的系统中，尽可能早的警示脑裂，并尽早处理。

对于监控程序探测到脑裂的自动修正，其基本逻辑类似于1.2节中提到的人工修复脑裂状态，即将脑裂的判断与处理步骤自动化，省去人工检查和判断。但需要注意的是这种恢复行为由于是从两条PG时间线中挑选一条恢复，舍弃的时间线上的部分数据将被忽视。