在线reform

特性简介

reform：在集群出现变化的情况下，例如新节点加入、节点重启等，集群从不可用状态转变为可用状态。这一系列变动称之为reform。

我们将单个集群中的单一变化分为以下场景：

• 场景1：新节点（主机）加入集群：只在建库后的首轮出现。

• 场景2：新节点（备机）加入集群。

• 场景3：主机故障重启。

• 场景4：备机故障重启。

• 场景5：备节点被踢出集群。

• 场景6：failover（主节点被踢出集群）。

• 场景7：switchover。

• 场景8：新节点一直加入失败并最终被踢出：属于场景2和场景5的组合场景，因为该场景需要特殊处理，所以单独列出。

对应当前4种类型reform：

• normal reform：对应着reformer锁没有出现由一个节点持有变成另一个节点持有，包含着场景1、2、3、4、5。

• failover reform：对应着reformer锁出现一个节点持有变成另一个节点持有，对应场景6。

• switchover reform：对应着场景7。

• full clean reform：对应着场景8。

reformer锁由集群资源管理软件HAS提供，各个DB节点向HAS发起抢锁请求，抢到reformer锁的节点被称之为reformer，其他节点被称之为partner。由reformer节点定期获取HAS提供的节点情况，以及感知当前集群中所有节点的状态，从而确认集群出现何种变化。当集群出现变化后，reformer节点可以组织一轮reform，从而让集群恢复正常。

对于复杂场景，例如主节点被踢出集群+新节点（备机）加入，根据reformer锁信息出现了节点间的变化，由failover reform处理。例如备机故障重启+（另一个备机）被踢出，reformer信息没有出现变化，属于normal reform。

对于swithover reform是由一个稳定集群下进行，在叠加故障下，不会进行switchover。对于full clean reform，如果出现叠加故障，根据锁信息的是否变更，由failover reform或者normal reform进行处理。

在线reform

在过去的版本中，所有场景下的reform需要集群中所有节点中断业务，对应的业务线程全部退出。这一做法影响业务的运行，对此我们提出在线reform。

在线的含义：在reform过程中，非故障的节点在reform前进行的业务不会因为发生reform而被中断，在reform结束后可以继续运行。

由此看出在线reform不是一种reform类型，而是reform的属性。即某一种类型的集群变化是否支持“在线”这一功能。

对于新节点（备机）加入集群、备机故障重启、备节点被踢出集群、新节点一直加入失败并最终被踢出，这些场景的情况较为类似，我们称之为备机场景。

当前在线reform，仅支持备机场景。

• 暂不支持主机故障重启；
• 对于failover、switchover暂不支持；
• 新节点（主机）加入集群，在reform前没有业务连接，不涉及在线reform。

场景的支持情况：

reform类型的支持情况：

客户价值

在资源池化架构下，当集群出现的变化属于备机场景时，非故障的节点的业务没有中断，在集群恢复正常后仍可继续运行。该特性提高集群的可用性，更好为用户提供服务。

特性描述

在资源池化架构下，在特定的reform场景中（仅备机场景），reform前的业务不会因为reform被中断，reform完成后还能继续运行。

特性约束

• 在资源池化架构下，无参数决定在线reform功能是否开启，该特性默认开启。
• 在资源池化架构下，单集群部署下，failover场景、switchover场景不支持在线reform，其余场景均支持。
• 在资源池化架构下，在支持在线reform场景的情况下，业务不会被中断，但也不会继续运行，直到页面放开访问（reform中的一个阶段）完成，业务才能跑下去。
• 在资源池化架构下，双集群的部署下，备集群的所有场景，都不支持在线reform；主集群的场景的支持情况与单集群相同。