这是一次 HBase 集群异常导致无法启动的故障记录。原本只是想在业务空闲时重启 HBase 释放内存，并顺带调整部分 YARN 配置，结果在停机后集群再也没有正常拉起。整个问题排查和恢复过程耗费了很长时间，也暴露出运维操作不规范带来的风险。
环境版本
CDH 6.0.1
Hadoop 3.0
HBase 2.0.0
问题现象
HBase 重启后无法正常启动，报错核心信息为 hbase:namespace table is not online，同时 Master 一直停留在初始化状态，无法完成启动。
从日志现象来看，存在多个 Region 长时间处于 opening 状态，系统持续提示 STUCK Region-In-Transition。另外，访问 Master 状态页面时还能看到 Master is initializing 的异常信息。
更关键的报错指向了系统表 hbase:namespace 未正常上线，这会直接影响 Master 初始化流程，导致整个集群无法进入可用状态。
排查过程
遇到这类问题后，第一反应通常是借助 hbck 工具检查并修复元数据或 Region 状态。不过在 HBase 2.0.0 版本中，传统 hbck 的修复能力实际上已经被废弃，能够查看信息，但不能像旧版本那样直接执行常规修复。
随后继续查资料时，又找到了 hbck2 这个工具。按官方说明，它用于替代旧版 hbck 的部分修复能力，看上去像是一个可行方案。
但实际进一步确认后发现，HBase 2.0.0 到 2.0.2 以及部分 2.1.x 版本正处于一个比较尴尬的阶段：旧版 hbck 不能修，新版 hbck2 也不适用。也就是说，刚好踩在了工具支持的断层区间，常规修复手段基本失效。
问题总结
这次故障的棘手之处不在于报错本身，而在于以下几点同时出现：
HBase Master 无法完成初始化；
系统表
hbase:namespace未正常上线；多个 Region 长时间处于迁移或打开中的异常状态；
当前版本缺少可直接使用的官方修复工具。
在这种情况下，恢复工作的第一目标已经不是优化配置，而是先修复 Master，让集群能够正常启动。
解决方向
1. 先修复 Master，恢复集群启动能力
由于当时 Master 无法初始化，后续所有操作都必须围绕让 Master 恢复正常展开。只有 Master 能顺利启动，才有机会继续排查 Region、系统表以及元数据层面的问题。
这次经历说明，在生产环境中进行 HBase 重启、配置调整等操作时，必须充分评估版本特性与修复工具兼容性，尤其是涉及系统表和集群元数据时，更要提前制定回退方案。否则一个看似普通的重启动作，也可能演变成持续数天的集群恢复事故。
