region 没问题，就是因为 slow store 掉 leader

[image] 我的每个节点配置都是一样的，而且 br 恢复应该也不会发生写偏斜吧，不知道咋解

用的 br，能让 slow store 的评分不生效吗

任务又建立起来了，我再观察几天看下是否会复现

同步了，我看任务的报警信息，告知目标端的表直接就没了

搜过目标端的日志，没有删除的记录

确实没有 t1 表的 drop table 语句

在下面的路径下 /home/tidb/.tiup/components/ctl/vx.x.x/etcdctl

这个问题应该不是 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 的角度出发能做的事情很有限