13518219792
这期内容当中小编将会给大家带来有关Hbase master gone系统崩溃、遭遇hbase bug以及对应的解决方案是什么 ，文章内容丰富且以专业的角度为大家分析和叙述，阅读完这篇文章希望大家可以有所收获。
为朝阳等地区用户提供了全套网页设计制作服务，及朝阳网站建设行业解决方案。主营业务为成都网站设计、网站制作、朝阳网站设计，以传统方式定制建设网站，并提供域名空间备案等一条龙服务，秉承以专业、用心的态度为用户提供真诚的服务。我们深信只要达到每一位用户的要求，就会得到认可，从而选择与我们长期合作。这样，我们也可以走得更远！
hbase 双master 架构, 挂掉了.
master 无法转为active了 . 整个系统重启多次 爆同样的错误.
2019-05-21 14:50:55,189 WARN [hadoop-8-52:16000.activeMasterManager] util.FSHDFSUtils: attempt=3 on file=hdfs://clusterpc/hbase/MasterProcWALs/state-00000000000000026244.log after 73101ms
org.apache.hadoop.ipc.RemoteException(org.apache.hadoop.hdfs.protocol.AlreadyBeingCreatedException): Failed to RECOVER_LEASE /hbase/MasterProcWALs/state-00000000000000026244.log for DFSClient_NONMAPREDUCE_-23587253_1 on 192.168.8.52 because the file is under construction but no leases found.
发现
/hbase/MasterProcWALs
下面很多文件
已经很久了. 这个目录下面一共有1800多个文件.
这些文件都是0 长度的.
最后重启hdfs .
重启zookeep
然后重启 hbase 问题解决.
但是奇怪的事情发生了.
上面目录里的文件都消失了.
系统启动后, 从日志里去找点东西出来看看:
2019-05-21 15:31:12,843 INFO [hadoop-8-51:16000.activeMasterManager] procedure.ZKProcedureUtil: Clearing all procedure znodes: /hbase/online-snapshot/acquired /hbase/online-snapshot/reached /hbase/online-snapshot/abort
2019-05-21 15:31:12,852 INFO [hadoop-8-51:16000.activeMasterManager] procedure.ZKProcedureUtil: Clearing all procedure znodes: /hbase/flush-table-proc/acquired /hbase/flush-table-proc/reached /hbase/flush-table-proc/abort
2019-05-21 15:31:12,879 INFO [hadoop-8-51:16000.activeMasterManager] master.MasterCoprocessorHost: System coprocessor loading is enabled
2019-05-21 15:31:12,892 INFO [hadoop-8-51:16000.activeMasterManager] procedure2.ProcedureExecutor: Starting procedure executor threads=25
2019-05-21 15:31:12,893 INFO [hadoop-8-51:16000.activeMasterManager] wal.WALProcedureStore: Starting WAL Procedure Store lease recovery
2019-05-21 15:31:13,016 INFO [hadoop-8-51:16000.activeMasterManager] util.FSHDFSUtils: Recovering lease on dfs file hdfs://clusterpc/hbase/MasterProcWALs/state-00000000000000026244.log
这些文件都被执行了一次恢复操作.
是什么问题导致的这些标志文件 ,
集群是主从两个master 的. 一直都监控运行. 系统稳定性良好.
故障切换也没有问题.
在网上找到了一篇 详细的关于hdfs 文件恢复的帖子:
https://blog.cloudera.com/blog/2015/02/understanding-hdfs-recovery-processes-part-1/
master 在8.51上的时候, 发现 多了很多这个文件.
然后web 页面看到 很多 region in tracsaction 也就是spli 失效了.
然后手动切换到 8.52
这些文件就消失了.
同时在 8.52 上 日志里看到了修复这些文件的日志.
2019-05-23 09:43:48,423 INFO [hadoop-8-52:16000.activeMasterManager] util.FSHDFSUtils: Recovering lease on dfs file hdfs://clusterpc/hbase/MasterProcWALs/state-00000000000000028058.log
2019-05-23 09:43:48,435 INFO [hadoop-8-52:16000.activeMasterManager] util.FSHDFSUtils: recoverLease=true, attempt=0 on file=hdfs://clusterpc/hbase/MasterProcWALs/state-00000000000000028058.log after 12ms
2019-05-23 09:43:48,470 INFO [hadoop-8-52:16000.activeMasterManager] util.FSHDFSUtils: Recovering lease on dfs file hdfs://clusterpc/hbase/MasterProcWALs/state-00000000000000028059.log
2019-05-23 09:43:48,471 INFO [hadoop-8-52:16000.activeMasterManager] util.FSHDFSUtils: recoverLease=true, attempt=0 on file=hdfs://clusterpc/hbase/MasterProcWALs/state-00000000000000028059.log after 1ms
2019-05-23 09:43:48,493 INFO [hadoop-8-52:16000.activeMasterManager] util.FSHDFSUtils: Recovering lease on dfs file hdfs://clusterpc/hbase/MasterProcWALs/state-00000000000000028060.log
也就是 只要适当的安排 master 的相互切换.
其实既可以规避这个问题.
发现HBASE 的一个bug . https://issues.apache.org/jira/browse/HBASE-14712修复版本 1.2.0 .
问题出在 这个
/hbase/MasterProcWALs 下面的日志太多了 .
然后 在master 变成 active 之前, 需要回复这些文件.
当这些文件太多的时候, 在想namenode 请求信息的时候.
导致 tcp buffer 满了.
然后对namenode 形成了事实上的ddos 攻击.
然后master 超时下线了.
所以启动不了.
重启 集群就可以了. 或者让这个目录下面的文件数不要太多.
------------------ 解决方案 ------------------
如果 暂时无法执行版本升级.
那么 可以周期性的切换 master 来规避这个问题.
上述就是小编为大家分享的Hbase master gone系统崩溃、遭遇hbase bug以及对应的解决方案是什么 了，如果刚好有类似的疑惑，不妨参照上述分析进行理解。如果想知道更多相关知识，欢迎关注创新互联行业资讯频道。
