怎样通过日志分析rac各种脑裂发生的原因

Posted 2023-04-17

tags:

篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了怎样通过日志分析rac各种脑裂发生的原因相关的知识，希望对你有一定的参考价值。

参考技术A OracleRACCSS提供2种后台服务包括群组管理(GroupManagment简称GM)和节点监控(NodeMonitor简称NM)，其中GM管理组(group)和锁(lock)服务。在集群中任意时刻总有一个节点会充当GM主控节点(masternode)。集群中的其他节点串行地将GM请求发送到主控节点(masternode)，而masternode将集群成员变更信息广播给集群中的其他节点。组成员关系(groupmembership)在每次发生集群重置(clusterreconfiguration)时发生同步。每一个节点独立地诠释集群成员变化信息。而节点监控NM服务则负责通过skgxn(skgxn-libskgxn.a，提供节点监控的库)与其他厂商的集群软件保持节点信息的一致性。此外NM还提供对我们熟知的网络心跳(Networkheartbeat)和磁盘心跳(Diskheartbeat)的维护以保证节点始终存活着。当集群成员没有正常Networkheartbeat或Diskheartbeat时NM负责将成员踢出集群，被踢出集群的节点将发生节点重启(reboot)。NM服务通过OCR中的记录(OCR中记录了Interconnect的信息)来了解其所需要监听和交互的端点，将心跳信息通过网络发送到其他集群成员。同时它也监控来自所有其他集群成员的网络心跳Networkheartbeat，每一秒钟都会发生这样的网络心跳，若某个节点的网络心跳在misscount(bytheway:10.2.0.1中Linux上默认misscount为60s，其他平台为30s，若使用了第三方vendorclusterware则为600s，但10.2.0.1中未引入disktimeout；10.2.0.4以后misscount为60s,disktimeout为200s；11.2以后misscount为30s:CRS-4678:Successfulgetmisscount30forClusterSynchronizationServices,CRS-4678:Successfulgetdisktimeout200forClusterSynchronizationServices)指定的秒数中都没有被收到的话，该节点被认为已经”死亡”了。NM还负责当其他节点加入或离开集群时初始化集群的重置(Initiatesclusterreconfiguration)。在解决脑裂的场景中，NM还会监控votingdisk以了解其他的竞争子集群(subclusters)。关于子集群我们有必要介绍一下，试想我们的环境中存在大量的节点，以Oracle官方构建过的128个节点的环境为我们的想象空间，当网络故障发生时存在多种的可能性，一种可能性是全局的网络失败，即128个节点中每个节点都不能互相发生网络心跳，此时会产生多达128个的信息”孤岛”子集群。另一种可能性是局部的网络失败，128个节点中被分成多个部分，每个部分中包含多于一个的节点，这些部分就可以被称作子集群(subclusters)。当出现网络故障时子集群内部的多个节点仍能互相通信传输投票信息(votemesg),但子集群或者孤岛节点之间已经无法通过常规的Interconnect网络交流了，这个时候NMReconfiguration就需要用到votingdisk投票磁盘。因为NM要使用votingdisk来解决因为网络故障造成的通信障碍，所以需要保证votingdisk在任意时刻都可以被正常访问。在正常状态下，每个节点都会进行磁盘心跳活动，具体来说就是会到投票磁盘的某个块上写入disk心跳信息，这种活动每一秒钟都会发生，同时CSS还会每秒读取一种称作”killblock”的”赐死块”，当”killblock”的内容表示本节点被驱逐出集群时，CSS会主动重启节点。为了保证以上的磁盘心跳和读取”killblock”的活动始终正常运作CSS要求保证至少(N/2+1)个投票磁盘要被节点正常访问，这样就保证了每2个节点间总是至少有一个投票磁盘是它们都可以正常访问的，在正常情况下(注意是风平浪静的正常情况)只要节点所能访问的在线votingdisk多于无法访问的votingdisk，该节点都能幸福地活下去，当无法访问的votingdisk多于正常的votingdisk时，ClusterCommunicationService进程将失败并引起节点重启。所以有一种说法认为votingdisk只要有2个足以保证冗余度就可以了，没有必要有3个或以上votingdisk，这种说法是错误的。Oracle推荐集群中至少要有3个votingdisks。补充1：Question:有同学问那么votingdisk必须是奇数个呢？Answer:实际上我们仅仅是推荐使用奇数个votedisk，而非必须是奇数个。10gR2中votedisk的数目上限是32个。Question我们可以使用2或4个votedisk吗？Answer:可以的。但是2、4这样的数目在“至少(N/2+1)个投票磁盘要被节点正常访问”这一diskheartbeat的硬性算法下是不利的：当我们使用2个votedisk时，不能发生任意个votedisk的心跳失败当我们使用3个votedisk时，不能发生大于1个的votedisk心跳失败当我们使用4个votedisk时，不能发生大于1个的votedisk心跳失败，这和3个时的容错率是一样，但是因为我们有的votedisk，这会导致管理成本和引入的风险增长当我们使用5个votedisk时，不能发生大于2个的votedisk心跳失败当我们使用6个votedisk时，仍然不能发生大于2个的votedisk心跳失败，同样的因为比5时多出一个，也会引入不合理的管理成本和风险补充2：Question:若节点间的网络心跳正常，且节点所能正常心跳的votedisk大于不能正常访问的，如3个votedisk时恰巧有1个votedisk的diskheartbeat超时，此时Brainsplit会发生吗？Answer:这种情况即不会触发BrainSplit，也不会引发节点驱逐协议(evictionprotocol)。当单个或小于(N/2+1)个的votingdisk心跳失败(diskheartbeatfailure)时，这种心跳失败可能是由于短期内节点访问votingdisk发生I/Oerror错误而引起的，此时css会立刻将这些失败的votingdisk标记为OFFLINE。虽然有一定数量的votingdiskOFFLINE了，但是我们仍有至少(N/2+1)个投票磁盘可用，这保证了evictionprotocol不会被调用，所以没有节点会被reboot重启。紧接着nodemonitor模块的DiskpingMonitorThread(DPMT-clssnmDiskPMT)会重复尝试访问这些失败的OFFLINEvotingdisk，若这些投票磁盘变得再次可I/O访问且经过验证其上的数据也没有讹误，那么css会再次将此votingdisk标记为ONLINE；但是如果在45s(这里的45s是基于misscount和内部算法获得的)内仍不能正常访问相关的votingdisk，那么DMPT将在cssd.log中生成警告信息，如：

基于权重的节点驱逐 - Oracle RAC 12.2 新特性

在 Oracle RAC 中，多个节点之间需要能够正常通信来保持集群的一致性。当一个节点发生故障或者发生脑裂，节点因网络等原因不能与其他节点互通时，很可能会在集群重新配置的过程中被驱逐出去。

RAC 的重新配置包含两个层面，一个是集群层面的，在发生脑裂的时候一般是基于编号做节点驱逐；另一个是实例层面的，这时候是根据节点获得的 RR 锁的权限判断的。在12.2之前，通过以上两种方式的重新配置，系统可以通过规则和计算自动决定哪个节点将会被驱逐出去。

而从12.2开始，引入了基于权重的节点驱逐。

在官网对该功能的介绍如下：

在 Oracle Clusterware 需要从集群中驱逐特定节点或一组节点的情况下，基于服务器权重的节点驱逐作为一种决胜机制，在这种情况下，所有节点代表驱逐的平等选择。在这种情况下，基于服务器权重的节点驱逐机制有助于基于有关这些服务器上的负载的附加信息来识别要驱逐的节点或节点组。存在两种主要机制，即系统固有的自动机制和基于用户输入的机制，以提供相应的指导。

使用基于服务器权重的节点驱逐允许在集群中的某些故障与业务需求之间调整哪个节点被逐出的选择，确保最重要的工作负载尽可能长时间保持活动，假设服务器之间的相等选择。

也就是说，12.2中的节点驱逐不是有系统自动决定的，而是可以根据业务关系，做更精细的控制。避免自动模式下的偏差对核心业务的影响。

特性介绍

可以手动设置 Oracle RAC 集群故障恢复机制，在节点不能互相通信的时候，该机制就会生效，决定哪些节点会被驱逐出去。

在脑裂的情况下，当集群发生了网络分裂，会将集群的节点划分为若干个不相交的分组，集群管理软件会通过特定的规则将部分节点从集群中踢出去。一般来说，会把那些大量占用系统关键资源的节点踢出去。

可以通过向数据库实例或节点添加值来影响决策的结果，以便在 Oracle Clusterware 必须决定是驱逐还是终止时，会考虑这些因素并尝试确保所有关键组件都可用。可以配置权重函数来为群集中的关键组件添加权重，从而在决定在解决裂脑情况时排除哪些节点时增加输入。

使用与配置

在一些场景下，用户可能希望确保特定的节点不会在基于默认的投票规则中被踢出去，或者是为了保持某些硬件特性，某些资源因为特定的数据库或服务而存活，因此引入基于权重的驱逐。用户可以根据以下标准为特定节点，资源或服务分配权重：

只将权重分配给由 administrator 管理的节点。
可以将权重分配给已注册 Oracle Clusterware 资源的服务器或应用程序。

权重有助于协调不同组件的重要等级，并影响 Oracle Clusterware 在管理裂脑情况时所做的选择。在其他关键因素相同的情况下，Oracle 集群件选择权重最高的的节点保留在集群中。

使用场景

可以为各种组件分配权重，如下所示：

为数据库实例或服务分配权重，可以在添加数据库实例或服务时将 -css_critical yes 参数与 srvctl add 数据库或 srvctl add service 命令一起使用。也可以使用 srvctl modify database 和 srvctl modify service 命令的参数。
为非 ora.* 资源分配权重，请在添加或修改资源时使用 crsctl add resource 和 crsctl modify resource 命令的 “attr”CSS_CRITICAL = yes 参数。
为服务器分配权重，请使用 crsctl set server 命令使用 -css_critical yes 参数。