对应当前 4种类型reform：
normal reform：对应着reformer锁没有出现由一个节点持有变成另一个节点持有，包含着场景1、2、3、4、5
failover reform：对应着reformer锁出现一个节点持有变成另一个节点持有，对应场景6
switchover reform：对应着场景7
full clean reform：对应着场景8
reformer锁由CM（集群资源管理软件，Cluster Manager）提供，各个DB节点向CM发起抢锁请求，抢到reformer锁的节点被称之为reformer，其他节点被称之为partner。由reformer节点定期获取CM提供的节点情况，以及感知当前集群中所有节点的状态，从而确认集群出现何种变化。当集群出现变化后，reformer节点可以组织一轮reform，从而让集群恢复正常。
对于复杂场景，例如主节点被踢出集群+新节点（备机）加入，根据reformer锁信息出现了节点间的变化，由failover reform处理。例如备机故障重启+（另一个备机）被踢出，reformer信息没有出现变化，属于normal reform。 对于swithover reform是由一个稳定集群下进行，在叠加故障下，不会进行switchover。对于full clean reform，如果出现叠加故障，根据锁信息的是否变更，由failover reform或者normal reform进行处理。
在6.0.0-RC1版本之前，所有场景下的reform需要集群中所有节点中断业务，对应的业务线程全部退出。这一做法影响业务的运行，对此我们提出在线reform。
在线的含义：在reform过程中，非故障的节点在reform前进行的业务不会因为发生reform而被中断，在reform结束后可以继续运行。
由此看出在线reform不是一种reform类型，而是reform的属性。即某一种类型的集群变化是否支持在线这一功能。
对于新节点（备机）加入集群、备机故障重启、备节点被踢出集群、新节点一直加入失败并最终被踢出，这些场景的情况较为类似，我们称之为备机场景。
当前在线reform，仅支持备机场景，以及主机故障重启；对于failover、switchover暂不支持；新节点（主机）加入集群，在reform前没有业务连接，不涉及在线reform。
场景的支持情况
| 编号 | 描述 | 是否支持在线reform |
|---|---|---|
| 场景1 | 新节点（主机）加入集群 | 不涉及 |
| 场景2 | 新节点（备机）加入集群 | 支持 |
| 场景3 | 主机故障重启 | 支持 |
| 场景4 | 备机故障重启 | 支持 |
| 场景5 | 备节点被踢出集群 | 支持 |
| 场景6 | failover | 不支持 |
| 场景7 | switchover | 不支持 |
| 场景8 | 新节点一直加入失败被踢出 | 支持 |
详情查看：opengauss.org 详情查看：docs-opengauss.osinfra.cn
