缩容tikv快24小时了,还是下线中

【 TiDB 使用环境】生产环境
【 TiDB 版本】5.0.1
【复现路径】做过哪些操作出现的问题
【遇到的问题:问题现象及影响】
【资源配置】
【附件:截图/日志/监控】
raftdb.info日志

tiup还是k8s?
pd-ctl store
看看下线的store是不是还有region。

多少节点下线到多少节点。

tiup

3个节点下线到2个,其实这台是重装的系统,集群恢复后这个节点就一直没有在线过,所以就准备缩容后再扩容看看,是这么一个背景

3 节点没有办法缩容到 2 的,不满足 3 副本最低需求。你得先扩容后缩容

2 Likes

tidb内部机制是三副本的,你先加一个节点,然后再做操作

tiup cluster scale-in --force clustername --node xx.xx.xx.xx:port ,已经离线的节点可以试试这个命令

大佬就是大佬,一下抓到了问题点了。没想到是3缩成2…

4节点了,重新下线了超12小时还是在下线中

那就不预期了,除非扩容的那个不够补数据的 :thinking: 不应该啊。

发下 pd-ctl store 命令的输出信息。

已经莫明的节点重新在线了,之前是因为一直不在线,才想着缩容后,再把他扩容上去,好神奇的事情!谢谢大家的一系列建议

如果是三个节点 宕一个 多久不新增节点会出问题

多久也不会有问题,直到再down一个就没法服务了,然后只能等着节点再启动。

3个节点down 了一个剩下两个,其余的两个还可以正常提供服务,为啥3个节点缩容成2个就不可以呢?

3个节点实例,如果缩容成2个,则 无法满足 raft 协议的最低的要求,然后 3 副本的必备也就无法达成了…

那比如3个节点实例 down 了一个 不也是剩下一个吗?为啥就可以正常提供服务?缩容和down 有啥区别呢

pd那边设置的默认3副本,然后2副本提交后认为数据已经可以commit,挂了一个以后,剩下的2个就得全部提交后才能跑。实际上也能跑,但是缩容为什么缩不回去呢?因为tiup或者k8s里的operator限制着呢,挂了是异常,无法阻止的,不可抗力的。但是缩容干嘛要缩成一个很危险的状态,所以operator、k8s都阻止了。

明白了 谢谢

1、tidb默认的replication.max-replicas为3,因此如果1个region的3个member,要下线掉2个,tidb不会接受这样的请求,可以看看tidb日志信息。
2、如果正常的3个member,下线1个实例,却长时间无法完成,则需要查看如下一些参数,看是否是性能上受到限制:
region-schedule-limit
replica-schedule-limit
max-snapshot-count
store_limit
另外之前也有遇到过,可能是kv storage实际不足,或者kv中设置的存储相关容量限制了迁移进度。

1 Like