记录一次事故处理50%kudu表无法进行正常访问
记录一次事故处理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数据相对较多些,显得不均衡。
2.kudu文件句柄要设置根据自己业务量评估
3.kudu_tablet分区不能大于1500,大于1500后进行平衡或者扩容
4.kudu表的接入需要规范化
5.无效的kudu表进行下线
6.所有环境一视同仁
低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。
持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。
转载内容版权归作者及来源网站所有,本站原创内容转载请注明来源。
- 上一篇
kubesphere 3.0 安装部署填坑记录
一:系统环境 1.1 系统环境初始化 系统:Centos7.8x64 cat /etc/hosts ----- 192.168.100.11 node01.flyfish.cn 192.168.100.12 node02.flyfish.cn 192.168.100.13 node03.flyfish.cn 192.168.100.14 node04.flyfish.cn 192.168.100.15 node05.flyfish.cn 192.168.100.16 node06.flyfish.cn 192.168.100.17 node07.flyfish.cn 192.168.100.18 node08.flyfish.cn ----- 本次安装以 前三台部署 k8s 部署说明 1.2 系统配置初始化 安装基础工具 yum install -y wget && yum install -y vim && yum install -y lsof && yum install -y net-tools 关闭防火墙或者阿里云开通安全组端口...
- 下一篇
Oracle Linux希望吸引正寻找替代方案的CentOS用户
鉴于本周传出的最新消息显示CentOS 8明年将结束使命,而长期支持版也活不过2024年,CentOS将专注于 "CentOS Stream"作为RHEL的上游,对于很多那些想要一个免费的、几乎相同的CentOS提供的当前RHEL构建版本的人来说是一个非常糟糕的消息。 有鉴于此,Oracle希望能够做好接班人的角色,吸引至少有一部分沮丧的CentOS用户过渡到Oracle Linux。 甲骨文Linux一直在跟踪RHEL的上游,事实上他们的Red Hat Compatible Kernel已经相当接近RHEL/CentOS的vanilla状态。甲骨文本身在提供了围绕甲骨文Linux的支持服务,但发行版本身是免费下载的。最近,甲骨文Linux在针对新的RHEL版本进行分发时比CentOS本身更快。因此,为什么在我们本周早些时候关于CentOS 8将消失的文章中,曾经提到Oracle Linux作为一个替代方案是值得评估的。 为了吸引CentOS的用户寻找替代方案,今天Oracle的一篇博客文章欢迎他们使用这个Linux发行版。为什么要考虑Oracle Linux的原因是,它是免费下载/使...
相关文章
文章评论
共有0条评论来说两句吧...
文章二维码
点击排行
推荐阅读
最新文章
- SpringBoot2配置默认Tomcat设置,开启更多高级功能
- Windows10,CentOS7,CentOS8安装Nodejs环境
- Docker安装Oracle12C,快速搭建Oracle学习环境
- Windows10,CentOS7,CentOS8安装MongoDB4.0.16
- CentOS8编译安装MySQL8.0.19
- MySQL8.0.19开启GTID主从同步CentOS8
- CentOS8安装Docker,最新的服务器搭配容器使用
- CentOS8,CentOS7,CentOS6编译安装Redis5.0.7
- SpringBoot2整合Redis,开启缓存,提高访问速度
- CentOS7,8上快速安装Gitea,搭建Git服务器