【 TiDB 使用环境】生产环境
【 TiDB 版本】7.3.0
【遇到的问题：问题现象及影响】服务器tikv里面db文件夹存储过大，这里面为什么会有好几万个，总共550g，真实数据也就100g，也不敢删，说是正常的数据
【资源配置】
检查gc情况，select * from mysql.tidb看看
.sst就是KV键值对数据，看下rockdb就知道了
https://docs.pingcap.com/tidb/v8.4/rocksdb-overview
在 TiDB 中，.sst 文件（Sorted String Table 文件）是 RocksDB 用于持久化存储数据的关键组件。RocksDB 是一种高性能的嵌入式键值存储引擎，采用 LSM-tree（Log-Structured Merge-Tree）架构。以下是 .sst 文件生成的基础和过程，以及 RocksDB 在数据持久化和检索中的作用：
.sst 文件的生成过程
- 数据写入：当用户向 TiDB 写入数据时，数据首先被记录到 RocksDB 的 Write Ahead Log (WAL) 中，然后写入内存中的 MemTable（一个 SkipList 数据结构）。
- MemTable 刷新：当 MemTable 中的数据达到一定大小时，RocksDB 会将其内容刷新到磁盘上，生成一个新的 .sst 文件。这个过程称为“刷盘”。
- 多级存储：.sst 文件在磁盘上以多级结构组织，通常有多达 6 个级别。当某一级别的总大小达到阈值时，RocksDB 会选择部分 .sst 文件并将其合并到下一级别。每个后续级别的大小是前一级别的 10 倍，因此大部分数据存储在最后一个级别。
换个版本吧7.3.0是DMR , 可以升级到7.5.5
1 个赞
看起来很奇怪 还没遇到过
看看grafana的overview里，是不是有很多空region？
这个怎么看呢，大佬？
这个是怎么计算出来的呢？可以先看看gc设置的多大，gc是否正常运行
会不会有经常删数据但是没来得及gc回收的表
看gc时间，如果没问题，就说明你的数据本就有500G
版本升级一下
看看GC 时间
select * from mysql.tidb
执行这句，看看tikv_gc_life_time 设置的是多长时间
10m0s
备份数据，也通过还原数据没问题，备份大小就是100左右
tikv_gc_last_run_time 和 tikv_gc_safe_point 这俩呢
这两个都是
20240808-08:08:59.683 +0800
可以看下你的gc是否正常，上次gc的时间是啥时候。br只备份leader的，数据量还要看副本数。