【 TiDB 使用环境】生产环境
【 TiDB 版本】V7.5.0
【复现路径】对同一台服务器缩容再扩容后执行了 curl -X DELETE http://136.18.1.6:2379/pd/api/v1/store/4?force=true(参考某大神的 专栏 - TIKV节点数据文件误删后不更换服务器快速恢复 | TiDB 社区)
【遇到的问题:问题现象及影响】现在一共有4个store,被缩容的store一直是Offline状态,一直没被删除,然后tikv.log中频繁出现两个error日志,如下图所示
【附件:截图/日志/监控】
你一共三个tikv怎么先缩容再扩容啊?你先找台其他的机器,或者原机器上换个端口扩容个tikv节点,然后再缩容啊。。。。
小龙虾爱大龙虾
(Minghao Ren)
3
同一个节点缩容再扩容进去有啥意义呢
?,3 副本 3 个节点正常缩容是缩不下去的,不了解 TiDB 原理,不建议做什么强制缩容等危险操作,否则容易把集群搞坏
小龙虾爱大龙虾
(Minghao Ren)
6
pd-ctl 执行下 store 命令,再把监控 PD=》Statistics - balance=》Store leader count 和 Store region count 面板截图看下
还是我上面的建议,你先找台其他的机器,或者原机器上换个端口扩容个tikv节点,然后再缩容这个异常的节点吧
谢谢老师,我重新再其他机器上扩容了一台,缩容异常的tikv后状态一直为Pending Offline
请问这个状态会持续多久呢,等这个异常节点缩容完成后我再在这台服务器上扩容一台可以吗,然后再把临时扩容的那台也缩容掉,因为临时的这台资源有限
你再看下这个store的信息,看看region和leader的数量是否再减少
![image](https://asktug.com/uploads/default/original/4X/9/f/3/9f31261cced9001be0b09755f6c2c62a8bf1c073.png)
是leader_count和region_count吗
老师我还有个疑问就是,除了临时扩的那太kv以外剩下的2台KV一直在报错,好像一直在尝试向这个被缩容的kv写数据
前两张图是老kv的后面一张是新扩容的log
谢谢老师我先尝试下上面老师的方式,谢谢您 我是一个初学者遇到些问题请教,您们能无偿帮助给出建议真的非常感谢 ![:grinning: :grinning:](https://asktug.com/images/emoji/apple/grinning.png?v=12)
是生产坏境?使用接口地址操作,艺高胆大。新扩容的数据平衡后,再观察下。之前缩容操作未完成(终止)和又扩容的动作,数据也很大,估计得耐心等等。
今天在检查数据库的时候发现kv日志一直报错无法写入消息了,排查发现这台kv的磁盘有问题就网上找了个方法看着挺靠谱的没想到风险这么大,还好有大神和老师们帮助,谢谢您们,祝您们工作顺利 升职加薪,谢谢您的回复
您好我又发现个问题,我新扩容的kv数据目录只有250G空间,但是我看其他两台kv已经使用到了300多G
Kongdom
(Kongdom)
19
可以考虑再扩容一个节点来分摊存储压力。后期还是要吧每个节点的磁盘空间调大一点。250G的硬盘空间太少了。
明白了老师,这个250G的只是作为一个过度,等待异常的kv服务器缩容完成后,我可以重新在 在这个异常过的kv服务器上再扩容吗,然后把250G的这台kv缩容