基于本文回答

播面

0
评论

当某台 HRegionServer 宕机后，其上运行的 Region 是如何迁移和恢复的？

在 HBase 中，当一台 HRegionServer (简称 RS) 宕机后，其上运行的 Region 必须被迁移到其他健康的 RS 上，并且要保证在此过程中数据不丢失（尤其是还停留在内存 MemStore 中未刷写到磁盘的数据）。

这个迁移和恢复的过程是由 ZooKeeper、HMaster 和其他健康的 HRegionServer 共同协作完成的。整个过程主要分为以下四个关键步骤：

第一步：宕机检测 (Failure Detection)

  1. ZooKeeper 临时节点机制：每个 RS 启动时，都会在 ZooKeeper 的 /hbase/rs 目录下创建一个临时节点（Ephemeral Node），并保持心跳（Session）。
  2. 连接断开：当某台 RS 宕机或网络中断导致 Session 超时，ZooKeeper 会自动删除该 RS 对应的临时节点。
  3. HMaster 发现宕机：HMaster 一直在监听（Watch）ZK 的 /hbase/rs 目录。一旦发现有节点被删除，HMaster 就会立即感知到该 RS 已宕机，并将其加入到“死节点列表（Dead Servers）”中，随后启动故障恢复流程（ServerCrashProcedure）。

第二步：WAL 日志切分 (Log Splitting)

这一步是保证数据不丢失的核心。宕机 RS 的内存（MemStore）数据已经随之消失，必须通过存储在 HDFS 上的 Write-Ahead Log (WAL) 来恢复。

  1. 为什么需要切分？
    HBase 中一台 RS 上的所有 Region 共享同一个 WAL 文件。如果不切分直接恢复，目标 RS 为了恢复一个 Region 的数据，不得不读取整个包含了大量无关 Region 数据的 WAL 文件，效率极低。
  2. 重命名 WAL 目录：HMaster 首先会将宕机 RS 的 WAL 目录重命名（例如加上 -splitting 后缀），这是为了防止“脑裂”（Split-Brain），确保如果那台 RS 是假死，它也无法再向原来的日志文件写入数据。
  3. 分布式日志切分 (Distributed Log Splitting, DLS)：
    • HMaster 会将读取和切分 WAL 的任务发布到 ZooKeeper。
    • 集群中其他健康的 RS 会去 ZK 认领这些任务。
    • 健康的 RS 读取宕机 RS 的 WAL 文件，按 Region 将日志条目过滤出来。
    • 将过滤后的日志数据写入到 HDFS 中对应 Region 目录下的 recovered.edits 文件夹中。这样，每个 Region 都拥有了属于自己需要恢复的日志。

第三步：Region 重新分配 (Region Reassignment)

在处理数据的同时，HMaster 需要决定这些无家可归的 Region 接下来由谁来负责。

  1. 标记下线：HMaster 根据内存中的路由状态或读取 hbase:meta 表，找出宕机 RS 上原本服务的所有 Region，并将它们的状态标记为 OFFLINE。
  2. 负载均衡分配：HMaster 内部的 Assignment Manager（分配管理器）会调用 Load Balancer（负载均衡器），将这些 Region 均匀地分配给当前集群中处于健康状态的 RS。
  3. 发送分配指令：HMaster 向被选中的目标 RS 发送 RPC 请求，命令它们上线（Open）指定的 Region。

(注：在 HBase 2.x 中，这个过程由基于状态机的 Procedure V2 框架严格保证，即使在恢复过程中 HMaster 宕机，重启后也能从原来的状态继续执行，不会导致状态混乱。)

第四步：Region 恢复与上线 (Region Open & Recovery)

目标 RS 收到 HMaster 的分配指令后，开始执行 Region 的上线和数据恢复。

  1. 修改 Meta 表：目标 RS 准备接管 Region，会更新 hbase:meta 表，将该 Region 的 Server 地址修改为自己的地址。（这样客户端之后就能查到新的地址）。
  2. 加载 HFile：RS 从 HDFS 读取该 Region 已有的底层数据文件（HFile）结构。
  3. 日志回放 (Replay WAL)：（关键）
    • RS 会检查该 Region 在 HDFS 的目录下是否存在 recovered.edits 文件夹（即第二步切分出来的日志）。
    • 如果存在，RS 会读取这些编辑日志，将其逐条回放（Replay）到内存的 MemStore 中。
    • 回放完成后，为了安全起见，RS 会立即强制执行一次 Flush 操作，将这部分内存数据刷写为 HDFS 上的 HFile。
    • 刷写成功后，删除 recovered.edits 目录。
  4. 对外提供服务：完成上述所有步骤后，该 Region 的状态变为 OPEN，正式对外提供读写服务。

总结

整个恢复过程可以简单概括为：
ZK 报警 -> HMaster 统筹 -> 健康 RS 帮忙切分旧日志 -> HMaster 重新分配 Region -> 新 RS 认领 Region 并回放日志 -> Region 重新上线。

由于底层的 HFile 和 WAL 都是存储在具有高可用和多副本机制的 HDFS 上的，因此 Region 的迁移实际上不需要搬运底层的数据文件，只需要进行元数据的修改、日志的切分回放以及内存状态的重建，这保证了 HBase 在节点宕机时依然具备极高的数据安全性和较快的恢复速度。

右滑查看面试常问