一、问题描述

　　CDH5的测试环境，HBase的master一直爆红。

　　不良 : Master 汇总： node8（可用性：未知，运行状况：良好）. 该运行状况测试不良，因为 Service Monitor 未找到活动 Master。

　　但奇怪的是Hbase的master是绿色的，也就表示master本身是正常运行的，而且通过hbase shell，查表插入数据也都正常。

　　但爆红嘛，很不爽。搞不明白就求助百度呗，但感觉被好一顿坑。

二、第一步处理

　　浏览了很多帖子，发现基本都是删除/var/lib/cloudera-scm-agent/cm_guid下的guid，然后重启agent。

　　这里需要注意的是，这的确是一种解决大多数主机不良的方法。

　　但这更适用于安装集群的时候，在节点存在大量数据的情况下，这么干的话，请做好迎接更大麻烦的准备。

　　我还就这么干了。

　　cdh5早点的版本，并没有/var/lib/cloudera-scm-agent/目录，而是在/(安装路径)/cm-<版本号>/lib/cloudera-scm-agent/下存在节点主机全局唯一ID的uuid。

　　然后我就rm ./uuid，悲剧的开始。

　　重启agent后：

　　　　查看主机界面，node8节点连接正常。

　　　　hbase爆红依然存在。

　　　　但界面多了另一个告警，CM警告node8失联，进入告警却显示node8连接正常，刷新后告警依然存在。

　　这很奇怪，相当奇怪。

　　

　　但查看数据库中的记录，就明白为什么了，在CM库的HOSTS表中记录了两条node8的uuid。显然，CM判断其中一条处于失联状态。

　　

 

 

 　　找到原因就好办了，删除在uuid文件中不存在的那一条呗。

　　但在打算删的时候，我犹豫了。如果我将原来的uuid删除，这个新的uuid岂不是相当于一台新的节点？那原本的节点上安装的组件以及数据会怎样？

　　这一点只是猜测，我并没有去查证资料或者去测试，如有实际验证的大佬请指点。如果之后找时间进行验证会更新。

三、第二步处理

 

　　虽然是测试环境，数据依然重要。我保守的选择保留旧有ID，即HOSTS表记录的uuid写回/cm-<版本号>/lib/cloudera-scm-agent/uuid中。

　　先关掉master节点的cloudera-scm-server和node8节点的cloudera-scm-agent。

　　修改uuid文件的内容，使用vim编辑器，或者echo，为了避免多出一些不该存在的空格换行啥的，建议使用 echo -n "XXX-XXX-XXX-X" >uuid

　　　然后删除HOSTS表中记录的那条你不需要的uuid。

   重启server和agent。

　　恭喜，问题并没有解决！！！！

　　然后你会发现，HOSTS表中记录了两条一模一样的uuid，而且对应主机都是node8节点。啊，真是太好了呢，双胞胎唉。

　　我突然意识到一个问题，此时无论我是修改数据库的uuid还是修改uuid文件中的uuid，都已经无法使原本的uuid和node8这台节点对应起来了。

　　显然是因为我先前的rm uuid操作和重启agent，使某些东西发生了变动。

　　然后我就对比这新生的两胞胎。果然，就算外表一样，内里还是不同的。CLUSTER_ID不同，然后我就思考，我也许可以去更改这个ID。

　　

 

 

 四、第三步处理

　　有了思路，事情就简单了。但是HDFS的cluster ID在哪记着我倒是知道，但agent记在哪里呢？我翻遍了‘/cm-<版本号>/*’下的文件，没找到。度娘也间歇性抽风。

　　我不得不再次依靠自己，最终我把目标锁定在与uuid同文件夹下的response.avro文件。

　　   vim打开一看……，好，就它了。

　　　

 

 

 　　 显而易见，我不想给它进行反序列化。那咋办，取巧呗。从其他节点上拷贝过来不就行了！！！我真是个天才（即否）！

　　果然事情很顺利。

　　一切又回到了最初的样子：hbase爆红！！！

　　在做无用功这块，我就没输过谁！

　　……

五、言归正传

　　万万没想到，我最后还是找到了这次hbase爆红……慢着，你以为是原因吗？并不是，而是病友，逛cloudera社区逛出来六年前的病友……一个悬而未决的帖子，疑是CM监控问题而非hbase问题。也许现今庞大的网络中的某处存在着它的解决方法以及原因剖析，但暂时我是没兴趣了。或者有请隐藏大佬发言。