记录一次事故处理50%kudu表无法进行正常访问
测试环境kudu集群事故，影响：测试效果，测试进度，生产发布延迟，需警惕，特此写出过程 操作需谨慎！ 操作需谨慎！ 操作需谨慎！ 任务环境都要以生产环境而对待！
事故原因：
昨天于上午10点，业务说kudu表无法使用后，影响测试，无法正常发布。去scm平台发现kudu_tablet挂了5台
运维查看信息日志后，做近一步处理
1.重启kudu—tablet发现无法启动
2.然后重新查看相关日志
Check failed: _s.ok() Bad status: IO error: Unable to write consensus meta file for tablet e99481bc28d84bd69ccf328bed071d6b to path /data/ktwd/consensus-meta/e99481bc28d84bd69ccf328bed071d6b: Call to mkstemp() failed on name template /data/ktwd/consensus-meta/e99481bc28d84bd69ccf328bed071d6b.kudutmp.XXXXXX: Too many open files (error 24)F1219 1354 raft_consensus.cc:3052]
3.发现文件句柄不够影响io写入，运维停止kudu_tablet，操作
然后重启tablet-server后可以启动tablet-server，但是操作完之后，所有tablet-server部分分区块不可用
具体截图：
这时运维解决不了-上报平台owner后处理
事故分析：
1.问相关运维如何操作的，查看相关记录命令
2.查看kudu_tablet相关日志
3.检查kudu健康状态
cluster
ksck：检查kudu集群的健康
kudu cluster ksck <master_addresses> [-checksum_cache_blocks] [-checksum_scan] [-checksum_scan_concurrency=<concurrency>] [-nochecksum_snapshot] [-color=<color>] [-tables=<tables>] [-tablets=<tablets>]
master_addresses：逗号分隔的master地址
checksum_cache_blocks：是否检查扫描read blocks
checksum_scan：对集群中的数据进行校验和扫描
checksum_scan_concurrency：每个ts设置多少扫描校验执行器，默认4
color：输出是否有颜色
tables：一个逗号分隔的检查tables，空表示检查所有tables
tablets：逗号分隔的tablets id，空表示检查所有tablets
kudu cluster ksck cdh-02:7051,cdh-03:7051,cdh-04:7051
842 out of 1462 table(s) are not healthy
事故处理：
1.找出所有的有问题的kudu_table,并列出来
这里就不贴了
2.如何修复此问题
如何处理这种情况呢？优先考虑恢复tablet server。先查询下有没有节点tablet server服务已经关闭了，有的话，再先启动tablet server服务。然后重新ksck一下，查看tablet副本的可用情况情况。 如果tablet server无法恢复，可以考虑下面的方法。下面的方法可能会导致对该tablet最近的修改数据丢失
使用命令检查
sudo -u kudu kudu cluster ksck cdh-02:7051,cdh-03:7051,cdh-04:7051 -tables='db_test.ods_'
kudu中，表由tablet组成。对于3副本的情况，如果有2个副本所在的tablet Server不可获取(TS unavailable)，且其中一个不可获取的副本为leader。那么会本tablet不能正常的访问。
使用命令修复
使用到的kudu提供的命令行工具： kudu remote_replica unsafe_change_config7。
kudu remote_replica unsafe_change_config <tserver_address> <tablet_id> <peer uuids>…
sudo -u kudu kudu remote_replica unsafe_change_config cdh-04:7050 b8475299d46f47af9e68665db225af42 451c8b9e876c4099a9c1c1d0807f370a
#正常的tablet-server 要修复的tablet-id 正常的server-id
重新使用命令检查
3.修改文件句柄
修改系统文件句柄：ulimit -n 409600
修改集群kudu句柄
4.重启tablet-server
重启tablet-server
5.python脚本过滤条件批处理修复
有多张表，不能访问，可以使用程序解析ksck输出的内容，批量处理生成修改一致性配置的命令，然后批量修改该命令
import re
#获取tablet id
def search1(line):
searchObj = re.match(r'Tablet (\w{32}) .+ not RUNNING',line)
if searchObj:
return searchObj.group(1)
else:
return None
#获取running的server id 主机名
def search2(line):
searchObj = re.match(r'(\w{32}) \(([\w|-]+):\d+\): RUNNING',line)
#获取正则匹配中()包含的信息
if searchObj:
return searchObj.group(1) + ',' + searchObj.group(2)
else:
return None
#读取tablet-id.txt
with open('tablet-id.txt','r') as f :
lists = f.readlines()
#写commond.txt
f= open('commond.txt','w')
#tablet server
ts=''
#tablet id
ti=''
#server id
si=''
command_pre='sudo -u kudu kudu remote_replica unsafe_change_config '
#拼接后的命令
command=''
#匹配计数器
cnt=0
for i in lists:
i = i.strip()
#cnt为0时查找 tablet id那行
if cnt==0 and search1(i) is not None:
ti = search1(i)
cnt += 1
continue
#匹配tablet id之后的三行
if cnt>0 :
cnt += 1
#匹配server running的行
searchObj = search2(i)
if searchObj is not None:
#对返回结果server name和id进行拆分
l=searchObj.split(',')
si = l[0]
ts = l[1]
#四行都匹配完写文件
if cnt==4:
if len(ts)>0 and len(ti)>0 and len(si)>0:
command = command_pre + ts + ' ' + ti + ' ' + si + '\n'
print command
f.write(command)
cnt = 0
ts=''
ti=''
si=''
f.close()
在服务器上执行后
正在慢慢恢复，数据量比较大，就不截图了。
总结
1.tablet server关闭时，tablet的移动(不能同时迁移2台)
tablet server关闭时，tablet的移动。
本部分，是对本文内容的一个补充。
Tablet replicas are not tied to a UUID.Kudu doesn't do tablet re-balancing at runtime, so new tablet server will get tablets the next time a node dies or if you create new tables.8
当一个tablet server被关闭超过一定的时间（默认5分钟），位于tablet server上的tablet会被移动到其它的tablet server9。如果一个tablet server被关闭了很长时间，再启动起来，位于本tablet server上的tablet数目可能很少。其它tablet server上的tablet数据相对较多些，显得不均衡。
