根因是 For a large table with multiple range queries, if the region count exceeds 128, the last range may be not limited. 问题在于扫描的region超过128就会报错。analyze后能正常，可能是有了比较准确的统计信息后，扫描的region个数小于128了。 当然重启能解决更好，不过我感觉恐怕于事无补。 另外这个issue，其实代码改动非常小。 [image] 改动一下pd代码里面对应文件的这个判断的位置就完成修复了。 如果着急，不如自己搞个8.5.…

几个要素都有，大表，超过128个region，count。

看上去是这个bug。描述非常接近。 好消息是这个bug修掉了，坏消息是这个bug2周前才修的，现在还没有最新可用的子版本包含这个修复。

开庭时带着你在论坛的发帖

2楼说的没问题，这个是tikv自己上报的状态，所以你的pd访问不到这个tikv，但这个tikv可能是可以访问到pd的。

纯单机的话，我觉得换一个产品的成本更低。 我总觉得一个产品适应所有场景的说法，应该只有广告和销售会喜欢。 实际用起来就很难和广告/销售说的一样。

同意楼上，这类6.5左右的版本的ddl卡住问题，最后还能通过重启解决的，大概率都和元数据锁MDL有关。建议直接关闭MDL。

主要问题在于已经确认是个bug了，不升级就挺难搞的。

先扩再缩是很稳妥的做法，而且你好像只是说pd节点？那更安全一些。

dm的promethus组件需要单独部署，和tidb的混用会比较麻烦。 单独部署的话，你扩容dm-worker就自动加入进去了。 如果一定要整合的话，你看看下面这个文章

看上去就是这个bug。 问题是这个bug的修复没有合并到7.5这个分支上，而是直接合并到了master。 7.5版本还没有可用的子版本包含这个修复，晚于2024年6月17日发布的主版本，以及晚于这个时间的8.1的子版本是包含这个修复的。 目前来说，只有8.1.1之后的子版本，和8.5.0之后的子版本才包含这个修复。

真的有用嘛？不会睡前朗诵完更有精神了嘛？

网络不行，写入慢确实是没办法的。但你网络是现在这个情况，正常的tcp连接本来就会断的情况下，binlog压缩了该断一样断的。 就支持一个特性的角度，我觉得你的需求没问题。不过就你出现的这个问题而言，我觉得即使有这个特性，可能改善的效果也是微乎其微的。

意思是你原本的 replication.max-replicas 就被你改过了，设置的是1或者2？ 我还是想知道你现在这个参数设置到底是什么。

[image] 你设置的是几个副本？ https://docs.pingcap.com/zh/tidb/stable/pd-configuration-file/#max-replicas 默认3副本的话，tikv的节点数量已经小于副本数量了。这个缩容真要能下线的话，就丢数据了。 如果你确认就是丢数据也要缩容，那就在缩容的时候加 --force 强制缩容 https://docs.pingcap.com/zh/tidb/stable/tiup-component-cluster-scale-in/#--force

那就是把tiflash的mpp扫描视作了一个带索引的扫描？然后就选了indexjoin？ 我觉得这里预估行数estRows已经看到很大的情况下，从tiflash的mpp扫描不能视作一个带索引的扫描，行数这么多，列存扫到这么大的数据，返回还要列转行，这个速度比根据索引扫描要慢得多。

不建议折腾原来的task。已经运行的好好任务，这个时候你去修改，往往引入一些不必要的麻烦。 个人建议，最好是新加一个task，里面的过滤规则就设置同步这个表就好了。 相当于一个库有多个任务，相互任务之间，在同步不同的表就好了。

没感觉到有什么问题。 可能写入的比较多，有slow store，和region分裂产生的regionmiss和regionScheduling告警挺正常的。 入门级监控教程，看这个视频