Doris 一个 tablet 有多个副本，可能因为某些情况导致状态不一致。Doris 会尝试自动修复这些状态不一致的副本，让集群尽快从错误状态中恢复。每个副本的状态有以下几种
- 1.BAD : 即副本损坏。包括但不限于磁盘故障、BUG等引起的副本不可恢复的损毁状态
- 2.VERSION_MISSING : 版本缺失。Doris 中每一批次导入都对应一个数据版本。而一个副本的数据由多个连续的版本组成。而由于导入错误、延迟等原因，可能导致某些副本的数据版本不完整
- 3.HEALTHY : 健康副本。即数据正常的副本，并且副本所在的 BE 节点状态正常
Tablet 的状态是有所有副本状态来决定的，状态如下：
- 1.REPLICA_MISSING：副本缺失（即存活副本数小于期望副本数）
- 2.VERSION_INCOMPLETE：存活副本数大于等于期望副本数，但其中健康副本数小于期望副本数。
- 3.REPLICA_RELOCATING ：拥有等于 replication num 的版本完整的存活副本数，但是部分副本所在的 BE 节点处于 unavailable 状态
- 4.REPLICA_MISSING_IN_CLUSTER ： 当使用多 cluster 方式时，健康副本数大于等于期望副本数，但在对应 cluster 内的副本数小于期望副本数
- 5.REDUNDANT：副本冗余
- 6.COLOCATE_MISMATCH：针对 Colocation 属性的表的分片状态。表示分片副本与 Colocation Group 的指定的分布不一致
- 7.COLOCATE_REDUNDANT：针对 Colocation 属性的表的分片状态。表示 Colocation 表的分片副本冗余。
- 8.FORCE_REDUNDANT：这是一个特殊状态。只会出现在当期望副本数大于等于可用节点数时，并且 Tablet 处于副本缺失状态时出现。这种情况下，需要先删除一个副本，以保证有可用节点用于创建新副本
- 9.HEALTHY：健康分片，即条件[1-8]都不满足。
下面这张图是 Doris 副本检查及副本恢复的整体流程图
名词解释：
- 1.TabletChecker（TC）：TabletChecker 作为常驻的后台进程，会定期检查所有分片的状态。对于非健康状态的分片，将会交给 TabletScheduler 进行调度和修复。修复的实际操作，都由 BE 上的 clone 任务完成。FE 只负责生成这些 clone 任务。
- 2.TabletScheduler 每5秒进行一次调度
- 3.TabletScheduler 每次调度最多 50 个 tablet
- 4.最大等待调度任务数和运行中任务数为 2000。当超过 2000 后，TabletChecker 将不再产生新的调度任务给 TabletScheduler。
- 5.最大均衡任务数为 500。当超过 500 后，将不再产生新的均衡任务
- 6.每块磁盘用于均衡任务的 slot 数目为2。这个 slot 独立于用于副本修复的 slot
- 7.一个 clone 任务超时时间范围是 3min ~ 2hour。具体超时时间通过 tablet 的大小计算。计算公式为 (tablet size) / (5MB/s)。当一个 clone 任务运行失败 3 次后，该任务将终止。
- 8.TabletScheduler（TS）：是一个常驻的后台线程，用于处理由 TabletChecker 发来的需要修复的 Tablet。同时也会进行集群副本均衡的工作。
副本恢复流程
首先是 FE 的 tablet 检查进程，会定期的对所有分片进行检查，然后会不健康的分片，交给Tablet调度进程去完成调度和修复，下面我们主要介绍一下 FE 这边怎么生成调度及BE怎么完成Clone 和修复。
首先我们要找到一个目标BE，可以用来Clone 一个新的副本
- 1.找到一个可用的 BE 及副本存放路径，作为我们副本Clone的目标节点
- 2.首先这个 BE 是要 Alive 的
- 3.应该将现有副本的 BE 节点排除在外，因为同一个 BE 只能有一个副本。
- 4.选择一个 proper tag BE
- 在副本丢失的情况下，我们要选择一个有副本丢失的 tag
- 根据副本分步情况，如果没有 副本丢失 tag 的，这种应该抛出异常
- 为了删除多余的副本，这时候需要找出一个多余副本的标签
- 1.这个目标 BE 要有可以使用执行 Clone 任务的 Solt
- 2.找到一个可以用来 Clone 副本的合适的路径，这里要考虑磁盘容量和使用百分比
- 3.目标是要找到一个负载（ClusterLoadStatistics（CLS））相对低的路径，这里TabletScheduler 会每隔 20s 更新一次 CLS
- 4.找到一个适合的副本源
- 5.这个副本应该是健康的
- 6.源副本所在的BE有可用的Clone solt
- 7.向目标 BE 发送克隆任务
- 8.目标 BE 提交 Clone task 任务
- 9.判断 tablet 副本都否存在，如果不存在开始 Clone 一个新的 tablet
- 10.向源 BE 发送一个创建Snapshot的请求，这里源 BE 之所以要创建Snapshot，是因为方式在 clone 修复的时候，这个时候有数据写导致Clone 失败，通过创建快照来避免这个问题。
- 11.源 BE 检查 tablet 状态及版本等是否正常
- 12.如果源 BE 的tablet 副本状态、版本等都是正常的，执行创建Snapshot，并返回
- 13.目标 BE 从源 BE 下载刚才创建的Snapshot到本地，完成副本恢复
实例
用户的操作步骤：
1. 修改已有表字段长度， varchar(60) --> varchar(90) 2. tablet出现损坏 3. 自动修复失败。
下面我们来看一个实例，怎么去定位 Tablet 副本均衡失败的原因
- 1.首先我们要通过
show tablet tablet_id查看这个 tablet 副本的情况 - 2.在执行上面命令返回的数据最后一列的命令
类似下面的命令
SHOW PROC'/dbs/10005/17679/partitions/774669/6061262/6061295';
然后我们可以看到最下面的一行，显示这个副本正Clone，但是过了一会并没有Clone 成功，这个时候我们可能感觉无从下手，不知道为什么了，我们这个时候要去关注 cluster_balance, 通过这个查看副本均衡调度任务执行的情况
- 1.查看副本调度的任务情况，执行下面的命令
SHOW PROC '/cluster_balance/pending_tablets'; 或者 SHOW PROC '/cluster_balance/running_tablets';
在返回的结果里我们可以看到：SrcBe 和 DestBe
这个时候我们就要去目标BE上去查看日志，在日志里搜索这个 Tablet Id，然后我在日志里看到下面的信息
[图片上传失败...(image-d42cdf-1662968106713)]
显示这个目标 BE 在去源 BE 请求创建 tablet 副本快照的时候失败了，这个时候我怀疑可能是其他的副本也是有问题的，正常情况下这个地方不应该失败，我通过
SHOW PROC'/dbs/10005/17679/partitions/774669/6061262/6061299';
注意：
这里因为当时是在查看三个 tablet的问题，所有这个tablet id 前后对不上，都是一样的问题
我去看刚才 Clone 失败的副本均衡任务的源 BE 上副本对应的的哪行数据最后一列：CompactionStatus ，然后将这个URL在浏览器里访问，看一下是不是刚才猜测的这个副本也存在问题。
然后看到了下面的信息，版本丢失了
因为有三副本，之前只损坏一个副本，是不是另外一个副本也是这种情况呢，我又去看了另外一个be上的副本状态，最后发现也是同样的问题
最后去看了一下，源 BE 上的日志，搜索了 3341 这个版本号，来确认是否真版本丢失了
通过上面的日志，确认了这个tablet 三个副本都是损坏的，而且没办法修复
这种情况下，我们就要通过 BE 日志来分析具体的原因，是因为操作不当还是程序存在 Bug，如果是操作不当，可以先从操作上规避，然后将这个问题提交给社区，有社区开发人员定位分析，然后修复
针对这个里面没办法修复的，只能先删除这个分区，重新将这个分区的数据导入进来
正常情况下Doris不会出现某个tablet 副本全部损坏不可修复的问题，
现在Doris 社区发版速度很快，而且在1.1.x版本上维护了一个准LTS版本，所以建议大家及时升级到最新版本，正常按照社区的升级手册，不会出现数据丢失的情况
因为Doris 不支持高版本超低版回退，大家可能比较担心我一旦升级错误怎么办，下一篇文章我来给大家讲解怎么进行升级前的备份，在升级失败后，可以回退到之前的版本，正常运行。
