7.5.4 MVCC 优化测试

作者： h5n1 原文来源：https://tidb.net/blog/4e02d900

1. 背景

      由于 MVCC 版本数量过多导致 rocksdb 扫描 key 数量过多影响 SQL 执行时间是 tidb 经常出现问的问题，tidb 也一直在致力于优化该问题。 一些优化方式包括比：

(1) 从传统的集中式 GC 变为 GC in compaction filter，在 rocksdb compact 时进行 GC，降低 GC 时性能影响，同时能将 GC 后的数据直接清理。

(2) 引入 region-compact-min-redundant-rows、region-compact-redundant-rows-percent 参触发更多的 compact 以清理冗余的 mvcc 版本

(3) 修复 GC 相关的 bug , 如：https://asktug.com/t/topic/932932

(4) 7.5.4 及该版本后的版本进一步通过 mvcc.delete_rows 方式解决 region-compact-min-redundant-rows 不能触发的场景。

 有小伙伴在7.5.1版本遇到了这个问题，有一张表目前只有40000多万数据，但全表扫描出来要6亿多total\_keys，GC设置为24小时，检查GC tso推进正常

   但是检查该表的 region 发下最小的 tso 时间还很早，很明显有些 mvcc 数据还没有被 GC，也就没法清理。

  猜测是由于gc in compaction filter等特性导致历史数据没有被GC，而且region上没有多少冗余的mvcc版本导致region-compact-min-redundant-rows等未起作用。
 通过7.5.4 版本引入的MVCC优化特性：**优化存在大量 DELETE 版本时 RocksDB 的 compaction 触发机制，以加快磁盘空间回收 #17269**  issue描述，小伙伴很可能也是这种场景，目前暂未确认，也未进行版本升级尝试。

  要解决上述问题，除了版本升级外还可以通过以下方式解决

(1) 修改参数 enable-compaction-filter 关闭 compaction filter 使用传统 GC 模式

(2) 使用 region compact 手工对表 compact，可以通过 threads 设置并发度。

(3) 重建表表后清理原表，但影响业务

(4) 降低 region-compact-min-redundant-rows、region-compact-redundant-rows-percent 参数值以触发更多 compact，但如果冗余 mvcc 极少的情况下可能没效果。      

2. 测试内容

本测试是验证7.5.4版是否能够解决背景中描述的问题，测试时初始化一张表，然后分段删除表数据，只保留中间和末尾的极少部分数据。

(1) 在 7.5.1 版本按要求删除数据后，观察 GC 情况和全表扫描的 total_keys 数量。

(2) 重启 7.5.1 集群观察重启操作对 compact/GC 是否有影响，以排除升级重启后影响 GC。

(3) 升级到 7.5.4 版本观察测试表的 GC 情况和全表扫描的 total_keys 数量。

(4) 在 7.5.4 版本按照步骤 1 重新测试和观察。

    测试中相关参数保持默认值，如 GC 时间。

3. 版本 7.5.1 删除后测试

测试表插入了42578713条数据，按要求删除后剩余18754条。

刚删完 (2025-01-14 14:22:53）后 total_keys:84985676

2 个多小时后 total_keys:35037709

直到 7 个小时后 key 数量一直保持稳定未变化,total_keys:35037709

    从监控可以看到 17:00 后 GC 几乎无活动。

4. 测试集群重启影响

  重启集群后经过20多分钟观察，keys降到以下数值后未变化，total keys从重启前的35037709降为34866180，减少171529，约0.4%

从GC监控上看有3次GC，但实际是从21:30的GC后 keys数量就一直未变化。

问题： 再重启后观察 total keys：61222618 数量比重启前的 35037709 还要高很多，直到最后稳定在 34866180，为什么这个会变高呢？

5. 升级 7.5.4 版本

使用 offline 方式升级到 7.5.4 版本后 观察 GC 情况，可以看到 22:10 分左右完成升级后 -22:46 totalkeys 降到了 5295017

 从监控上可以看到明显GC活动比单纯的重启集群要更剧烈些

6. 新版本重复测试

在新的7.5.4集群重复前面的的测试观察delete数据后GC情况。初始 51611460条数据，删除后剩余8837条。
9:48 首次检查total\_keys；100164327

10:22 再次检查 total_keys；17446709，34 分钟内 totalkeys 减少了 82717618。

  监控上看GC/compact活动也很频繁。

7. 结论

7.5.4 版本对于大量 delete 版本优化改进还是比较明显，建议升级到较新的版本。