从你提供的Master日志来看，核心问题出在WAL日志拆分后的目录清理失败，直接导致RegionServer无法完成恢复流程，进而全部宕机无法启动。具体拆解如下：

核心报错点 #

日志里明确抛出了org.apache.hadoop.ipc.RemoteException(org.apache.hadoop.fs.PathIsNotEmptyDirectoryException): /hbase/WALs/node1,16020,1515405124767-splitting is non empty，意思是HBase尝试删除拆分WAL的临时目录时，发现目录里还有未处理完的日志文件，删除操作失败。

同时，SplitLogManager的警告信息也佐证了这一点：Returning success without actually splitting and deleting all the log files in path...——它错误地标记整个WAL拆分任务为成功，但实际上还有一个日志文件node1%2C16020%2C1515405124767.default.1515405126022留在了splitting目录里。

为什么会出现这个问题？ #

在HBase 1.2.x版本（尤其是1.2.6）中，SplitLogManager的协调逻辑存在一个已知的小缺陷：当WAL拆分过程中遇到网络波动、HDFS响应延迟，或者SplitLogWorker（负责实际拆分的组件）意外中断时，部分日志文件可能会被遗漏，没有被归档到oldWALs目录。而SplitLogManager会在收到部分拆分成功的信号后，错误地认为整个任务已完成，尝试清理临时目录时就会因为目录非空失败，进而卡住整个RegionServer的恢复流程——因为Master一直认为还有未完成的拆分任务，无法正常分配Region给RegionServer，最终导致所有RegionServer无法启动。

手动修复步骤 #

你可以按照以下步骤手动清理残留文件，恢复集群：

• 首先确保所有HBase进程（Master和RegionServer）都已停止：stop-hbase.sh
• 用HDFS命令查看残留的文件：

  hdfs dfs -ls /hbase/WALs/node1,16020,1515405124767-splitting
  

• 将残留的日志文件手动移动到oldWALs目录（这是HBase归档已处理WAL的标准目录）：

  hdfs dfs -mv /hbase/WALs/node1,16020,1515405124767-splitting/node1%2C16020%2C1515405124767.default.1515405126022 /hbase/oldWALs/
  

• 删除空的splitting临时目录：

  hdfs dfs -rm -r /hbase/WALs/node1,16020,1515405124767-splitting
  

• 最后重启HBase集群：start-hbase.sh，观察RegionServer是否能正常启动，Master日志是否再出现类似报错。

内容的提问来源于stack exchange，提问作者Hafiz Muhammad Shafiq