检查过每个 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

我们有这样的一个场景的需求，3副本： 单机多实例的业务场景下，隔离级别需要设置成 host，因为需要避免同一个 region 的leader 和 follower 同时出现在一个主机上，如下图： [image] 但是对于上游链路来说，同一个交换机可能管理多个主机，如果需要 region 的高可用一个 host 是不符合需求的，如下图： [image] 那么能想到的解决方案如下： 业务侧自行控制 host 和 rack 的对应关系，避免一个交换机管理多台 tikv host 当交换机调整后，变更 host 的 label （需要 4 个主机） 所以想确认一下是否有 rack,…

看起来不像资源导致的抖动，建议看看在那个时间段都跑起了什么 SQL 语句

您主机配置的网卡是千兆还是万兆的

截一下网卡监控谢谢