【 TiDB 使用环境】生产环境
【 TiDB 版本】5.0.1
【复现路径】做过哪些操作出现的问题
【遇到的问题：问题现象及影响】
【资源配置】
【附件：截图/日志/监控】
raftdb.info日志
tiup还是k8s？
pd-ctl store
看看下线的store是不是还有region。
多少节点下线到多少节点。
tiup
3个节点下线到2个，其实这台是重装的系统，集群恢复后这个节点就一直没有在线过，所以就准备缩容后再扩容看看，是这么一个背景
3 节点没有办法缩容到 2 的，不满足 3 副本最低需求。你得先扩容后缩容
2 个赞
tiup cluster scale-in --force clustername --node xx.xx.xx.xx:port ，已经离线的节点可以试试这个命令
大佬就是大佬，一下抓到了问题点了。没想到是3缩成2…
4节点了，重新下线了超12小时还是在下线中
那就不预期了，除非扩容的那个不够补数据的 
不应该啊。
发下 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 个赞