[转帖]记一次sst文件损坏修复过程

一次,sst,文件,损坏,修复过程 · 浏览次数 : 0

小编点评

**问题定位:** 1. region_id是2435254出问题的通过pd-ctl查看region详情发现region正常,通过navicat查询上面删除数据一切正常。 2. 出现异常情况:region分裂、合并时访问到这个region导致删除失败。 **修复方法:** 1. 使用bad-ssts检测有问题的sst文件:`tikv-ctl bad-ssts --db /data/tidb-data/tikv-20160/db --pd 10.20.10.63:2379` 2. 使用--data-dir指定data-dir目录报参数错误,使用了tikv-ctl + --db参数后执行正常:`tikv-ctl bad-ssts --db /data/tidb-data/tikv-20160/db --pd 10.20.10.63:2379` 3. 删除损坏的sst文件: - `tikv-ctl ldb --db=/data/tidb-data/tikv-20160/db unsafe_remove_sst_file "/data/tidb-data/tikv-20160/db/10973719.sst"` 4. 删除region peertikv-ctl --db=/data/tidb-data/tikv-20160/db tombstone -r 2336448 --pd 5. 使用tikv-ctl --data-dir=/data/tidb-data/tikv-20160 tombstone -r 2336448 --force处理成功。 6. 查看之前访问报错的数据已经正常。 **其他提示:** - 在修复过程中,建议使用最新版本的tikv,并根据情况进行调整。 - 在删除sst文件时,请确保目标文件存在。 - 使用pd监控大屏healthregion中发现有82个region处于down_peer_region状态,建议对这些region进行手动修复。

正文

https://tidb.net/blog/54e388c8

 

【2023-07-14 14:26:28】应用系统报警删除数据失败,查看日志报Region is unavailable,同时企业微信群也收到数据库告警信息。

image.png

image

二、问题定位

首先查看集群进程都正常,登录tidb dashboard查看日志。

image

image

登录tidb节点10.20.10.127 查看详细日志,定位到是region_id是2435254出问题的

image

通过pd-ctl查看region详情

image

发现region正常,通过navicat查询上面删除数据一切正常,手动删除数据也正常,因为这张表插入删除数据很频繁,一度以为是中奖了,正好在region分裂、合并时访问到这个region导致删除失败的。

直到2023-07-15日查看tidb日志发现又有同样情况出现,继续深入查看发现是同一个kv报错,如下截图是日志信息

image

这时候社区大佬提醒是不是有sst文件出现了损坏,建议停止该kv逐个检查sst文件。

三、修复

官方文档提供了修复损坏的 SST的方法。

image.png

根据官方文档提供的命令使用bad-ssts检测有问题的sst文件,尝试使用--data-dir指定data-dir目录报参数错误,使用了tikv-ctl + --db参数后执行正常。

tikv-ctl bad-ssts --db /data/tidb-data/tikv-20160/db --pd 10.20.10.63:2379

image

检查了一个多小时,有10个sst文件需要修复,并列出了操作建议。

image.png

第一步:删除损坏的sst文件

按照上述输出的建议命令执行tikv-ctl ldb --db=/data/tidb-data/tikv-20160/db unsafe_remove_sst_file "/data/tidb-data/tikv-20160/db/10973719.sst",报错:Failed: Failed to parse SST file number /data/tidb-data/tikv-20160/db/10973719.sst 。在社区中查看发现需要使用指定sst的文件号而不是文件名,使用 sst文件号执行成功!

第二步从有问题的tikv上删除sst文件的region peer

tikv-ctl --db=/data/tidb-data/tikv-20160/db tombstone -r 2336448 --pd

该命令同样在--data-dir/--db/--pd参数使用上报错,最后使用tikv-ctl --data-dir=/data/tidb-data/tikv-20160 tombstone -r 2336448 --force处理成功,这里建议官方能把这块的文档完善下(也有可能是我用的版本太老了)。

image

至此官方建议的修复步骤就执行完了,重启tikv节点。

查看之前访问报错的数据已经正常。

 

然后再看了下kv节点的日志,发现一直在循环刷同一段日志,而且tidb告警信息PD_down_peer_region_nums还是一直在推送。

image

image.png

在pd监控大屏healthregion中发现有82个region处于down_peer_region 状态

通过 pd-ctl 的 region check down-peer查看副本状态为 Down 的 Region,通过region命令查看region的down_peer的store_id 为刚修复的tikv节点。

image

通过pd-ctl operator add remove-peer 2556939 1133876 手动删除tikv中副本

image.png

不用担心region只有2个副本会出问题,pd会自动复制一份副本到其他kv节点。

至此整个修复完成,集群恢复正常。

与[转帖]记一次sst文件损坏修复过程相似的内容:

[转帖]记一次sst文件损坏修复过程

https://tidb.net/blog/54e388c8 【2023-07-14 14:26:28】应用系统报警删除数据失败,查看日志报Region is unavailable,同时企业微信群也收到数据库告警信息。 二、问题定位 首先查看集群进程都正常,登录tidb dashboard查看日志

[转帖]记一次靠谱的 K8S 排错实战过程,硬核!

http://blog.itpub.net/31545813/viewspace-2925035/ 一 背景 收到测试环境集群告警,登陆 K8s 集群进行排查。 二 故障定位 2.1 查看 Pod 查看 kube-system node2 节点 calico pod 异常。 查看详细信息,查看nod

[转帖]记一次线上Oracle连接耗时过长的问题

https://www.cnblogs.com/changxy-codest/p/15670495.html 问题现象 1、远程Oracle数据库通过IP:PORT/SERVICE_NAME连接 2、应用服务通过Docker容器部署,访问Oracle联通性测试接口,需要50s左右才能返回连接成功;

[转帖]记一次靠谱的 K8S 排错实战过程,硬核!

http://blog.itpub.net/31545813/viewspace-2925035/ 一 背景 收到测试环境集群告警,登陆 K8s 集群进行排查。 二 故障定位 2.1 查看 Pod 查看 kube-system node2 节点 calico pod 异常。 查看详细信息,查看nod

[转帖]记一次flannel网络调整

https://www.jianshu.com/p/a772e4b951f2 背景 最近给一个子公司部署一套k8s集群,集群搭建完之后有几个新需求需要新增几个node节点,在新增节点时发现添加失败,经过查询发现是网络规划问题导致。 flannel启动失败,报错信息如下:Error registeri

[转帖]记一次使用nacos2踩到的坑

https://cloud.tencent.com/developer/article/2077110?areaSource=104001.26&traceId=7WZNP412yK3vh7ebw4th0 前言 本文素材来源朋友学习nacos2.1.1踩到的坑。直接上正菜 坑点一:出现端口被占用 因

[转帖]记一次压测引起的nginx负载均衡性能调优

https://xiaorui.cc/archives/3495 这边有个性能要求极高的api要上线,这个服务端是golang http模块实现的。在上线之前我们理所当然的要做压力测试。起初是 “小白同学” 起头进行压力测试,但当我看到那压力测试的结果时,我也是逗乐了。 现象是,直接访问Golang

[转帖]记一次使用gdb诊断gc问题全过程

https://www.cnblogs.com/codelogs/p/17092141.html 简介# 上次解决了GC长耗时问题后,系统果然平稳了许多,这是之前的文章《GC耗时高,原因竟是服务流量小?》然而,过了一段时间,我检查GC日志时,又发现了一个GC问题,如下:从这个图中可以发现,我们GC有

[转帖]记一次vcsa6修复过程

一、 某天发现一台vmware vCenter Server Appliance services 6偶尔能登陆了,但极不稳定,连shell都偶尔能进...... 然后利用各种手段想方设法进到shell里,这是必须的,否则白谈.... 首先查看空间:df -h,发现/和/storage/log都用了

[转帖] 记一次使用gdb诊断gc问题全过程

记一次使用gdb诊断gc问题全过程 原创:扣钉日记(微信公众号ID:codelogs),欢迎分享,转载请保留出处。 简介# 上次解决了GC长耗时问题后,系统果然平稳了许多,这是之前的文章《GC耗时高,原因竟是服务流量小?》然而,过了一段时间,我检查GC日志时,又发现了一个GC问题,如下:从这个图中可