HBase 集群启动问题排查总结（含流程图、方法表、心得体会）
一、今日问题汇总（现象 + 根因 + 解决方案）
按问题出现顺序梳理，覆盖从 HBase 启动到集群稳定运行的全流程问题：
1. 问题 1：执行start-hbase.sh报错 “bash: start-hbase.sh: 未找到命令”
现象
在任意目录执行start-hbase.sh，终端提示 “未找到命令”，但 HBase 已安装在/opt/module/hbase-2.4.18。
根因
系统PATH环境变量未包含 HBase 的bin目录（/opt/module/hbase-2.4.18/bin），终端无法找到命令路径。
解决方案
-
临时方案：用绝对路径或切换到
bin目录执行# 绝对路径执行 /opt/module/hbase-2.4.18/bin/start-hbase.sh # 或切换到bin目录执行 cd /opt/module/hbase-2.4.18/bin && ./start-hbase.sh -
永久方案：将 HBase
bin目录添加到PATH（推荐）# 编辑用户环境变量文件 vim ~/.bashrc # 添加以下内容（末尾） export HBASE_HOME=/opt/module/hbase-2.4.18 export PATH=$PATH:$HBASE_HOME/bin # 使配置生效 source ~/.bashrc
2. 问题 2：执行start-hbase.sh报错 “权限不够”
现象
执行/opt/module/hbase-2.4.18/bin/start-hbase.sh，提示 “/opt/module/hbase-2.4.18/bin/start-hbase.sh: 权限不够”。
根因
- HBase 目录所有者为
root（安装时用root解压 / 移动），当前用户atguigu无执行权限； start-hbase.sh文件缺少 “执行位（x）”，即使所有者正确也无法运行。
解决方案
# 1. 切换到root用户，修改HBase目录所有者为atguigu（所有节点执行）
su - root
chown -R atguigu:atguigu /opt/module/hbase-2.4.18
exit # 切回atguigu
# 2. 给bin目录下所有脚本添加执行权限（所有节点执行）
chmod u+x /opt/module/hbase-2.4.18/bin/*
3. 问题 3：用sudo start-hbase.sh报错 “sudo: start-hbase.sh：找不到命令”
现象
尝试用sudo解决权限问题，却提示 “sudo: start-hbase.sh：找不到命令”。
根因
sudo会重置PATH环境变量为系统默认路径（不包含atguigu用户配置的 HBasebin目录），因此无法找到命令。
解决方案
-
避免直接用
sudo执行应用命令，优先通过chown+chmod赋予普通用户权限； -
若必须用
sudo，需指定绝对路径：sudo /opt/module/hbase-2.4.18/bin/start-hbase.sh
4. 问题 4从节点（192.168.10.103/104）报错 “hbase-daemon.sh: 权限不够”
现象
主节点执行start-hbase.sh时，从节点提示 “bash: /opt/module/hbase-2.4.18/bin/hbase-daemon.sh: 权限不够”。
根因
从节点 HBase 目录的所有者或执行权限未同步（仅主节点修复了权限，从节点仍为root或无x位）。
解决方案
-
远程同步权限（主节点执行，无需登录从节点）：
# 修复hadoop103权限 ssh atguigu@hadoop103 "sudo chown -R atguigu:atguigu /opt/module/hbase-2.4.18 && chmod u+x /opt/module/hbase-2.4.18/bin/*" # 修复hadoop104权限 ssh atguigu@hadoop104 "sudo chown -R atguigu:atguigu /opt/module/hbase-2.4.18 && chmod u+x /opt/module/hbase-2.4.18/bin/*" -
手动修复（若远程 sudo 失败，登录从节点执行）：
su - root chown -R atguigu:atguigu /opt/module/hbase-2.4.18 su - atguigu chmod u+x /opt/module/hbase-2.4.18/bin/*
5. 问题 5：HMaster 启动后异常退出（jps无 HMaster 进程）
现象
start-hbase.sh日志显示 “running master”，但jps无HMaster；查看日志（hbase-atguigu-master-hadoop102.out）提示 “ABORTING master”。
根因
HBase 依赖 HDFS 存储数据，HMaster启动时需连接 HDFS 的 NameNode，但 HDFS 未启动 / 异常 / 端口不匹配，导致HMaster启动失败。
解决方案
-
检查 HDFS 状态（主节点
hadoop102执行）：# 查看HDFS健康状态（需Hadoop的sbin目录在PATH） hdfs dfsadmin -report # 若提示“未找到命令”，用绝对路径 /opt/module/hadoop-3.1.3/bin/hdfs dfsadmin -report -
重启 HDFS（若 HDFS 异常）：
# 停止HDFS /opt/module/hadoop-3.1.3/sbin/stop-dfs.sh # 启动HDFS /opt/module/hadoop-3.1.3/sbin/start-dfs.sh -
验证 HDFS 端口监听（确认 NameNode 在指定端口运行）：
netstat -tuln | grep 8020 # 8020为core-site.xml配置的HDFS端口
6. 问题 6：执行stop-dfs.sh/start-dfs.sh报错 “未找到命令”
现象
管理 HDFS 时执行start-dfs.sh，提示 “未找到命令”。
根因
PATH未包含 Hadoop 的sbin目录（/opt/module/hadoop-3.1.3/sbin），终端无法找到 HDFS 管理脚本。
解决方案
-
永久方案：更新
~/.bashrc，添加 Hadoopsbin目录：vim ~/.bashrc # 添加以下内容（补充到已有Hadoop配置后） export HADOOP_HOME=/opt/module/hadoop-3.1.3 export PATH=$PATH:$HADOOP_HOME/bin:$HADOOP_HOME/sbin # 生效配置 source ~/.bashrc -
临时方案：用绝对路径执行：
/opt/module/hadoop-3.1.3/sbin/start-dfs.sh
7. 问题 7：HRegionServer 进程关不掉（stop-hbase.sh无效）
现象
执行stop-hbase.sh后，从节点jps仍显示HRegionServer进程（如 PID 5460）。
根因
进程处于 “僵尸状态” 或脚本未触达从节点，导致无法正常停止。
解决方案
-
用 HBase 脚本单独停止（从节点执行）：
/opt/module/hbase-2.4.18/bin/hbase-daemon.sh stop regionserver -
强制杀死残留进程（若脚本无效）：
# 查看进程PID jps | grep HRegionServer # 强制杀死（替换5460为实际PID） kill -9 5460 -
清理残留 PID 文件（避免下次启动冲突）：
rm -rf /tmp/hbase-* # 所有节点执行
8. 问题 8：HMaster 因 HDFS 端口配置不一致启动失败
现象
HMaster日志显示 “Call From hadoop102 to hadoop102:9000 failed 拒绝连接”，但 HDFS 实际端口为 8020。
根因
- Hadoop 的
core-site.xml配置 HDFS 端口为 8020（fs.defaultFS=hdfs://192.168.10.102:8020）； - HBase 的
hbase-site.xml配置 HDFS 端口为 9000（hbase.rootdir=hdfs://hadoop102:9000/hbase）； - 配置不一致导致
HMaster连接 HDFS 失败。
解决方案
-
统一配置（修改 HBase 的
hbase-site.xml）：vim /opt/module/hbase-2.4.18/conf/hbase-site.xml # 修改hbase.rootdir为HDFS实际地址 <property> <name>hbase.rootdir</name> <value>hdfs://192.168.10.102:8020/hbase</value> </property> -
同步配置到所有从节点（主节点执行）：
scp /opt/module/hbase-2.4.18/conf/hbase-site.xml atguigu@hadoop103:/opt/module/hbase-2.4.18/conf/ scp /opt/module/hbase-2.4.18/conf/hbase-site.xml atguigu@hadoop104:/opt/module/hbase-2.4.18/conf/ -
重启 HBase：
stop-hbase.sh && start-hbase.sh
二、问题排查流程图（Mermaid）
flowchart TD
A[执行start-hbase.sh启动HBase] --> B{命令是否找到？}
B -- 否 --> C[检查是否在HBase bin目录/用绝对路径？]
C -- 是 --> D[执行脚本]
C -- 否 --> E[编辑~/.bashrc，添加HBase bin到PATH]
E --> F[source ~/.bashrc生效]
F --> D
B -- 是 --> D
D --> G{是否提示“权限不够”？}
G -- 是 --> H[ls -l 查看文件所有者和执行权限]
H --> I{所有者是否为atguigu？}
I -- 否 --> J[sudo chown -R atguigu:atguigu /opt/module/hbase-2.4.18]
I -- 是 --> K[检查是否有执行位（x）？]
K -- 否 --> L[chmod u+x /opt/module/hbase-2.4.18/bin/*]
J --> L
L --> D
G -- 否 --> M{主节点jps是否有HMaster？}
M -- 否 --> N[查看HBase Master日志（hbase-atguigu-master-hadoop102.log）]
N --> O{日志是否显示“HDFS连接拒绝”？}
O -- 是 --> P[检查HDFS状态（hdfs dfsadmin -report）]
P --> Q{HDFS是否正常？}
Q -- 否 --> R[重启HDFS（stop-dfs.sh → start-dfs.sh）]
Q -- 是 --> S[检查Hadoop core-site.xml和HBase hbase-site.xml的端口是否一致]
S -- 不一致 --> T[统一端口（如8020），同步hbase-site.xml到所有节点]
T --> R
R --> D
S -- 一致 --> D
O -- 否 --> U[检查是否为ZooKeeper问题（日志是否有KeeperException）]
U --> V[重启HBase内置ZooKeeper（stop-hbase.sh → rm -rf /tmp/hbase-* → start-hbase.sh）]
V --> D
M -- 是 --> W{从节点jps是否有HRegionServer？}
W -- 否 --> X[检查从节点权限（远程执行chown和chmod）]
X --> D
W -- 是 --> Y[HBase集群启动成功，可通过Web UI（192.168.10.102:16010）或hbase shell使用]
三、个人问题排查心得体会
1. 分布式系统 “配置一致性” 是生命线
本次最核心的问题是 HDFS 与 HBase 的端口配置不一致（8020 vs 9000），导致HMaster启动失败。分布式组件（HDFS、YARN、HBase）通过配置文件约定通信规则，任何一处配置不同步都会导致整个链路断裂。→ 教训：修改配置后，必须用scp同步到所有节点；安装软件时，统一用同一用户（如atguigu）操作，避免权限混乱。
2. 日志是排查问题的 “金钥匙”，切勿忽略异常细节
初期HMaster启动后消失，一度误以为是权限问题，直到查看hbase-atguigu-master-hadoop102.log，才发现 “连接 hadoop102:9000 拒绝” 的关键信息。日志中的IP、端口、Exception 类型（如ConnectException）是定位根因的直接线索，比盲目尝试命令更高效。→ 习惯：遇到服务启动失败，第一时间查看对应日志（HBase 日志在logs目录，Hadoop 日志在hadoop-3.1.3/logs）。
3. Linux 权限问题需 “追根溯源”，而非依赖sudo
多次遇到 “权限不够”，初期想直接用sudo跳过，但反而触发 “sudo 找不到命令”。Linux 权限问题的核心是 “所有者 + 权限位”：
-
所有者必须是执行用户（如
atguigu），否则即使有x位也可能无权限； -
执行位（
x）需针对所有者（u+x），而非所有用户（a+x），保证安全性。→ 原则：优先用
chown改所有者，再用
chmod加执行位，避免滥用
sudo
4. 服务启动 / 停止需遵循 “底层到上层” 的顺序
分布式集群的依赖关系是 “HDFS（存储）→ YARN（资源）→ HBase（应用）”，启动时违反顺序会导致依赖失败，停止时违反顺序会导致数据残留：
-
启动：HDFS → YARN → HBase；
-
停止：HBase → YARN → HDFS。
→ 习惯：操作前先明确组件依赖，避免 “跨级” 启动 / 停止。
5. 进程残留需 “彻底清理”，避免 “假死” 干扰
HRegionServer 关不掉时，仅用stop-hbase.sh无效，需手动kill -9并删除/tmp/hbase-*残留文件。临时文件（如 PID 文件）会让脚本误以为进程已存在，导致下次启动失败。→ 技巧：服务异常停止后，必删/tmp下对应组件的临时目录（Hadoop：/tmp/hadoop-*；HBase：/tmp/hbase-*）。
四、问题排查方法总结表
| 问题类别 | 典型现象 | 排查步骤 | 解决方案 | 预防措施 | |
|---|---|---|---|---|---|
| 命令找不到类 | 执行start-hbase.sh/start-dfs.sh提示 “未找到命令” | 1. 用which 命令查看是否在 PATH；2. 确认命令实际路径（如 HBase bin、Hadoop sbin） | 1. 临时：用绝对路径执行；2. 永久：编辑~/.bashrc，添加路径到 PATH，source生效 | 安装软件后，立即将bin/sbin目录添加到 PATH；记录软件安装路径 | |
| 权限不足类 | 执行脚本提示 “权限不够”；ls -l显示无x位或所有者为root | 1. ls -l 脚本路径查看所有者和权限位；2. 确认执行用户是否为所有者 | 1. 改所有者：sudo chown -R atguigu:atguigu 目录；2. 加执行位：chmod u+x 脚本 | 安装软件时用目标用户（如atguigu）解压 / 移动；避免用root操作普通用户文件 | |
| 服务启动失败类（依赖问题） | HMaster启动后消失；日志显示 “连接 HDFS/ZooKeeper 拒绝” | 1. 查看服务日志（定位依赖组件）；2. 检查依赖服务状态（如 HDFS 用hdfs dfsadmin -report）；3. 确认依赖配置（如端口、地址） | 1. 修复依赖服务（重启 HDFS/ZooKeeper）；2. 统一配置（如 HBase 与 HDFS 端口）；3. 同步配置到所有节点 | 启动服务前，先验证依赖服务状态；修改配置后必同步所有节点 | |
| 进程残留类 | stop-hbase.sh/stop-dfs.sh后，jps仍显示进程；提示 “进程已存在” | 1. jps查看残留进程 PID；2. `ps -ef | grep PID` 确认是否为僵尸进程 | 1. 脚本停止：hbase-daemon.sh stop regionserver；2. 强制杀死：kill -9 PID；3. 删残留文件：rm -rf /tmp/组件-* | 服务停止后，必用jps验证；定期清理/tmp下临时文件 |
| 配置不一致类 | 日志显示 “连接 IP: 端口拒绝”；组件间通信失败（如 HBase 连不上 HDFS） | 1. 查看依赖组件配置（如 Hadoop core-site.xml）；2. 查看当前组件配置（如 HBase hbase-site.xml）；3. 对比关键参数（如端口、地址） | 1. 统一关键配置（如 HDFS 地址、端口）；2. 用scp同步配置文件到所有节点；3. 重启组件生效 | 配置文件修改后，用diff对比主从节点配置；记录关键配置参数（如端口） |
五、后续运维建议
- 配置文件备份：将
core-site.xml、hbase-site.xml等关键配置文件备份到~/conf_backup，避免误改后无法恢复； - 脚本自动化：编写启动 / 停止脚本（如
start-cluster.sh包含 HDFS→YARN→HBase，stop-cluster.sh包含 HBase→YARN→HDFS），减少手动操作错误； - 定期检查：每天启动集群后，用
jps（所有节点）、Web UI（HDFS：50070，YARN：8088，HBase：16010）验证集群状态； - 日志归档：定期将
logs目录日志归档（如按日期命名），避免日志过大影响排查效率。
管理分布式集群的关键在于遵循正确的启动和关闭顺序，以确保数据一致性和服务稳定性。
扫一扫
1667
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
