我说的不会丢 是指数据可以恢复出来（最坏的情况）。由于你的tikv较多，最坏就是强制下线的两个节点刚好有同一副本当中的2-3个
-----最坏就是强制下线的两个节点刚好有同一副本当中的2-3个
这个没怎么懂，集群设置的三个副本，丢了2个节点，不是最多就是损失了2个副本吗，第三个副本肯定是在正常的Up状态的tikv实例里的
所以说是可能。因为他是3个kv。你是多个kv,不一定出现这个情况。
你可以用命令 把store 的状态修改为UP
没测过你这种情况是不是可行
curl -X POST ‘http://pd：port/pd/api/v1/store/5/state?state=Up’
之前版本 一次性缩容2个tikv 调度可能会有问题
调度是有问题，现在没办法了，能不丢数据就很好了。
现在插入失败的都写日志了，后面我们的代码有定时读取日志再插入的
算了 我不敢了，如果这样能自己修复就让他修复把 错误已经造成了
后面导致数据库部分不可用
后面没有操作，等待这2个实例中的 region_count 满满减少
报啥错 region is 那个错嘛
代码里报的是timeout,具体的错也不知道哪里能找到
先在region迁移速度非常慢
pd自动的调度包括主要包括2种operator
一种是replace-offline-replica,这个看看日志全部超时了，超时要10分钟，然后看operator show所有的线程全部阻塞住了
就算调大了replica-schedule-limit的值，所有的线程还是都会阻塞住
另一种是replace-down-replica,这个看日志全部finish了，而且耗时只要1-2秒。
看日志2个operator做的事情差不多。
看region check down-peer跟region check offline-peer2个打印很多都是重复的。
我们想确定下这种情况下如果把enable-replace-offline-replica设置为false会不会有影响
大神来帮帮忙啊，能解决问题，我愿意出500块
你的部署display发一下。
能不能加个微信或者qq发 我私聊你
走下认证~
如果你需要获得快速 “加急”处理问题的权限，加快问题响应速度， 点击完成认证，获得“加急”处理问题的权限，方便你更快速地解决问题。
认证后在 导航栏：我的团队-全部主题-加急，直接加急你的问题 。
enable-replace-offline-replica 先尝试关掉这个。如果还是无法解决。 https://docs.pingcap.com/zh/tidb/v4.0/tikv-control/#强制-region-从多副本失败状态恢复服务 参考这个。
3 个赞
不要随意使用 --force
生产操作，最好一次操作一个实例
此话题已在最后回复的 1 分钟后被自动关闭。不再允许新回复。