老哥，这种HMaster莫名挂掉的情况我之前在运维HBase集群时碰到过好几次，结合踩过的坑和常见排查思路，给你列几个重点方向，你可以逐一排查：

1. 内存资源不足 #

• HMaster默认的JVM堆内存可能不够，尤其是NameNode和SecondaryNameNode本身就占用大量内存，容易导致HMaster被系统的OOM Killer强制杀掉。你可以检查系统日志（比如/var/log/messages或执行dmesg命令），搜索oom-killer或者HMaster的进程ID，确认是不是被内存回收机制干掉了。
• 调整HMaster的JVM参数：修改$HBASE_HOME/conf/hbase-env.sh里的HBASE_HEAPSIZE，根据服务器物理内存情况调高（比如从默认1G改成2G，别超过物理内存的70%）：

  export HBASE_HEAPSIZE=2048
  

2. HBase配置冲突或异常 #

• 重点检查$HBASE_HOME/conf/hbase-site.xml里的核心配置：
  • 确认hbase.rootdir指向的HDFS路径正确，且HDFS集群（NameNode）能正常提供读写服务（虽然你说NameNode正常，但要确保HBase进程有权限访问该路径）。
  • 检查hbase.zookeeper.quorum配置的ZK集群节点是否全部正常运行，HMaster严重依赖ZK管理集群状态，ZK节点波动或连接失败会直接导致HMaster退出。
  • 确认hbase.cluster.distributed设置为true（分布式集群模式），如果是伪分布式模式部署多节点会出问题。

3. 深挖HMaster错误日志 #

• 你提到有错误日志，这是最关键的排查依据！找到$HBASE_HOME/logs目录下的HMaster日志文件（文件名格式一般是hbase-<用户名>-master-<主机名>.log）：
  • 重点看日志末尾的ERROR或FATAL级别的信息，比如是否出现HDFS读写超时、ZK会话过期、权限不足（比如HMaster进程没有HDFS目录的读写权限）。
  • 如果你部署了主备HMaster（在NameNode和SecondaryNameNode各一个），还要看是不是出现脑裂问题，或者备节点尝试切换为主节点时失败。

4. 系统资源限制不足 #

• 文件描述符限制：HBase需要大量文件描述符，默认系统上限可能不够。执行ulimit -n查看当前值，至少要设置到65536以上。修改/etc/security/limits.conf添加以下配置：

  hbase soft nofile 65536
  hbase hard nofile 65536
  

• 进程数限制：同样在limits.conf里调高进程数上限：

  hbase soft nproc 32768
  hbase hard nproc 32768
  

  修改后需要重新登录HBase用户生效。

5. 网络或防火墙问题 #

• 检查NameNode/SecondaryNameNode与其他节点（DataNode、ZK节点）的网络连通性：用ping测试延迟和丢包，用telnet <节点IP> <端口>测试关键端口（比如HBase的16000/16010、HDFS的9000、ZK的2181）是否能正常连通。
• 确认防火墙（iptables或firewalld）没有拦截这些端口的通信，必要时可以临时关闭防火墙测试是否恢复正常。

6. 版本兼容性问题 #

• 确认你的Hadoop和HBase版本是兼容的，比如HBase 2.x对应Hadoop 3.x，HBase 1.x对应Hadoop 2.x，版本不匹配会导致各种莫名其妙的服务异常。你可以对照HBase官方的版本兼容矩阵确认。

内容的提问来源于stack exchange，提问作者ABHISHEK RANA