如果是这样的话，可能需要等待，等待 PD 收集完所有的 region 信息 可以参考下 grafana 监控的 region 信息，是否有不一致 如果region 信息未一致（合并和分裂），链接上有任何操作，大概率会报错出现 backoff

线上围观ing

region_id: 115 leader { id: 1075 store_id: 1 } 日志中的 store_id = 1，Leader Id = 1075 并不是你图中提供的 ，是不是做过什么操作？

又要上新周边了～

tidb serverless 对 ai 的支持确实很友好，特别是 RAG 的支持，很香。 做相应的数据关系，人物关系和关键字的检索和自动推理，会比较棒！

这个肯定不正常了，延迟已经是分钟级了（都 30 分钟了，半小时了…） 你先检查下，是数据问题，还是资源的问题导致的

看看 LAG 的指标

那我明白了，你找个空的虚拟机环境，验证下这个过程不就好了 就先装这个版本的 tiup，看看相同的操作，是不是一样的结果 在直接升级，升级到XX版本，记录下来，在验证上面的过程… 就是废点时间，我觉得是值得的

tiup 能升级就升级吧，这样的话，不容易踩坑

[image] 日志里头写的什么？ 猜测，不是超时问题，就是 bug了 参考： [image] [image]

有大事务，就需要更多的内存，这个肯定需要保守策略来支持的 最简单的方式，多分配点内存就好了

保守用法： storage.block-cache.capacity * 2.2 激进用法： storage.block-cache.capacity * 1.5 15 * 2.2 = 33 GB ，刚好超了…

上 explain 看看

查下 dm 的日志 看看冲突的数据是哪些，

用 grafana 看看 PD 的指标

强力围观！

表名一样，对吧，就库名不一样

最傻的方式，就是 table name 一 一 对 应 ，参考下

一分耕耘，一分收获！