是的，没想到会出现这个问题，目前是重建解决，定时进行索引校验

已经知道是什么问题了，索引问题，索引数据和表数据不一致导致的，表的数据是load data进来的 参考这个帖子：TiDB表的索引数据和主表数据不一致 不知道这个问题什么时候给修复

顶一下，我们线上也出现这个问题了

第一个表的结构 [image] 第二个表的结构 [image]

请问这是什么情况，tiflash查询的是没问题的，tikv为何没有查出来

已经解决了，是配置文件的问题，加上dispatchers就好了

按照官网复制改的 [image]

tidb通过ticdc同步数据到kafka，创建changefeed后，查询任务有这个错误

已经更换服务器了。tikv全部换成统一配置的新服务器了，问题解决了

嗯，是的，今天应急就这么操作的，立马生效

总结一下，做个记录： 线上业务tikv做缩容，不要直接tiup cluster scale-in 集群名 --node 10.100.100.101:20161 --node 10.100.100.102:20161，这样会出现大面积dml慢查询，backoff重试 tikv扩容几乎没有影响，或者说性能影响低 tikv下线操作先手动进行leader迁移：tiup ctl:v6.5.5 pd store weight 69804641 0 1 --pd=“http://10.100.100.111:2379” 然后再进行scale-in缩容 应急操作直接stop掉下线的tikv instan…

嗯，我到时候修改下参数 问题原因找到了，就是缩容导致的，扩容无影响 业务sql插入数据时，找不到leader，backoff重试导致的，直接将缩容节点stop掉就可以了

以前没操作过，请问大神有操作命令么

设置为1了，还是有一些慢查询，如何才能取消呢

集群一个三个副本，zone的拓扑规划为z1,z2,z3，现在是对z1里的tikv实例进行了扩容，缩容操作

共3个副本，只对第一个副本的服务器实例进行了扩容缩容操作

tiup ctl:v6.5.5 pd config set label-property reject-leader zone z1 这个脚本没有生效，这个zone z1的leader并没有迁走

如何取消缩容操作，正在查找脚本，还没找到

是的，只是一个副本的