一下命令如果涉及认证问题请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
没发现好办法。。但是我想到了一个办法。。