基于本文回答

播面

0
评论

当某个 BE 节点发生突发宕机且无法短时间内恢复时，其上运行的数据副本是如何在集群内部进行自动修复和重构（Replica Repair）的？

在以 Apache Doris 或 StarRocks 为代表的 MPP 数据库架构中，当某个 BE（Backend）节点突发宕机且无法在短时间内恢复时，集群会启动一套自动化的副本修复与重构机制（Replica Repair）。

这个过程主要由 FE（Frontend）的 Tablet Scheduler（分片调度器） 主导，协同存活的 BE 节点共同完成。以下是该机制的详细工作原理和步骤：

第一阶段：故障检测与状态判定（Detection）

  1. 心跳检测失效：

    • FE 节点（主要是 Leader 节点）会定期向所有 BE 节点发送心跳。
    • 如果某个 BE 节点由于硬件故障、断电或 Core Dump 导致心跳中断，FE 会迅速感知并将其标记为 Alive = false（不可用）。

  2. 触发容忍度倒计时（非常关键）：

    • 为了防止因网络抖动、临时重启等原因引起不必要的大规模数据迁移（会消耗极大的网络和磁盘 I/O），FE 不会立即启动副本重构。
    • FE 会等待一个安全时间窗口，由参数 max_backend_down_time_second 控制（默认通常为 30 分钟 / 1800 秒）。
    • 如果在该时间内 BE 未能恢复，FE 才会正式判定该 BE 上的数据副本需要永久性重构。

第二阶段：受损分片（Tablet）识别与优先级排序（Scheduling）

  1. 识别受损 Tablet：

    • FE 存储了全局的元数据，知道每个 Tablet（数据分片）的副本分布在哪些 BE 上。
    • 一旦确认某个 BE 死亡，FE 会扫描元数据，找出所有“物理副本数小于期望副本数”（例如：设置了 3 副本，现在只剩 2 副本）的 Tablet。

  2. 优先级队列划分：

    • FE 的 Tablet Scheduler 会将这些需要修复的 Tablet 放入一个优先级队列中。优先级规则如下：
      • 红色预警（极高优先级）： 副本数降为 1 的 Tablet（即 3 副本只剩 1 副本）。此时如果再坏一个节点，数据就会彻底丢失。
      • 黄色预警（高优先级）： 副本数降为 2 的 Tablet（3 副本剩 2 副本）。
      • Colocate Table 修复： 绑定了 Colocate 属性的表，需要优先修复以保证本地化关联查询（Colocate Join）的性能。

第三阶段：副本重构方案制定（Planning）

对于队列中的每一个需要修复的 Tablet，FE 会制定一个克隆计划（Clone Plan）：

  1. 选择源节点（Src BE）：

    • FE 会在现存的、含有该 Tablet 健康副本的 BE 中，选择一个作为数据源。

  2. 选择目标节点（Dest BE）：

    • FE 会在其他健康的、且目前不持有该 Tablet 副本的 BE 节点中选择一个作为迁入目标。
    • 选择算法会考虑以下因素：
      • 负载均衡： 优先选择磁盘使用率较低、当前写入负载较低的 BE。
      • 高可用分布（Tag）： 遵循多机架、多可用区（Tag）部署策略，避免将新副本放在与已有副本相同的机架上。

第四阶段：数据异步复制（Execution）

  1. 下发克隆任务（Clone Task）：

    • FE 向选定的目标 BE（Dest BE）下发一个 CLONE 任务。任务中包含：Tablet ID、Schema 版本、数据源 BE（Src BE）的 IP 和端口等信息。

  2. BE 间点对点拉取（Peer-to-Peer Copy）：

    • 目标 BE 收到任务后，主动向数据源 BE 发起连接。
    • 增量或全量克隆：
      • 增量克隆（优先）： 如果目标 BE 上残留有该 Tablet 的旧数据（比如是之前掉线又起来的节点），且与源 BE 的版本差异很小，BE 会只传输差异的 Rowset（数据段），速度极快。
      • 全量克隆（本场景）： 既然是新节点或彻底重构，目标 BE 会通过 HTTP 协议，将源 BE 上的整个 Tablet 目录的数据文件（Segment 文件）完整下载到本地。

  3. 本地加载与校验：

    • 下载完成后，目标 BE 会在本地加载该 Tablet，校验数据的完整性（Checksum Check），确保数据未损坏。

第五阶段：元数据更新与完成（Commit）

  1. 汇报状态：

    • 目标 BE 完成加载后，向 FE 汇报：CLONE 任务执行成功。

  2. 更新元数据：

    • FE 收到汇报后，更新内存及 BDBJE（Metadata Journal）中的元数据：
      • 将目标 BE 上的新副本状态标记为 Visible（可用）。
      • 将已宕机 BE 上的旧副本彻底标记为 Trash（废弃）。
    • 此时，该 Tablet 的副本数重新回到了设定的安全值（如 3 副本），修复完成。

核心保障机制（防止集群雪崩）

在整个自愈过程中，Doris/StarRocks 设计了多重保护机制，防止因数据迁移压垮存活节点：

  1. 并发限速控制（Rate Limiting）：
    • tablet_sched_max_balancing_tablets：限制系统中同时进行重构的 Tablet 数量。
    • BE 节点之间的数据传输也会限制带宽，防止抢占线上业务的查询和导入流量。
  2. 只读/写入双重保障：
    • 在副本修复期间，只要存活副本数大于等于集群要求的最低写入副本数（Quorum），数据的读写操作完全不会中断。
    • 对于查询，FE 会自动避开那个挂掉的 BE，将查询规划发送给存活的 BE。

总结

当 BE 宕机，Doris/StarRocks 会经历：等待观察（30min） -> 扫描受损 Tablet -> 优先级排队 -> 规划迁移路径 -> BE 点对点拉取数据 -> FE 更新元数据。整个过程无需人工干预，全自动完成，确保了系统的高可用性和数据完整性。

右滑查看面试常问