这样啊，学习了，谢谢 没设置成0，是因为tiflash同步特别的慢，设成0，捯饬完再设回来，怕时间不够。是生产环境夜里操作的，到早晨必须恢复到正常可用。 那现在应该怎么清理掉墓碑呢？有专家能给指点下吗

没有将tiflash replica设置为0 当时这3个节点的tiflash起不来了，一直是disconnect状态，应该没有在同步tikv

升级服务器的操作系统，重启了机器 然后tiflash有3个节点起不来了，一直报错循环重启，报错截图没留，大概就是这3个节点互相没法通信 然后就让运维同学用pd-ctl强制缩容了，因为正常缩容一直是pending状态，还是循环报错起不来 然后扩容时报错说这3个store还存在： [2023/12/23 01:53:34.636 +08:00] [FATAL] [run.rs:1267] ["failed to start node: Other(\"[components/pd_client/src/util.rs:885]: duplicated store address: id:4…

感谢上面两位的帮助 慢SQL不好查的，CPU被打高了之后，所有sql都是慢SQL了 线上环境，qps在100多，很难肉眼排查，只能依赖于Top SQL这种统计信息

收到，那就升级一下了。谢谢

版本号提问里选了，6.1.1 强制走tikv和强制走mpp一样，是正确结果 [image] count是一样的 [image] [image]

可以了，谢谢

有专家能给指点下吗

好的，赞

夜里跑完了全部压测，没有出任何异常情况 所以就简单的改这个参数了 建议咱们tidb可以在新版本增加个参数来控制这个balance 感谢指点！

我研究了一下代码，把这个参数从 false 改为了 true [image] 因为我发现 GetTiFlashRPCContext 函数内部，如果loadBalance= false 的话，总是返回找到的所有store中的第一个，就造成了热点，改为true的话每次会换一个。 目前编译替换后，跑压测就完全平衡了： [image] 但是不知道原来传入false是什么考虑，改为true了有什么副作用没？是不是就是注释里说的： // loadBalance is an option. For MPP and batch cop, it is pointless and might ca…

这样确实解释了我这个现象了 这个balance的逻辑是最近加的吗？我最早用5.4版本压测好像挺均衡的 我现实的业务场景，就是这个数据分布和SQL分布，tiflash资源就浪费了 该怎么办才能让负载平衡呢？有没有什么参数可以设的

继续请教一下： 假设有4个节点分别叫ABCD，sql是在A节点的tidb服务上执行的 假设这个SQL只涉及到一个表的一个region，这个region有ABCD 4个tiflash副本可用，那么选择哪个副本的逻辑是啥？

另外开了帖子在问了，此贴关掉

我来补充信息了，sorry晚了些，集群刚跑完压测空出来 发现了更多有趣的信息： 刚跑完压测，没动集群，跑原来异常的SQL，不出错了，explain analyze的结果如下： explain_analyze.txt (291.0 KB) 重启tiflash，再跑，依然不出错 重启整个集群，再跑，错误出现，有2个节点用掉了5k多个线程不释放 截图和metrics如下 [image] [image] mc-TiFlash-Summary_2022-09-21T09_47_41.154Z.json (478.6 KB) mc-TiFlash-Proxy-Details…

mc-TiFlash-Summary_2022-09-21T09_14_08.949Z.json (915.8 KB)

好的，我弄一下试试，还没玩过这个 集群有4000多张表，上面帖子里说了

好的，现在集群在跑压测，这一两天我扒下来发您 感谢关注

sorry 看到的晚了 explain结果见附件，explain analyze跑不出来结果，报错线程资源耗尽 explain.txt (195.1 KB)