背景

       集群创建成功后是不允许修改IP或Port的，集群启动后会将节点的信息保存在partitionTable中，且序列化到磁盘上形成partitions文件。但是，在某些场景下，修改服务器IP或Port的情况是存在的，需要支持这种情况

目标

       实现在对单一节点的IP或Port的修改，且在修改期间要保证数据的安全性，需要保证数据组不发生变化，且不产生数据的迁移。

设计思路

 

  1. 需要修改IP或Port的节点停止，修改配置文件，重启节点
  2. 重启节点会加载配置文件，此时会读取到配置文件中节点的IP和Port，同时重启节点会加载磁盘上的partitions，里面存储为旧的IP和Port，此时加上判断，取出paritions文件中读取到的当前节点node信息与配置文件的node信息进行比对，不一致则证明修改了配置文件中node信息，走修改node信息的流程。（此处从partitions文件中取出allnodes，找出node_identifier为当前节点的node信息与配置文件的node信息对比）
  3. 当前节点发起request给meta leader，并等待回复
  4. 当前节点不知道谁是meta leader，从seed_nodes中随机取出一个节点发送request，假如这个节点是leader则进行处理，不是leader的话路由到其他节点。
  5. Request请求包含的信息是新的node信息，即node类信息（新旧node信息中node_identifier是从磁盘上读取的，可认为新旧node信息node_identifier是一致的）
  6. 如果request请求没有响应或者超时，此时当前节点启动失败。
  7. Meta Leader收到请求后，进行安全检查，修改node信息是采用逐个节点进行修改，因此如果要修改多个节点，需要拆分成逐个节点进行修改，所以此时需要检查上次修改是否完成，如果没有的话需要拒绝这次请求。检查包括：上次的流程是否有阻塞节点。
  8. Leader将请求即node信息加入日志中，将日志发给元数据组的成员，等待超过半数以上节点收到信息
  9. 元数据组成员超过半数收到日志后，代表成功，此时meta leader再将node信息发送给所有的data group的leader，修改其中的node信息。
  10. 数据组的leader收到新node信息之后，将node信息发送给组内成员，成员收到日志信息后提交并且返回结果，等待超过半数以上节点已经处理
  11. 等待数据组都完成日志的处理，元数据leader提交日志，返回结果。
  12. 修改node信息的节点收到返回结果后，启动元数据组和数据组

 

部分问题处理

  1. 配置文件需要保证为最新的，以及所有节点配置文件相同.当集群中的节点修改成功ip和端口后，两种方案：a.其他节点也需要人工修改配置文件，然后重启节点（不重启也可，配置文件与内存中的seednode是一致的），保证集群中所有配置文件都是一致的b.其他节点的iotdb-confing.properties配置文件由程序进行修改，修改seednode的配置
  2. 目前master分支上针对nodeRing的排序方式为sort(nodeRing)，读取partitions文件重新排序的话会环会发生改变，产生数据迁移，因此修改为根据node_identifier进行排序
  3. 在修改node信息的过程中发生leader的变化？

              leader变化，那client就收不到原先leader的返回值，此时client等待超时之后重新发送请求。

接口设计

cluster.thrift：long sendModifyNodeInfo(1: Node node)

   return -1(RESPONSE_AGREE) or -3(RESPONSE_REJECT) and so on

 

  • No labels