Apache Doris tablet 副本修复的原理、流程及问题定位

本文涉及的产品
日志服务 SLS,月写入数据量 50GB 1个月
简介: Apache Doris tablet 副本修复的原理、流程及问题定位

Doris 一个 tablet 有多个副本,可能因为某些情况导致状态不一致。Doris 会尝试自动修复这些状态不一致的副本,让集群尽快从错误状态中恢复。每个副本的状态有以下几种


  1. 1.BAD : 即副本损坏。包括但不限于磁盘故障、BUG等引起的副本不可恢复的损毁状态

  2. 2.VERSION_MISSING : 版本缺失。Doris 中每一批次导入都对应一个数据版本。而一个副本的数据由多个连续的版本组成。而由于导入错误、延迟等原因,可能导致某些副本的数据版本不完整

  3. 3.HEALTHY : 健康副本。即数据正常的副本,并且副本所在的 BE 节点状态正常

Tablet 的状态是有所有副本状态来决定的,状态如下:


  1. 1.REPLICA_MISSING:副本缺失(即存活副本数小于期望副本数)

  2. 2.VERSION_INCOMPLETE:存活副本数大于等于期望副本数,但其中健康副本数小于期望副本数。

  3. 3.REPLICA_RELOCATING :拥有等于 replication num 的版本完整的存活副本数,但是部分副本所在的 BE 节点处于 unavailable 状态

  4. 4.REPLICA_MISSING_IN_CLUSTER : 当使用多 cluster 方式时,健康副本数大于等于期望副本数,但在对应 cluster 内的副本数小于期望副本数

  5. 5.REDUNDANT:副本冗余

  6. 6.COLOCATE_MISMATCH:针对 Colocation 属性的表的分片状态。表示分片副本与 Colocation Group 的指定的分布不一致

  7. 7.COLOCATE_REDUNDANT:针对 Colocation 属性的表的分片状态。表示 Colocation 表的分片副本冗余。

  8. 8.FORCE_REDUNDANT:这是一个特殊状态。只会出现在当期望副本数大于等于可用节点数时,并且 Tablet 处于副本缺失状态时出现。这种情况下,需要先删除一个副本,以保证有可用节点用于创建新副本


  1. 9.HEALTHY:健康分片,即条件[1-8]都不满足。

下面这张图是 Doris 副本检查及副本恢复的整体流程图

微信图片_20231009170105.png

名词解释:


  1. 1.TabletChecker(TC):TabletChecker 作为常驻的后台进程,会定期检查所有分片的状态。对于非健康状态的分片,将会交给 TabletScheduler 进行调度和修复。修复的实际操作,都由 BE 上的 clone 任务完成。FE 只负责生成这些 clone 任务。

  2. 2.TabletScheduler 每5秒进行一次调度

  3. 3.TabletScheduler 每次调度最多 50 个 tablet

  4. 4.最大等待调度任务数和运行中任务数为 2000。当超过 2000 后,TabletChecker 将不再产生新的调度任务给 TabletScheduler。

  5. 5.最大均衡任务数为 500。当超过 500 后,将不再产生新的均衡任务

  6. 6.每块磁盘用于均衡任务的 slot 数目为2。这个 slot 独立于用于副本修复的 slot

  7. 7.一个 clone 任务超时时间范围是 3min ~ 2hour。具体超时时间通过 tablet 的大小计算。计算公式为 (tablet size) / (5MB/s)。当一个 clone 任务运行失败 3 次后,该任务将终止。

  8. 8.TabletScheduler(TS):是一个常驻的后台线程,用于处理由 TabletChecker 发来的需要修复的 Tablet。同时也会进行集群副本均衡的工作。

副本恢复流程


首先是 FE 的 tablet 检查进程,会定期的对所有分片进行检查,然后会不健康的分片,交给Tablet调度进程去完成调度和修复,下面我们主要介绍一下 FE 这边怎么生成调度及BE怎么完成Clone 和修复。


首先我们要找到一个目标BE,可以用来Clone 一个新的副本


  1. 1.找到一个可用的 BE 及副本存放路径,作为我们副本Clone的目标节点

  2. 2.首先这个 BE 是要 Alive 的

  3. 3.应该将现有副本的 BE 节点排除在外,因为同一个 BE 只能有一个副本。

  4. 4.选择一个 proper tag BE

  • 在副本丢失的情况下,我们要选择一个有副本丢失的 tag

  • 根据副本分步情况,如果没有 副本丢失 tag 的,这种应该抛出异常

  • 为了删除多余的副本,这时候需要找出一个多余副本的标签

  1. 1.这个目标 BE 要有可以使用执行 Clone 任务的 Solt

  2. 2.找到一个可以用来 Clone 副本的合适的路径,这里要考虑磁盘容量和使用百分比

  3. 3.目标是要找到一个负载(ClusterLoadStatistics(CLS))相对低的路径,这里TabletScheduler 会每隔 20s 更新一次 CLS

  4. 4.找到一个适合的副本源

  5. 5.这个副本应该是健康的

  6. 6.源副本所在的BE有可用的Clone solt

  7. 7.向目标 BE 发送克隆任务

  8. 8.目标 BE 提交 Clone task 任务

  9. 9.判断 tablet 副本都否存在,如果不存在开始 Clone 一个新的 tablet

  10. 10.向源 BE 发送一个创建Snapshot的请求,这里源 BE 之所以要创建Snapshot,是因为方式在 clone 修复的时候,这个时候有数据写导致Clone 失败,通过创建快照来避免这个问题。

  11. 11.源 BE 检查 tablet 状态及版本等是否正常

  12. 12.如果源 BE 的tablet 副本状态、版本等都是正常的,执行创建Snapshot,并返回

  13. 13.目标 BE 从源 BE 下载刚才创建的Snapshot到本地,完成副本恢复

实例


用户的操作步骤:


1. 修改已有表字段长度, varchar(60) --> varchar(90) 2. tablet出现损坏 3. 自动修复失败。

下面我们来看一个实例,怎么去定位 Tablet 副本均衡失败的原因


  1. 1.首先我们要通过 show tablet tablet_id 查看这个 tablet 副本的情况

  2. 2.在执行上面命令返回的数据最后一列的命令

类似下面的命令


SHOW PROC'/dbs/10005/17679/partitions/774669/6061262/6061295';

微信图片_20231009170514.png

然后我们可以看到最下面的一行,显示这个副本正Clone,但是过了一会并没有Clone 成功,这个时候我们可能感觉无从下手,不知道为什么了,我们这个时候要去关注 cluster_balance, 通过这个查看副本均衡调度任务执行的情况


  1. 1.查看副本调度的任务情况,执行下面的命令

SHOW PROC '/cluster_balance/pending_tablets'; 或者 SHOW PROC '/cluster_balance/running_tablets';

在返回的结果里我们可以看到:SrcBeDestBe

1.png

这个时候我们就要去目标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在浏览器里访问,看一下是不是刚才猜测的这个副本也存在问题。

2.png

然后看到了下面的信息,版本丢失了


因为有三副本,之前只损坏一个副本,是不是另外一个副本也是这种情况呢,我又去看了另外一个be上的副本状态,最后发现也是同样的问题

3.png

最后去看了一下,源 BE 上的日志,搜索了 3341 这个版本号,来确认是否真版本丢失了

4.png

通过上面的日志,确认了这个tablet 三个副本都是损坏的,而且没办法修复


这种情况下,我们就要通过 BE 日志来分析具体的原因,是因为操作不当还是程序存在 Bug,如果是操作不当,可以先从操作上规避,然后将这个问题提交给社区,有社区开发人员定位分析,然后修复


针对这个里面没办法修复的,只能先删除这个分区,重新将这个分区的数据导入进来


正常情况下Doris不会出现某个tablet 副本全部损坏不可修复的问题,


现在Doris 社区发版速度很快,而且在1.1.x版本上维护了一个准LTS版本,所以建议大家及时升级到最新版本,正常按照社区的升级手册,不会出现数据丢失的情况


因为Doris 不支持高版本超低版回退,大家可能比较担心我一旦升级错误怎么办,下一篇文章我来给大家讲解怎么进行升级前的备份,在升级失败后,可以回退到之前的版本,正常运行。

相关实践学习
【涂鸦即艺术】基于云应用开发平台CAP部署AI实时生图绘板
【涂鸦即艺术】基于云应用开发平台CAP部署AI实时生图绘板
目录
相关文章
|
1月前
|
消息中间件 OLAP Kafka
Apache Doris 实时更新技术揭秘:为何在 OLAP 领域表现卓越?
Apache Doris 为何在 OLAP 领域表现卓越?凭借其主键模型、数据延迟、查询性能、并发处理、易用性等多方面特性的表现,在分析领域展现了独特的实时更新能力。
182 9
|
1月前
|
人工智能 运维 监控
智能运维与数据治理:基于 Apache Doris 的 Data Agent 解决方案
本文基于 Apache Doris 数据运维治理 Agent 展开讨论,如何让 AI 成为 Doris 数据运维工程师和数据治理专家的智能助手,并在某些场景下实现对人工操作的全面替代。这种变革不仅仅是技术层面的进步,更是数据运维治理思维方式的根本性转变:从“被动响应”到“主动预防”,从“人工判断”到“智能决策”,从“孤立处理”到“协同治理”。
223 11
智能运维与数据治理:基于 Apache Doris 的 Data Agent 解决方案
|
1月前
|
SQL 存储 运维
Apache Doris 在菜鸟的大规模湖仓业务场景落地实践
本文介绍了 Apache Doris 在菜鸟的大规模落地的实践经验,菜鸟为什么选择 Doris,以及 Doris 如何在菜鸟从 0 开始,一步步的验证、落地,到如今上万核的规模,服务于各个业务线,Doris 已然成为菜鸟 OLAP 数据分析的最优选型。
139 2
Apache Doris 在菜鸟的大规模湖仓业务场景落地实践
|
1月前
|
SQL 存储 JSON
Apache Doris 2.1.10 版本正式发布
亲爱的社区小伙伴们,Apache Doris 2.1.10 版本已正式发布。2.1.10 版本对湖仓一体、半结构化数据类型、查询优化器、执行引擎、存储管理进行了若干改进优化。欢迎大家下载使用。
119 5
|
1月前
|
人工智能 自然语言处理 数据挖掘
Apache Doris 4.0 AI 能力揭秘(一):AI 函数之 LLM 函数介绍
在即将发布的 Apache Doris 4.0 版本中,我们正式引入了一系列 LLM 函数,将前沿的 AI 能力与日常的数据分析相结合,无论是精准提取文本信息,还是对评论进行情感分类,亦或生成精炼的文本摘要,皆可在数据库内部无缝完成。
91 0
Apache Doris 4.0 AI 能力揭秘(一):AI 函数之 LLM 函数介绍
|
2月前
|
SQL 人工智能 数据挖掘
Apache Doris + MCP:Agent 时代的实时数据分析底座
数据不再是静态的存储对象,而是流动的智能资源;数据库不再是单纯的存储系统,而是智能化的服务平台。Apache Doris 以其在 AI 方向的深度布局和技术创新,正在成为连接数据与智能的重要桥梁。
756 0
Apache Doris + MCP:Agent 时代的实时数据分析底座
|
1月前
|
存储 人工智能 Apache
ApacheCon 2025中国开源年度报告:Apache Doris 国内第一
在 Apache 基金会管理的近 300 个顶级项目中,Doris 已经成为仅次于 Apache Airflow 的全球第二大影响力项目。
127 0
|
14天前
|
人工智能 运维 Java
Flink Agents:基于Apache Flink的事件驱动AI智能体框架
本文基于Apache Flink PMC成员宋辛童在Community Over Code Asia 2025的演讲,深入解析Flink Agents项目的技术背景、架构设计与应用场景。该项目聚焦事件驱动型AI智能体,结合Flink的实时处理能力,推动AI在工业场景中的工程化落地,涵盖智能运维、直播分析等典型应用,展现其在AI发展第四层次——智能体AI中的重要意义。
163 8
Flink Agents:基于Apache Flink的事件驱动AI智能体框架
|
9月前
|
存储 人工智能 大数据
The Past, Present and Future of Apache Flink
本文整理自阿里云开源大数据负责人王峰(莫问)在 Flink Forward Asia 2024 上海站主论坛开场的分享,今年正值 Flink 开源项目诞生的第 10 周年,借此时机,王峰回顾了 Flink 在过去 10 年的发展历程以及 Flink社区当前最新的技术成果,最后展望下一个十年 Flink 路向何方。
672 33
The Past, Present and Future of Apache Flink

热门文章

最新文章

推荐镜像

更多