# [Known Issues] Dumpling 备份导致 TiDB OOM

## Key Words

Dumpling, OOM

## Description

采用 Dumpling (v4.0.6) 对 TiDB 集群（v4.0.6）发起备份，TiDB Memory Usage 监控 process 和 Heapuse 持续上涨最终 OOM。

![dumping-tidb-oom](/images/Dumpling/dumping-tidb-oom.png)

## Root Cause

用户使用了定制版本的 TiDB，5.2.4 之前版本的 dumpling 采用 select version() 获取 TiDB 版本，误认为是 MySQL 环境。

导出 MySQL 数据时，是根据统计信息来划分 chunk 的，但是在统计信息不准，或数据倾斜比较严重时，可能会划分非常大的 chunk，引起 TiDB-Server OOM。

但如果是针对 TiDB 导出数据，会根据 region 的维度来划分 chunk，通常各 region 大小比较均衡，引起 OOM 的概率较低，但也要考虑到超大 region 的影响。

## Diagnostic Steps

1. 检查 Dumpling 日志发现以下信息，经过了解得知用户对 TiDB 版本做了定制，导致 dumpling 无法正确识别 TiDB 版本，而是作为 MySQL 进行备份。

    ```golang
    ["detect server type"] [type=MySQL]
    
    ["detect server version"] [version=5.7.25-UbiSQL-v1.0.1]
    ```

    Dumpling 备份 MySQL 时，计算并发时会根据 explain 查到的统计信息的划分各个 chunk 范围，如果统计信息不准确或实际数据分布不均衡，可能会划出范围比较大的 chunk（可以开启 Dumpling debug 日志查看具体 SQL）。
    
2. 导出 TiDB goroutine 信息，发现 100 个持续运行 1小时以上的 copIteratorWorker goroutine，TiDB 集群 tidb_distsql_scan_concurrency 设置为 50，推测是有两个 dump SQL 划分了较大的 chunk。

## Resolution

使用最新版本 Dumpling 备份 TiDB 内存使用正常。 

说明：新版本 Dumpling 使用 select tidb_version() 代替 select version() 获取 TiDB 版本更加准确（[https://github.com/pingcap/dumpling/pull/381](https://github.com/pingcap/dumpling/pull/381)），备份 TiDB 划分 chunk 的维度是 region，通常各个 region 大小比较均衡。

## Workaround

N/A

## Affected Versions

dumpling < v5.2.4