【版本】v5.2.3 arm
【问题】
使用tikv-ctl region-properties 查看某张表的region属性信息,对比显示该region的sst文件有456个,全都是几K的小文件,最大也就100多k , 这个表上已经检查过ddl history没有进行过truncate操作。什么原因会导致产生很多小文件? 如何进行小文件合并?
要不要放在版主交流会?
-
这个取的是 RocksDB 的 GetPropertiesOfTablesInRange 方法,目的是 dump 出给定 range 的 table 信息;
-
这个 range 是对应到 ctl 时,会传入 region 的 range,就出来的对应 CF 的 RocksDB 的信息;
-
什么原因会导致产生很多小文件?
估计跟 rocksdb 自身规则有关 -
如何进行小文件合并?
我觉得 compaction 过后应该会有一定程度减少
但对于 3、4 点其实没有真正解答你的问题,还是需要上版主交流会找个懂 rocksdb 的老师解答下。
BTW : 高版本会显示出 CFName
Hello,出现这种情况有一种场景如下。
- 有一个很大的表,假设垮了 10 个 region
- 通过 delete 的方式陆陆续续开始删除大量数据
- PD 发现 region 1 和 region 2 很小,发起 merge region1,region2
- 在 merge 过程中,需要先把 region 1,region2 的副本迁移到一起,迁移过程中,因为是直接写 sst 文件到目标节点,产生了小 sst 文件
- merge region 1, region2, 成功,这个时候可以看到 merge 后的 region 的 mvcc properties 里面有小 sst 文件 出现
- 同样的道理,发现 region 3 很小,可以开始 mege, 循坏 3-5 的过程
7 最后这 10 个 region 被 merge 成了一个 region, 看最终 region 的 mvcc properties 时,就可以看到很多这种小的 sst 文件了。
如果是上面这种情况,可以通过指定范围进行手动 compaction 来 merge 掉这些小 sst 文件。相关文档: https://docs.pingcap.com/zh/tidb/dev/tikv-control#手动-compact-单个-tikv-的数据
另外,需要从监控和 pd 日志中确认,这个 region 是否是从不断的 merge 生成的。
这种情况是否应该有个机制在合并完后把原来的sst删掉
会的,compaction 完后会把旧的 sst 删掉的
此话题已在最后回复的 60 天后被自动关闭。不再允许新回复。