# [FAQ] Dumpling 备份引起 TiDB 延迟上涨

## Key Words

Mydumper, Dumpling, TiDB Duration 上升, delete_skipped

## Description

使用 Mydumper 或者 Dumpling 对集群进行备份，在备份开始时，会造成一个瞬间的延迟上涨。如图所示:

![image.png](/images/Dumpling/dumpling-TiDB-latency-1.png)

## Root Cause

1. Mydumper 备份唤醒了 hibernate region，刚被唤醒的 hibernate region leader 需要续 lease, 续 lease 则需要广播 heartbeat 以及收到大多数响应才完成，在引起 raftstore CPU 使用上升的同时也增加了 raftstore 请求的排队时间上升。

2. 监控 coporcessor-overview -> total RocksDB Perf Statistics 有大量的 delete_skipped-select 的情况(数据已经被删除，但是还没有在 RocksDB compact)。 扫描这么多 key 会导致 coprocessor 请求过长，从而导致其他请求等待。

![image.png](/images/Dumpling/dumpling-TiDB-latency-2.png)

## Diagnostic Steps

1.检查对应时间段 tidb 监控 -> kv duration，发现在mydumper 启动后出现 kv request duration 涨的情况，主要是 cop 请求出现了尖峰。

![image.png](/images/Dumpling/dumpling-TiDB-latency-3.png)

2.检查 tikv 监控，raftstore cpu 在 23:02 分有一个尖峰，心跳消息在此时也有一个尖峰。

![image.png](/images/Dumpling/dumpling-TiDB-latency-4.png)

![image.png](/images/Dumpling/dumpling-TiDB-latency-5.png)

3.检查 coprocessor overview 和 coprocessor details. handle duration 和 wait duration 都有上涨: 

![image.png](/images/Dumpling/dumpling-TiDB-latency-6.png)

delete_skipped-select delete_skipped-index 均有上涨:

![image.png](/images/Dumpling/dumpling-TiDB-latency-7.png)

到此时基本已经得到原因: 

1. Mydumper 备份需要扫描全表，从而导致 hibernate region 被唤醒导致，raftstore 消息增多，处理速度变慢。

2. Mydumper 扫描的数据前期由于做过手动 compaction，导致低层级的数据不容易 compaction 从而堆积大量 tombstone 的数据。

## Resolution

对于静默 region 被唤醒的情况，可能有 GC，全表扫描, 全量备份等情况。目前没有太好的办法避免由于 gc 触发的延迟尖峰。

对于有大量未 compact 的数据，由于手动 compaction 影响过大，只能等待下次的 compaction。 

## Workaround

1. 扩容，避免单个 TiKV 有过多的 region.

2. 找出 tombstone key 过多的数据范围，使用 scatter-range 触发 region 进行调度，从而强制舍弃 tombstone 的key。