【 TiDB 使用环境】生产环境
【 TiDB 版本】V6.5.8
【遇到的问题：问题现象及影响】 TIKV 挂了一个副本【例如服务器故障】对业务SQL耗时的影响【在裕度比较充足的场景】，TIDB是否还会把SQL请求发往到这个故障TIKV节点下呢？
TIDB已经检测到故障TIKV，肯定不会下发SQL，但是相关的region肯定会切换，可能会有一定的IO影响
假设读写原来分布在3个tikv上，挂了一个tikv显然读写只能分布到2个上，这两个tikv负载就会高一些，如果资源足够并没有明显影响.
tidb会缓存region分布在哪个tikv上，如果访问不到那个tikv了或者没找到对应region，tidb会访问pd再取新的region分布情况缓存
1 个赞
挂一个会导致其他两个读写压力大一些，丢失leader的region会很快选择出来新的，不会影响sql的执行。
如果还有backup策略那没问题
总体性能会下降，cpu会摊到剩下的两个节点上
这里先不考虑裕度问题，PD发现有个TIKV实例异常了，要说上层来的请求就不应该打到这个异常TIKV上了
是的啊，Region的leader切走了就不会发了
对业务影响应该不大的，region重新选举leader很快的，你backoff都能成功的。只是3个机器的压力压到2个机器上了而已
我看影响还是有一点的，但不大也是真的
会有波动的
另一方面，我其实比较关心挂的这个节点从拓扑里剔除遇到异常，哈哈，不知道你遇到过没有
目前还没碰到过，只能具体问题具体分析了
如果挂了一台TiKV的节点服务器，那么对于Leader在此服务器上的Region，会在其他节点上进行重新选举，此时正在该Region上进行读写的操作会有延迟。Leader不在此服务器上的Region，则一般不会受到影响。写操作一定是在Leader所在的Region Peer上进行的，而读操作可能会在Follower上面进行。
业务没有强一致性读的需求，所以读到的数据在TIKV的FOLLOW上也OK，正好也问问，对于这种故障了一个的TIKV的实例，用tiup工具踢掉这个故障节点时候遇到过预期外的问题么？ 例如剔除失败等
对于已经宕机的TiKV节点，应该检查集群状态，等到涉及的region全部选举完毕后，再使用–force选项对此节点进行强制缩容。
1 个赞
如果只有3个节点，且是三副本，坏了一个不影响使用，但是这个坏的节点是剔除不掉的，必须先再扩容一个节点，才可以剔除，因为3副本有一个副本没有地方存放。。。
其它TIKV整体负载肯定会加重的，原来的不会接受流量
新加后删的操作？我没看到官方文档有这方面的操作，只有简单的scalein or out的操作 
挂了的TIKV节点，从集群拓扑里是什么状态呢？ 这块遇到过么？ 我想抽时间模拟下这种场景