遇到的问题：请教一下grafana集群容量和Br备份的容量差的很多这是为什么，这个现象正常嘛
grafana显示集群 4T 大小：
BR备份日志：
1 个赞
有差距正常，但是你这看起来差的也太多了， 确定备份的时候 集群就是 4T了吗？ 看监控 store size 是刚增长上来的？
备份的时候就是4T大小
监控里应该是 存储的目录的大小， 不是数据量大小， 有没有可能你目录里存了别的东西？ 非tikv的数据？
几副本？
BR应该只是备份leader副本数据，follower副本的数据不备份。
看着都是在tikv的data目录下主要，有可能是有一些归档数据造成的，我再看看
三副本
看下是不是 info 结尾的文件占的比较多， 这个相当于 kv 的日志文件，是可以删除的
db目录下的 .sst 和 .log 比较多
这个 Current storage size 是文件系统的统计吧，可以看下你截图的这个 Dashboard 下面 TiKV → store size 的图，那个才真实反映数据规模
一样的，5个tikv，每个现在使用了700G多
还是不一样的，这也不是 4T 啊 
关键是咱不知道 BR 工具展示的 total-kv-size 是怎么计算的。
Grafana 展示的这个是 tikv 汇报给 pd 的存储大小，论坛上有人写过博客，可以搜下
计算的时候应该会包含 snap, db, raft 之类的
到现在也没搞太明白一个表多大，是压缩前还是后的大小，一个库多大。。。
SELECT TABLE_SCHEMA, TABLE_NAME, (DATA_LENGTH + INDEX_LENGTH)/1024/1024 AS total_size FROM INFORMATION_SCHEMA.TABLES where TABLE_SCHEMA NOT IN (‘test’,‘mysql’,‘PERFORMANCE_SCHEMA’,‘METRICS_SCHEMA’,‘INFORMATION_SCHEMA’);
查了之后，感觉也不大，准备升级了后面
要提取库表大小，结果都对不上。。不像mysql，查下ibd就都知道实际的占用空间了。这个确实很难准确
316G db 单独一个tikv的sst目录大小
3节点tikv [total-kv-size=1.946TB] 备份日志
全量备份文件278G
那就是实际数据本来就不大，应该是一些日志文件占用了比较大空间
