CM集群手动故障切换

故障场景

网络分区前两节点集群状态正常，CM集群和数据库集群均为一主一备正常运行。

网络分区发生后，因CM集群自动故障切换参数cms_enable_failover_on2nodes未启用（两节点集群总票数为2），故CM集群备实例不会执行故障切换逻辑，保持standby角色； CM集群主实例因孤立而无法确保日志多数派提交而降级为standby，最终CM集群无主，且此时数据库集群同样不可用。如下图所示。

• 节点一上的CM集群状态

  

• 节点二上的CM集群状态

  

处理办法

确定故障前的数据库集群主实例，并对该节点上的CM实例执行强制升主操作。

确定数据库集群主实例

在每个节点上执行gs_ctl query -D <datapath>指令获取该节点上数据库实例的角色。如下图所示，输出Primary的节点即为数据库集群主实例。

若数据库集群无主实例，则通过gsql指令选择term/lsn大的实例（具体指令参见下图所示）作为数据库集群的主实例，并在该实例所在节点上施加failover操作（具体指令参见下图所示)，使之升主。需要注意的是：gsql无法连接处于Pending状态的数据库实例，该情况下，需要通过日志来判断数据库集群的原始主实例，具体方法请参考基于日志判定数据库集群主备关系。

CM实例执行强制升主

一旦确定数据库集群的主实例，则将对数据库主实例所在节点上的CM实例执行强制升主操作。具体指令请参考下图。

CM实例取消强制升主

经过前述步骤后，CM集群必然存在一个主实例，甚至可能会出现双主脑裂故障，如下图。

需要注意：无论CM集群是否存在双主脑裂故障，都需要针对前述强制升主的CM实例执行清除强制升主操作指令（如下图）。此后，CM集群则基于已有机制执行脑裂故障处理，选择term大的CM实例作为CM集群的唯一主实例。针对该机制可能导致的数据库集群的脑裂故障的处理，请参考数据库集群脑裂手动故障恢复进行处理。

附录

基于日志判定数据库集群主备关系

(1) 确定CM集群原始主实例

在CM集群的所有实例中查看最新的日志cm_server_时间戳_进程名-current.log，找到如下类似内容，拥有该内容的实例即为原始主实例。

2023-01-06 11:40:34.443 tid=7050 HA LOG: node(1) cms role is Primary, cms change to standby by ddb, and g_ddbRole is 2.

(2) 确定数据库集群原始主实例

在CM集群原始主实例的最新日志文件cm_server_时间戳_进程名-current.log中查找数据库集群最后一次（网络分区前）可用时的主备关系。以下日志供参考：

数据库集群拥有主实例，其所在节点索引为0，也即节点编号为6001

2023-01-06 11:30:47.088 tid=7046 CM_AGENT DEBUG1: [GetCandicate], instanceId(6001), this group has dynamic primary(0), validPrimIdx is 0, not need to choose candicate.

数据库集群拥有主实例，dyPrimary: [0: 6001: 1704]

2023-01-06 11:30:47.088 tid=7046 CM_AGENT LOG: [DnArbitrateNormal]: instd(6001) staPrimary: [0: 6001: 1704], dyPrimary: [0: 6001: 1704], dyNorPrim: [0: 6001: 1704], notPendCmd: [insInfo is empty], cascade: [sta: (insInfo is empty);  dy: (insInfo is empty)].

上述两条日志说明，网络分区前数据库集群的主实例所在节点索引为0，编号为6001。因为在本文档描述的故障处理过程中，将对该节点上的CM实例执行强制升主操作。