情景:
昨天修改了solr的配置,重启完solr发现有两台kudu server掉了,查看日志发现原来是由于文件句柄太多了导致的。但是由于kudu中的数据太多,container过多,并且full container较少,重启kudu server特别慢,会一直在做log_block_manager,这是由一个已知的bug导致的。https://issues.apache.org/jira/browse/KUDU-2014关于这个jira,也有个应付的办法,就是哪个节点的kudu server重启的慢,就将它关闭上半小时再打开,等它的log_block_manager做完之后去它的webui中看到这个节点没有正在运行的Tablet了之后(即全部飘走了),在cloudera manager中将它删除掉,将系统硬盘中存的数据全清,再重新将这个节点加进来,做上一遍REBALANCE,以后再重启这个节点便会变快。
言归正传,由于重启做log_block_manager太慢,并且所需恢复时间不可预知,因此采用另一种方式:即不启动这2个节点了,先做一遍ksck检测表的健康状况。
sudo -u kudu kudu cluster ksck master1,master2,master3 -verbose > ./ksck.out 2>&1
发现有56个表处于非健康状态:
==================
Errors:
==================
table consistency check error: 56 out of 183 table(s) are not healthy
举例:
在ksck.out中可以看到具体是哪个表的哪个tablet出问题了:
The consensus matrix is:
Config source | Replicas | Current term | Config index | Committed?
---------------+--------------+--------------+--------------+------------
master | A B C* | | | Yes
A | A B C* | 1427 | 2450 | Yes
B | A B C* | 1427 | 2450 | Yes
C | A B C* | 1427 | 2450 | Yes
Tablet 3689e076ed354f94a0967d1eed4b7d16 of table 'impala::dl_zz_kudu.tm_scada_hdzysj_change' is unavailable: 2 replica(s) not RUNNING
868688d5077b4e02b14a8a0a57958668: TS unavailable
0b4f24052ed74405b5d58fecd83f33e7: TS unavailable
a59cf0d8d1ed45d8b1af094f4a28d686 (xxxxx:7050): RUNNING [LEADER]
0 replicas' active configs differ from the master's.
All the peers reported by the master and tablet servers are:
A = 0b4f24052ed74405b5d58fecd83f33e7
B = 868688d5077b4e02b14a8a0a57958668
C = a59cf0d8d1ed45d8b1af094f4a28d686
可以看到只有a59cf0d8d1ed45d8b1af094f4a28d686这一个replication是好的,另外俩都不可用了。
修复命令:
sudo -u kudu kudu remote_replica unsafe_change_config xxxx:7050 3689e076ed354f94a0967d1eed4b7d16 a59cf0d8d1ed45d8b1af094f4a28d686
然后根据ksck.out将出问题的tablet全部抓取出来,全都拼接成这个修复命令,放到一个sh中运行一下再用ksck检查一遍就好了。
最后再将这两个kudu server的数据全清,删除重新加入,再做一遍REBALANCE就好了。