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 mô tả decommissionLaunch và entry point iotdbserver_decommission_launch.sh, bao gồm các chuyển đổi trạng thái của ConfigNode và DataNode, việc di chuyển Region, rollback và shutdown. Hãy bắt đầu bằng cách xác định entry point đó và decommission workflow hiện có; issue không nêu tên các tệp mã nguồn hoặc test, và các tiêu chí chấp nhận của issue không được định nghĩa ngoài kiến trúc đã mô tả.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.