Orchestrator 一款是 MySQL 高可用high availability软件,主要用于 MySQL Master-Slave 主从架构。
从 v3.2.3 开始初步支持MGR MySQL Group Replication。但要求MySQL版本必须大于8.0。
改动主要包括三部分,实例探测、故障扫描, 以及故障处理。
在MySQL实例探测上,严格限制要求MySQL版本必须大于等于8.0,并且只支持单主模式(single primary mode)。
探测过程中执行的SQL是:
SELECT
MEMBER_ID,
MEMBER_HOST,
MEMBER_PORT,
MEMBER_STATE,
MEMBER_ROLE,
@@global.group_replication_group_name,
@@global.group_replication_single_primary_mode
FROM
performance_schema.replication_group_members
WHERE
MEMBER_STATE != 'OFFLINE'
通过执行这个查询SQL,可以发现这个MGR集群中的member。
在故障扫描部分,利用前面实例探测中获取到信息,区分出是Master-Slave架构还是MGR架构,接着判定相应的故障。
GetReplicationAnalysis
故障扫描函数中,增加replication group member的判断:
MIN(
master_instance.replication_group_name != ''
AND master_instance.replication_group_member_state != 'OFFLINE'
) AS is_replication_group_member,
如果是MGR架构,再具体条件判定故障类型:
/* Group replication issue detection */ {
// Group member is not reachable, has replicas, and none of its reachable replicas can replicate from it
if !a.LastCheckValid && a.CountReplicas > 0 && a.CountValidReplicatingReplicas == 0 {
a.Analysis = DeadReplicationGroupMemberWithReplicas
a.Description = "Group member is unreachable and all its reachable replicas are not replicating"
}
判定故障以后,接着进行故障处理,新增了MGR的故障处理函数checkAndRecoverDeadGroupMemberWithReplicas
。其中的故障处理注册 recovery register 操作逻辑与 Master-Slave架构相同。
故障处理基本过程:
针对这个故障处理逻辑,没有特别理解。
按照以前对MGR的理解,如果primary member宕机了,会自动重新选举一个group member作为新的primary member。
这个问题,后面再详细看下。
以上,将Orchestrator对MGR集群的故障探测和处理做了简要介绍。