怀疑是业务框架问题，让业务自己排查吧～

跟磁盘满 没有一定关系

哈哈 重启tidb-server 自动恢复

[2024/09/06 01:19:21.089 +08:00] [WARN] [backoff.go:172] [“regionMiss backoffer.maxSleep 40000ms is exceeded, errors:\ntikv disk full: store_id:47953057 reason:"propose failed: tikv disk full, cmd diskFullOpt=AllowedOnAlmostFull, leader diskUsage=AlreadyFull" ctx: region ID: 8465778522, meta: id:8…

如果是官方做了优化 比如7.5.1解决了这个问题 也可以说一下

但没有从根本上解决 如果表大 数据量多 那么消耗的内存应该还是高的

目前的解决办法 region-concurency 调低 但内存消耗还是很高。 后来进行拆表导入 内存就很平稳 。

也不着急 这么久都没继续报错。。 应该不是咱tidb的事。

他们把日志给厂商了 硬件+系统 也没看出来啥 。 在观察观察吧 内核层面的log 没打印 后面开一下

没～ 我们在观察观察吧

dmesg 没有明显error 我找idc同学看看

[image] 目前版本别动 保持默认

返回的时候 ±----------------------------------------------------------+ | File_token | ±----------------------------------------------------------+ | replayer_noKOnmKNqaSFeF7fqqV7-w==_1713854794051992499.zip | ±-------------------------------------------…

统计信息： replayer_8DQPE2X-wLe9I_HqfUHlDA==_1713851037740255330.zip|attachment (797.6 KB)

MySQL [TCSceneryMemberOrderAll]> explain select count(1) as refundCount from TCSceneryMemberOrderAll.RefundSupplier rs inner Join TCSceneryMemberOrderAll.OrderMain om ON om.SerialID=rs.SerialID inner Join TCSceneryMemberOrderAll.RefundOrder ro force index(I…

7.1.4 多了一个 group by

7.1.4 | id | estRows | estCost | actRows | task | access object | execution info …