那是不是只能进行不安全的操作了？
感觉是必须 停集群了（unsafe recover 建议 关闭调度，最好业务也关掉及 tikv 关掉比较好，担心有其他情况导致异常）tidb in action 这本书里有写步骤
我让我们研发帮看看了，不过信息太少，只能问一下，有没有其他办法（问一下，咱们可以重启集群不，咋觉得重启集群会好呢，想先重启集群，并修改 tikv 日志级别）
周六（3.5）重启了一下，还是没有好，原因是pd里面store 4没有删除掉吧
remove-peer有没有这样的接口操作，这样的接口好像比ctl好用
1、咱们可以把 store 55179137 的 tikv 日志级别改成 info级别吗，只改这个，重启这一个 store 就行（现象信息太少，不好排查）
— 我解释一下吧：重启不起作用，是因为 region 的 leader 还是正常的，另外有点担心：unsafe recover 虽然能让 这个 region 看起来好（实际现在也是好的），unsafe recover 只是更改了元数据（去掉了 store 4上的2个 peer），但本质问题不一定能解决：在新的 store 55179137 添加 peer，所以想要看看为啥 在 store 55179137 上无法成功添加 peer，就需要看咱们的 日志（而且添加完 peer 之后，应该不需要 unsafe recover 就可以解决问题
1 个赞
1、建议直接趁着这次机会修改参数
2、可以先去这台服务器上，手动执行 systemctl start xxx.service 启动，如果还启动不起来，看看对应服务的日志，看启动不起来的原因
— 补充：xxx.service 可以在。/etc/systemd/system下 查看具体名称
1 个赞
现在操作， 风险最低的就是先扩容tikv， 然后下线有问题的tikv 再查问题， 这种效率沟通， 万一操作有问题， 就只能跑路了
1 个赞
有没有扩容和下线的有问题的tikv操作文章？
你现在集群正常工作吗？
先找一台 新机器 扩容tikv， 剩下就是处理tikv的问题了。
如果你出问题的kv 还在工作， 那得先 驱逐上面的leader， 然后force ， 如果没工作， 那就放着先查问题