# [Know Issue]关于 TiKV 在 v4.x 版本 TiKV_Approximate_region_size 误报定位

## Key Words

Split region,TiKV_Approximate_region_size,Compaction Filter

## Description

收到大量的 TiKV_Approximate_region_size 的告警，但是查询 TiKV 日志发现实际并没有触发 Split Region 操作。

```markdown
# Approximate size 发现 Region 10 的大小已经达到 584469274 bytes 超过阈值 150994944 bytes

[2022/11/28 18:10:16.032 +03:00] [INFO] [size.rs: 172] ["approximate size over threshold, need to do split check"] 
[threshold=150994944] [size=584469274] [region_id=10]

# Split check 进行 Split 前再次检查 Region 实际大小为 0，所以不会触发 Region split

[2022/11/26 18:10:16.646 +08:00] [INFO] [split_check.rs:277) ["update approximate size and keys with accurate value"] 
[keys=0] [size=0] [region_id=10]
```

初步判断是因为 Approximate region size 检测 Region size 错误，将空 Region size 预估过大。

- Grafana 监控 TiKV-details 面板 -> Cluster -> Approximate Region Size 看到 Region Size 99%，95% 达到 2 GiB 左右，超过 Split Region Size 默认 96 MiB
 
## Root Cause

1. 在 V4 版本没有开启 `compaction filter`, 可以通过看 TiKV-details -> gc -> auto gc progress 如果有数据说明 Compaction Fliter 没有开。

2. `approximate_size` 是一个估算值，虽然存在误差，但是是包含了 `Rocksdb tombstone` 的数据的。`split-checker` 在收到 `Approximate_size` 过大报警后，会全局再扫一下看看真实的数据量，这边包含了 `TiKV` 事务里面的 `MVCC` 信息，但是不包含 `Rocksdb` 里的 tombstone 数据量。所以如果 `approximate_size`
很大但通过 TiKV 日志查看 Region 实际的 size 是 0 的话，可能是 `Rocksdb` 里面扫到了很多 tombstone。

综合以上两点， `compaction filter` 没有开，那么数据走普通的 GC 也就是一条一条调用 Rocksdb 来删除旧副本，GC 完后，Compaction 没开始这个中间，就有可能出现很多 tombstone 的 key.  这个可以通过 [Region properties](https://docs.pingcap.com/zh/tidb/dev/tikv-control#%E6%89%93%E5%8D%B0-region-%E7%9A%84-properties-%E4%BF%A1%E6%81%AF) 查看一下这个 region 的 `mvcc-properties`, 确定是否存在 Rocksdb 的 tombstone。

## Diagnostic Steps

1. 根据 TiKV 日志搜索关键字 `approximate size over threshold` 确认对应的 Region id 和 Store id 情况；
2. 通过 PD Control 查询对应的 Region id 的数据信息包括 Table、scheme 信息，了解该表是否存在大量的 Delete 或者 Update 操作导致 Tombstone key 增加；
3. 查询 `Region mvcc-properties` 查询对应的 Region 是否存在大量的副本信息，注意区分于 `Region size` 查询结果；截图中是通过 TiKV Control 查询到 Region size 大小。`tikv-ctl size` 的做法跟 `split-keys` 计算 `real size` 做法是一致。但类似的报警可以看一下 `mvcc properties`, 里面有详细的 rocksdb 有多少删除的信息。

    ```shell
    # TiKV 日志中观察到 approximate size 超过阈值的 Region 实际大小和 Key 为 0.
    [2022/11/29 16:41:51.206 +08:001 [INFO [size.rs:1721 ["approximate size over threshold, need to do split check"] [threshold=150994944] [size=156183608] [region_id-9033153]
    [2022/11/29 16:41:51.390 +08:00] [INFO] [split_check.rs:277] ["update approximate size and keys with accurate value"] [keys=0] [size=0] [region_id=9033153]
    
    # 通过 TiKV Control 的 Region size 查询命令可以查询到 Region 和实际的大小，和日志中 Split_check 结果匹配。
    ./.tiup/components/ctl/v4.0.14/tikv-ctl--host {tikv-ip}:{tikv-port} size -r 9033153
    region id: 9033153
    cf default region size: 0 B 
    cf write region size: 0 B 
    cf lock region size: 0 B
    ```

4. 类似场景中会在 `approximate size over threshold, need to do split check` 以后，会继续有一轮 Split Region 和 Merge region 操作，所以在 v5 版本以后开启 Compaction Filter 可以加快 Tombstone key 的处理，进而会降低 `approximate size over threshold, need to do split check` 的报错情况。
   
   ```markdown
   [2022/11/28 02:38:59.769 +08:00] [INFO] [size.rs: 1721]
   ["approximate size over threshold, need to do split check"] [threshold=150994944] [size=13043222351] [region_id=20]
   [2022/11/28 02:39:01.160 +08:00] [INFO Isplit_check.S:2771 ["update approximate size and keys with accurate value"] [keys=0] [size=0] [region_id=20]
   [2022/11/28 02:39:01.160 +08:00] [WARN] [mod. rs: 89]
   ["handle task [split check worker] Split Check Task for 9016250, auto_split: true"] [takes=13921]
   [2022/11/28 02:41:36.213 +08:00] [INFO] [pd.rs:835] ["try to merge"| merge-"target { id: 9016254 start_key: 748000000000005CFFFA5F728000000040FFA35C9D0000000000FA end_key: 748000000000005CFFFA5F728000000040FFA5B906006...
   ```

5. 可以通过  TiKV-details -> gc -> auto gc progress  是否有数据，有则说明 Compaction Fliter 没有开启。

## Resolution

尽快升级到 TiDB 最新版本或者 V5 的问题定版本，并开启 Compaction Filter，并发处理 RocksDB 中的 Tombstone key，进而减少对  Approximate Size 估算的影响。

## Affected Versions

N/A