恢复(recovery)和再平衡(rebalance)

该章节的配置项均在 controller 的 config 文件中进行配置（默认为 controller.cfg）。

通过 redo log 进行节点恢复

在 redo log 章节，介绍了重做日志相关的配置项。重做日志机制的目的就是为了防止节点宕机后数据丢失。启用重做日志机制，必须启用参考 cache engine，同时配置对应的日志存储路径。

在集群环境下，若某个节点发起的事务未完成时，发生了节点宕机。此时，用户可选择手动重启节点，或者经过 datanodeRestartInterval 的时间，集群会自动重启该节点。

配置参数	解释
datanodeRestartInterval=0	为一个正整数，值为 int 类型，单位为秒。配置该参数可以实现以下功能： (1)控制节点启动后自动启动数据节点（需要启动 agent）；(2) 数据节点掉线（非安全关机）的时间超过设置时长后自动重启该节点（需要启动 agent）。默认值为 0，表示不会自动重启或拉起数据节点。

节点间数据恢复

处于宕机、离线和同步恢复中的节点，不参与事务的处理。在此期间，若其它节点发起的事务涉及到该节点上的 CHUNK，根据集群是否为多副本，可分为以下两种情况：

• 集群为单副本，事务无法进行；

• 集群为多副本，系统将发起节点间恢复。（副本配置相关的配置项可参考 多副本 的说明。）

2.00.4 新版功能: OLAP 引擎支持在线增量恢复

2.00.5 新版功能: TSDB 引擎支持在线增量恢复

节点间恢复分为在线增量恢复和全量同步恢复。系统会优先尝试在线增量恢复，即通过其它节点的副本数据，增量补齐该节点由于无法参与事务而缺失的数据量。若存在数据不一致等问题，造成增量的在线恢复无法进行，系统将自动转换全量同步恢复。

节点间的全量恢复将以 CHUNK 副本为单位，将完整的副本复制到宕机节点中，因此网络开销较大。

节点间的在线增量恢复，只需复制缺失的事务数据，数据量较小。其通常分为两个阶段，异步恢复和同步恢复。当数据量较大时，同步恢复会导致源节点长时间阻塞，无法参与任何事务。因此在线恢复的第一阶段采用异步恢复，源节点在此期间仍可参与其它事务。等待恢复的数据量小于 dfsSyncRecoveryChunkRowSize 配置的值时，开始第二阶段的同步恢复，在较短的时间便可以完成。

配置参数	解释
dfsSyncRecoveryChunkRowSize=1000	一个正整数，默认值为1000。节点间进行数据恢复时，默认采用异步恢复，当待恢复的目的 chunk 的记录数与最新版本的记录数的差值小于该设置值，就会启用同步复制。

为了进一步提升节点间数据恢复任务的速度，可以通过调整配置项 dfsRecoveryConcurrency 来增加任务的并发度。

配置参数	解释
dfsRecoveryConcurrency	节点恢复时，执行 recovery 任务的并发度（worker 的数量），默认是集群数据节点个数的2倍。

同步恢复阶段，执行恢复任务的工作线程数可由参数 recoveryWorkers 配置。

配置参数	解释
recoveryWorkers=1	节点恢复时，可以用于同步恢复 chunk 的工作线程数。默认值是1。

节点数据再均衡

数据再均衡（rebalance）分为节点内数据均衡和节点间数据均衡。

节点内数据均衡主要指某个节点配置了多个磁盘卷，增加新的磁盘卷后，需要把数据重新分配，以提高 I/O 效率。对应函数 rebalanceChunksWithinDataNode。

节点间数据均衡指由于集群数据在各个节点上分配不均，可通过再均衡重新分配，提高分布式计算的效率。对应函数 rebalanceChunksAmongDataNodes。

在均衡的工作并发度可通过配置项 dfsRebalanceConcurrency 指定。

配置参数	解释
dfsRebalanceConcurrency	节点数据再均衡时，执行 rebalance 任务的并发度（worker 的数量），默认是集群数据节点个数的2倍。