知晓：故障检测与网络分区 - 深入浅出MGR2022/12/26 17:17:31

哦不明白

发生故障时，只有当多数派节点存活前提下，故障检测机制才能工作正常，使得MGR恢复可用性；当多数派节点本身已经异常的时候，MGR是法自行恢复的，需要人为介入。本文介绍MGR的故障检测机制，以及发生络分区后如何处理。域名IP查询的具体问题可以到我们网站了解一下，也有业内领域专业的客服为您解答问题，为成功合作打下一个良好的开端！

1故障检测当MGR中个别节点与其他节点通信异常时，就会触发故障检测机制，经过多数派节点投票判断后再决定是否将其驱逐出MGR。

发生故障时，只有当多数派节点存活前提下，故障检测机制才能工作正常，使得MGR恢复可用性；当多数派节点本身已经异常的时候，MGR是法自行恢复的，需要人为介入。

MGR中，各节点间会定期交换消息，当超过5秒（在MSQL中是固定5秒，在GSQL中新增选项____?可配置）还没收到某个节点的任何消息时，就会将这个节点标记为可疑状态。MGR各正常存活节点会对可疑节点每隔15秒检测一次（在GSQL中，调整为每隔2秒检测，效率更高，下面再介绍），当确认可疑节点在超过____秒超时阈值后，再将该节点驱逐出MGR。

需要注意的是，选项____?从MSQL8021开始，默认值为5。在MSQL8021之前，默认值为0。在=MSQL8020的版本中，____默认值为0，也就是当某节点被判定为可疑状态后，会被立即驱逐。在MSQL57中，没有该选项，行为模式也是一样的。

在MSQL中，MGR故障检测是由单独线程来完成的，该线程每隔15秒（MSQL在源码中硬编码定义了SUSPICION_PROCESSING_THREAD_PERIOD=15）进行一次检查。因此，节点发生故障时，极端情况下，可能要耗费5（5秒没发送消息，被判定为可疑节点）+15（SUSPICION_PROCESSING_THREAD_PERIOD）+5（____）=25秒才能驱逐该节点。比较好的情况下，比较5+5=10秒后即可驱逐该节点。

在GSQL中对此进行了化，新增选项____?（默认值5，比较小3，比较大60）用于定义节点超过多少秒没发消息会被判定为可疑。此外，还修改了硬编码SUSPICION_PROCESSING_THREAD_PERIOD=2?，也就是故障检测线程每2秒（而非15秒）就会检查一次。因此在GSQL中，比较5（____）+5（____）=10秒?完成驱逐，比较慢5+5+2（SUSPICION_PROCESSING_THREAD_PERIOD）=12秒完成驱逐。

在络条件不好的情况下，建议适当加大____值，避免络波动造成节点频繁被驱逐。不过也要注意另一个风险，见这篇文章所述：技术分享|为什么MGR一致性模式不推荐AFTER

存活的节点会把被驱逐的节点从成员列表中删除，但被驱逐的节点自身可能还没“意识”到（可能只是因为临时短时间的络异常），在状态恢复后，该节点会先收到一条包含该节点已被驱逐出MGR的新视图信息，而后再重新加入MGR。被驱逐的节点会尝试___次重新加入MGR。

选项____?定义了被驱逐节点之后的行为模式，默认是设置为__=ON，进入只读模式。

2少数派成员失联时当集群中的少数派成员失联时（U），默认不会自动退出MGR集群。这时可以设置____?，当少数派节点和多数派节点失联超过该阈值时，少数派节点就会自动退出MGR集群。如果设置为0，则会立即退出，而不再等待。节点退出集群时，相应的事务会被回滚，然后节点状态变成ERROR，并执行选项____?定义的后续行为模式。如果设置了___，也会再自动尝试重新加入MGR集群。

3多数派成员失联时当多数派节点也失联时（U），例如在一个3节点的MGR集群中，有2个节点失联了，剩下的1个节点不能成为多数派，也就法对新事务请求做出决策，这种情况就是发生了络分区（脑裂）。也就是一个MGR集群分裂成两个或多个区域，也因此缺少多数派，这种情况下，MGR集群法提供写入服务。

此时需要人工介入，通过设置___?强行指定新的成员列表。例如MGR集群由3个节点组成，其中两个节点都意外失联了，仅剩一个节点存活，此时就需要手动设置___强行指定成员列表，也就是只有比较后存活的节点。

两个重要提醒：

使用该方法基本上是比较后迫不得已的选择，因此需要非常谨慎。若使用不当，可能会造成一个人为的脑裂场景，或者造成整个系统被完全阻塞。也有可能会选错新的节点列表。强制设定新的节点列表并解除MGR阻塞后，记得再将该选项值清空，否则法再次执行STARTGROUP_REPLICATION。

4X当有节点处于可疑状态时，在它被确定踢出MGR集群之前，事务会缓存在其他节点的X中。这个对应选项____。当可疑节点短时内又恢复后，就会先从X中读取记录进行恢复，然后再进行分布式恢复。因此，在络不太稳定或并发事务较大，且物理内存也足够的场景里，可以适当加大X；反之，在物理内存较小，或者络较为稳定的场景里，不应设置太大，降低发生OOM的风险。

在MSQL57里，X比较大值1G，且不可动态调整。从MSQL80开始，可对其动态调整。在=MSQL8020的版本中，比较小值1G。在=MSQL8021的版本中，比较小值128M。

可以执行下面的SQL查看当前X消耗情况：

[@GSQL]SELECT*FROM______WHEREEVENT_NAMELIKE‘_GCS_XC::_';在MSQL中，是动态按需分配X的，如果太多有空闲，就释放；如果不够用，再动态分配更多内存，一次分配大概250000个，很容易造成约150的响应延迟。也就是说，会随着事务多少的变化而可能频繁产生响应延迟。

在GSQL中，对X采用了静态化分配机制，即一开始就预分配约1GB内存用于，这可以避免前面提到的响应延迟抖动风险，不过“副作用”是进程所占用的内存会比原来多，在内存特别紧张的服务器上不太适合。

5络分区在MGR里，事务是需要经过多数派节点达成一致性共识（要么都提交，要么都回滚）。同样的，前面提到的节点间通信消息也是需要在多数派节点间达成共识。当MGR中的多数派节点失联时，就法就此形成共识，也法满足多数派投票仲裁要求，此时MGR将拒绝写事务请求。这种情况，也称为络分区，及一个MGR集群分裂成两个或多个分区，彼此间相互法连通，任何一个分区中的节点都不能达成多数派。

可能P节点会因为络分区时被踢出MGR集群，它在重新加回时，可能会因为本地有此前还没来得及同步到其他节点的事务，而造成本地有更多事务，会报告类似下面的错误：

TL::1-300917674G::1-300917669此时需要人工介入处理，选择哪个节点作为比较新的P节点。

6小结本文介绍了MGR的故障检测机制、X，什么是络分区，以及发生故障时都有什么影响，如何恢复故障等。

参考资料、文档MSQL80RM(80-)

数据库内核开发-温正湖(_206071340)

GR原理-宋利兵(1O-KISAU1HLSEVLG9)