这个问题应该不是 tidb 给系统干崩溃，看下来问题的核心，是您的光纤模块驱动和 ol 2203 不兼容的问题 还有从原厂角度出发，我们是否可以考虑在 OpenEuler 社区设置 SIG 组，来紧跟 ol 系统的发版节奏，因为在我这边的场景中，发现了新版本 ol （如 2403）不支持某些硬件的驱动的情况，给我感觉后续 ol 的发版会更频繁，相应的数据库软件也需要适配新的 ol 版本

不创建 a 表，直接 truncate a 表的当天的 partition，在这步会有超时的现象 表没有在 tiflash replica 中，但从后台日志看，在做完了 truncate partition ，tiflash 也是做了 Applying partition changes 的动作 我总体感觉下来是 truncate partition 这步卡主了，业务侧超时

业务在开启前会做 truncate partition 这个动作，在这步会超时退出，结合日志看相关表有 ddl，tiflash 里面也有相应的 Applying partition changes ，感觉要么是 truncate 时间长，要么就是同步到 schema version 在 tiflash 同步时慢（虽然没有加到 tiflash 中）

最高小版本是 6.5.11

检查过每个 tikv gzip 都有的

6.5.7

磁盘没有满，要是满的话应该不会恢复把，单机多实例部署，每个磁盘都是 nvme2.0 ssd

slow score 确实有增加，请问什么因素会导致这个增加呢，我查看过主机 cpu，网络，磁盘均没有瓶颈，就看到单机多实例中部署的其中一个 store 有热点写问题 [image]

没有 [image]

[image] [image]

你如何确定是数据库泄露出去的数据？数据安全是整个系统的事情，拖库可能发生在各个环节，您从 dba 的角度出发能做的事情很有限

有升级，但是我看 pd store 里面的版本号就是 “version”: “7.5.4”,

您的意思是升级的时候 grpc 没有升级成功？

有 gzip

可以参考 OpenEuler （操作系统）的命名方式：22.03 、23.03、24.03 22 代表 2022年 .03 代表 3 月份 每年发一个版本，双数年版本为 LTS 版，奇数年为 火车头版类似 dmr

配置文件中增加相关参数，问题解决 [table-configs.config1] target-tables

配置文件中 f 为分区间，也配置上了

CREATE RESOURCE GROUP IF NOT EXISTS ap_l RU_PER_SEC = 25000 PRIORITY = LOW; create user u1@‘xxx.%’ identified by ‘xxxx’; ALTER USER u1@‘xxx.%’ RESOURCE GROUP ap_l; 跑 SQL 是切换到 u1 用户下，SQL 如下： SELECT xxx,xxx FROM t1 WHERE xx = 123 AND xx >= “2024-07-22” AND xx <= “2024-09-22” GROUP BY id …

我的意思是，如果有机架变更，那么 tikv 要重新打 label，而重新打 label 则有可能导致一个 region 出现在同一个交换机下，隔离在 host 上就有问题了，解决方案如上，所以 tidb 的隔离不能设置两个吗？ tikv : jijia1,host1 jijia1,host2 jijia3,host3