ConfigNode and DataNode Scaling

1. ConfigNode
2. DataNode

1) 管理员通过Manager下发退服操作
2) Manager根据退服操作构造退服请求，发送给任意一个可以连接的节点执行。
实现上是执行对应的iotdbserver_decommission_launch.sh脚本
3) 脚本在该DataNode起进程构造RPC请求发送给ConfigNode，请求发送前会首先进行一些检查操作，如：待移除节点能否ping通，是否在IotDB集群中；接着向ConfigNode发送某些节点退服申请。
4) ConfigNode收到请求后，首先会进行基本检查：
本次请求中是否与之前请求之间有重复节点? 退服节点是否在集群中?退服能否满足副本数要求？请求个数是否达到上限？等。 如果检查不通过则直接返回Response，并记录不能退服原因； 如果满足退服条件，则把退服请求放在队列中，并返回Response表示请求处理中。
ConfigNode的缩容请求队列会通过共识层同步给其他follower角色的ConfigNode。
5) 接着ConfigNode取队首请求，遍历本请求中的所有节点，依次执行如下操作：
在ConfigNode内存的节点信息表中标记该DataNode节点状态为“开始缩容”，接着广播给集群其他所有节点该节点不可用，之后所有的读写请求都不会转发到该节点；广播结束后，更新节点状态为“region迁移中”。
ConfigNode的节点信息表也会通过共识层同步给其他follower角色的ConfigNode。节点信息表会记录缩容节点的状态信息。
6) ConfigNode接着遍历退服DataNode上保存的所有Region，生成Map并通过共识层把Map结构同步给其他ConfigNode。
遍历Map中的Region先检查Region是否是leader，如果是leader则进行leader切换； 等所有region都切换为follower后，开始进行Region数据迁移。如果有Region数据迁移失败，则意味着该节点退服失败，需要执行回滚：删除目标DataNode上的该region数据目录; 恢复DataNode节点状态，广播此节点可用。数据迁移通过ratis实现，迁移数据的一致性也由ratis保证。
7) DataNode执行Region数据迁移，迁移成功则通知ConfigNode，ConfigNode则从Map中移除该Region。如果待移除DataNode上的所有Region数据迁移成功， ConfigNode收到请求后把节点状态设置为“数据迁移成功”
8) 最后ConfigNode通知待退服DataNode停机下线，并把最终状态设置为“停止”

ConfigNode中保存的DataNode节点状态及其转移图如下。每切到新状态都会记录WAL，并通过共识层同步给其他ConfigNode。
如果最终状态是“缩容失败”就需要根据日志，进行手动干预。


图4-10 DataNode缩容期间状态转移图
图4-11 region状态转移图

该 issue 描述了 decommissionLaunch 和入口点 iotdbserver_decommission_launch.sh，包括 ConfigNode 和 DataNode 的状态转换、Region 迁移、回滚和关闭。首先定位该入口点和现有的 decommission 工作流；该 issue 未指定源文件或测试，其验收标准除了所描述的架构之外并未定义。

由索引模型根据 Issue 内容生成。