diff --git a/docs/design_docs/dataservice_recovery_design.md b/docs/design_docs/dataservice_recovery_design.md index 4dbeafbe8e..8582013b9b 100644 --- a/docs/design_docs/dataservice_recovery_design.md +++ b/docs/design_docs/dataservice_recovery_design.md @@ -1,67 +1,61 @@ ### timetick 相关改动 -Datanode发送timetick msg需要有channel的信息，DataCoord根据channel来检查segment是否可以seal和flush - - +Datanode 发送 timetick msg 需要有 channel 的信息，DataCoord 根据 channel 来检查 segment 是否可以 seal 和 flush ### 服务发现 -DataCoord启动时检查是否有新的或重启过的DataNode，如果有重启过的，重新注册channel，并seek到上次记录的位置 +DataCoord 启动时检查是否有新的或重启过的 DataNode，如果有重启过的，重新注册 channel，并 seek 到上次记录的位置 -通过watch机制监听DataNode的状态，如果DataNode下线，其注册的channel重新分配到其他node，并seek到上次的位置（重新分配不一定现在做） +通过 watch 机制监听 DataNode 的状态，如果 DataNode 下线，其注册的 channel 重新分配到其他 node，并 seek 到上次的位置（重新分配不一定现在做） -如果监听到DataNode重新上线，向其注册channel，并seek到上次记录的位置 +如果监听到 DataNode 重新上线，向其注册 channel，并 seek 到上次记录的位置 -如果监听到有新的DataNode注册，记录其状态，后续向其注册channel或进行load balance（load balance不一定现在做） +如果监听到有新的 DataNode 注册，记录其状态，后续向其注册 channel 或进行 load balance（load balance 不一定现在做） -DataNode如果由于网络原因与etcd断开，应该重启服务发现，DataCoord会去重新注册channel，DataNode不能重复监听相同channel +DataNode 如果由于网络原因与 etcd 断开，应该重启服务发现，DataCoord 会去重新注册 channel，DataNode 不能重复监听相同 channel ### 需要记录的信息 -1. cluster信息（包括Datanode的节点及其上面的channel） -2. segment 分配信息（最后一次分配的过期时间，segment的上限等） -3. stats 和 segment flush channel最后位置 -4. DataNode向DataCoord发送channel的最后位置 +1. cluster 信息（包括 Datanode 的节点及其上面的 channel） +2. segment 分配信息（最后一次分配的过期时间，segment 的上限等） +3. stats 和 segment flush channel 最后位置 +4. DataNode 向 DataCoord 发送 channel 的最后位置 ### 重启恢复流程 1. 内存状态恢复： - 1. 基本组件启动（meta， etcd等） - 2. 恢复segment allocator和cluster状态 - 3. -2. 与DataNode节点交互： - 1. 启动stats/segment flush channel，并seek到上次记录的位置 - 2. 启动timetick channel + 1. 基本组件启动（meta， etcd 等） + 2. 恢复 segment allocator 和 cluster 状态 +2. 与 DataNode 节点交互： -3. 与Master交互： - 1. 启动时不需要和Master交互，Collection信息为空，需要用到时向Master请求并缓存 - 2. 启动new segment channel + 1. 启动 stats/segment flush channel，并 seek 到上次记录的位置 + 2. 启动 timetick channel + +3. 与 Master 交互： + + 1. 启动时不需要和 Master 交互，Collection 信息为空，需要用到时向 Master 请求并缓存 + 2. 启动 new segment channel 4. 启动服务发现 -目前channel注册是segment allocation驱动的，每次请求segment时，检查其channel有没有被注册，没有则将其注册到DataNode，并保存到本地。这里有个问题，如果channel注册成功，DataCoord挂掉了，那么在重启后，DataCoord并不知道已经注册成功，来一个新的请求，还是会去注册，而且可能注册到不同的DataNode上面。类似Transaction的情况，需要有一套机制保证原子性在多节点写入，目前不太好解决。可以用以下步骤临时解决： +目前 channel 注册是 segment allocation 驱动的，每次请求 segment 时，检查其 channel 有没有被注册，没有则将其注册到 DataNode，并保存到本地。这里有个问题，如果 channel 注册成功，DataCoord 挂掉了，那么在重启后，DataCoord 并不知道已经注册成功，来一个新的请求，还是会去注册，而且可能注册到不同的 DataNode 上面。类似 Transaction 的情况，需要有一套机制保证原子性在多节点写入，目前不太好解决。可以用以下步骤临时解决： -1. 在etcd上记录分配方法entry，状态是未完成 -2. 向DataNode注册 -3. 在etcd上将entry标记为完成 +1. 在 etcd 上记录分配方法 entry，状态是未完成 +2. 向 DataNode 注册 +3. 在 etcd 上将 entry 标记为完成 -重启时/分配时，如果发现有未完成的entry，重新向DataNode注册，需要DataNode保证幂等性。 - -这样保证了一个channel只向一个DataNode注册，如果DataNode挂掉或者与etcd断开，如果需要重新分配到其他DataNode，这些entry也跟着变。 - - - -DataCoord模块中，有些策略是可能频繁改变的，比如channel对DataNode的分配策略，可以是随机/顺序/平均/根据collection分散等等策略，比如检测到DataNode创建和下线，可能会不处理/balance/将下线节点的channel转移到其他节点等。比如segment allocation可能会根据文件大小/条数等来确定是否关闭。实现应该把这些策略相关抽出来，方便以后修改。 +重启时/分配时，如果发现有未完成的 entry，重新向 DataNode 注册，需要 DataNode 保证幂等性。 +这样保证了一个 channel 只向一个 DataNode 注册，如果 DataNode 挂掉或者与 etcd 断开，如果需要重新分配到其他 DataNode，这些 entry 也跟着变。 +DataCoord 模块中，有些策略是可能频繁改变的，比如 channel 对 DataNode 的分配策略，可以是随机/顺序/平均/根据 collection 分散等等策略，比如检测到 DataNode 创建和下线，可能会不处理/balance/将下线节点的 channel 转移到其他节点等。比如 segment allocation 可能会根据文件大小/条数等来确定是否关闭。实现应该把这些策略相关抽出来，方便以后修改。 ### TODO: -1. segment allocation信息持久化及恢复 -2. cluster信息（datanode及channel信息）改动+持久化及恢复 -3. channel与datanode分配策略实现（可选load balance） -4. stats/segment flush channel记录位置及重启时seek +1. segment allocation 信息持久化及恢复 +2. cluster 信息（datanode 及 channel 信息）改动+持久化及恢复 +3. channel 与 datanode 分配策略实现（可选 load balance） +4. stats/segment flush channel 记录位置及重启时 seek 5. 服务注册与发现，以及对应事件的处理逻辑 -6. timetick channel的改动以及segment关闭逻辑改动 -7. datanode上报的binlog信息持久化及恢复 - +6. timetick channel 的改动以及 segment 关闭逻辑改动 +7. datanode 上报的 binlog 信息持久化及恢复