kudu ksck 部分表 TS unavailable

一下命令如果涉及认证问题请sudo su kudu 或者kinit kudu@xxx.xxx

检查所有kudu表是否正常

kudu cluster ksck master.data.com:7051,node02.data.com:7051,node03.data.com:7051

发现部分表属于不正常状态。

原因。kudu的分区都分布在不同的机器上，比如分区a分布在node1 node2 node2，因为某些原因node2和node3下线了，或者把tablet server下线了。默认kudu文件的replia=3.那么此时这一份数据文件就只有一份了。其实很危险了，万一哪天哪个开发把node1机器也下线了，那么这份数据就没了。。。。。但是此时副本只有1还是不影响正常的查询的，因为这份数据还在，但是怎么避免这种风险呢？

下面介绍。

kudu cluster ksck master.data.com:7051,node02.data.com:7051,node03.data.com:7051 -tables=

default.good

 

 

可以看到有两个分区数据有问题，区kudu webui查看下 

确实存在问题

其中 81556965eed74b38b7c14761a5b42954   f7c9944884cc4a9692e5024fbda16305 

就是之前下线过的tablet server 的uuid。所以此时不可用了

修复 通过刚刚的ksck可以得到如下信息

tablet_id a3e8566605664a958f827c302223c7a1

peer uuids f7c9944884cc4a9692e5024fbda16305

正常节点tserver_address  node02.data.com

kudu remote_replica unsafe_change_config <tserver_address> <tablet_id> <peer uuids>

kudu remote_replica unsafe_change_config node02.data.com:7050 a3e8566605664a958f827c302223c7a1 1ce85cdecff240d5b191d512b927ef5a

 执行前

执行后

如果手速过快 使用 unsafe_change_config再ksck可以看到在复制中

但是。。。。令人操蛋的地方出现了。

三个b都挂了 神仙也难救。。下次研究下怎么把这个b 踢出去。 。。

2021-11-08

 

实际当我们在下线一个tablet server的时候，kudu会自己复制，看了一篇文章大概是5分钟，这个tablet server 不上线就会复制副本

 

kudu cluster ksck master.data.com:7051,node02.data.com:7051,node03.data.com:7051

 Corruption: table consistency check error: 264 out of 301 table(s) are not healthy

可以看到有264个tables 受到了影响，等了几分钟

 

 

 

 

最后发现就剩下的6个表(有的3个tablet 都挂了)属于不健康状态。。

后面我看了kudu官网命令行Apache Kudu - Apache Kudu Command Line Tools Reference 

没发现好办法。。但是我想到了一个办法。。