专栏 - TiDB br备份参数影响分析与最佳实践参考

背景介绍：

目前 TiDB 物理备份工具主要使用BR来实现，br备份具有较多参数配置，不同参数配置下备份效率与影响可能存在差异，本篇文章的主要目的：

依据详尽的观测数据来评估各类BR备份参数的影响；
依据详尽的观测数据来评估备份介质、表数量对BR备份的影响；
依据详尽的观测数据来评估BR备份对于在线业务QPS与latency的影响；
依据详尽的观测数据来评估BR备份对tikv cpu的影响；
依据相近的观察数据来预估BR备份任务的耗时公式、对GC阻塞时长的影响；
依据上述：BR各参数影响分析的结论，以及本身BR备份可能产生的影响，评估得出BR备份的最佳实践建议；

一、compression配置影响分析

数据分析：

lz4压缩方式，对tikv侧cpu消耗最低，备份速率适中，备份压缩率最低;
snappy压缩方式，对tikv侧cpu消耗适中，备份速率最快，备份压缩率适中；
zstd压缩方式，对tikv侧cpu消耗最高，备份速率最慢，备份压缩率最高;

建议：

如果追求更小的备份空间使用，建议选择zstd备份压缩方式；(默认zstd方式)
如果追求更快的备份速度，建议选择snappy备份压缩方式；
如果追求更小的业务影响，建议选择lz4备份压缩方式；

二、compression-level配置影响分析

ZSTD压缩方式下不同compression-level表现

snappy压缩方式下不同compression-level表现

lz4压缩方式下不同compression-level表现

数据分析：

lz4压缩方式下，调整不同compression-level，备份压缩率与备份速率几乎无影响；
snappy压缩方式下，调整不同compression-level，备份压缩率与备份速率几乎无影响；
zstd压缩方式下，compression-level =1时，备份速度最快;
zstd压缩方式下，compression-level = 16时，备份压缩率最高;

建议：

lz4与snappy压缩算法，不建议人为去调整compression-level，保持默认即可；
zstd压缩方式下，如果追求更小的备份空间使用，可以调整compression-level = 16;
zstd压缩方式下，如果追求更快的备份速度，可以调整compression-level = 1；
zstd压缩方式下，如果追求备份速度与备份空间使用的平衡，compression-level保持默认3即可；

compression-level参数详解：

compression-level参数控制BR备份压缩算法使用的压缩等级；
compression-level参数目前支持的等级范围: lz4是 1 ~ 12 , zstd是 -7 ~ 22;
compression-level参数配置为0，不代表关闭压缩，配置0目前是无效配置;

三、concurrency参数配置影响分析

数据分析：

concurrency参数配置越大，备份速度越快；
concurrency参数配置越大，tikv backup thread cpu (AVG)越高;
concurrency参数配置越大，tikv backup thread cpu (AVG) 值越趋近于tikv backup thread cpu (MAX)值;

建议：

如果追求更小的业务影响， concurrency参数建议默认4即可；
如果追求更快的备份速度， concurrency参数建议调大，参数值范围控制在4~256区间；

concurrency参数详解：

concurrency参数配置为8，表示BR会同时启动8个表的备份任务；
concurrency参数配置合理与否，与备份任务涉及的表个数相关，2者数值越相近，备份效率越高，相应的tikv侧资源消耗越高；

四、ratelimit配置影响分析

数据分析：

ratelimit参数配置大于64，对备份任务无明显影响；
ratelimit参数在128，256，512时，备份耗时、备份速度基本持平；
当concurrency被自动调整为1后，ratelimit继续调大，对于备份速度以及流量控制无实际意义；

建议：

不建议通过ratelimit来控制BR备份的效率，通过backup.num_threads 与 concurrency参数进行资源控制更为有效；

ratelimit参数详解：

ratelimit参数控制：备份文件存储到外部存储的速度；
当启用ratelimit配置的情况下，备份任务concurrency自动调节为1；
ratelimit参数控制的是：单个tikv实例的备份速率，并不是整个集群的备份速率；

五、backup.num-threads配置影响分析

数据分析：

backup.num-threads参数配置越大，备份速度越快，tikv cpu消耗越高；
backup.num-threads参数配置越小，备份速度越慢，tikv cpu消耗越低;

建议：

如果追求更快的备份速度，建议调大backup.num-threads参数，但通常不建议超过8;
如果追求更小的业务影响，更少的资源使用，建议调小backup.num-threads参数，以控制tikv侧cpu资源max位；
如果追求更小的业务影响，更少的资源使用，建议调小backup.num-threads参数 + 调小concurrency参数，以控制tikv侧cpu max位与avg位；

backup.num_threads参数详解：

backup.num-threads参数是tikv层config配置，可以edit-config进行修改reload，也可以set config tikv backup.num-threads=8 在线调整生效；
backup.num-threads参数控制的是tikv backup thread cpu的max位，也就是最大使用量，配置为2，代表：tikv backup thread cpu max值最大到200%;

六、表数量影响分析

数据分析：

图中10，100， 1000，分别代表集群中存在10个表、 100个表、1000个表的3种情况，总数据量是相同的；
表个数越多，备份速度越慢，tikv cpu消耗越低，备份耗时越长；
表个数越小，备份速度越快，tikv cpu消耗越高，备份耗时越短；

建议：

如果集群中存在大量的table对象，可以相应调大concurrency参数来提升BR备份的速度；

七、br备份对Online business影响分析

65%基础负载下，BR备份对Online business影响分析 (NVME)

65%基础负载下，BR备份对Online business影响分析 (NAS)

25%基础负载下，BR备份对Online business影响分析 (NVME)

25%基础负载下，BR备份对Online business影响分析 (NAS)

数据分析：

65%基础负载是指：没有启动BR备份，online business运行期间tikv主机层面cpu使用率是65%；
25%基础负载是指：没有启动BR备份，online business运行期间tikv主机层面cpu使用率是25%；
65%基础负载的online business，使用NVME盘运行BR备份期间，QPS衰减范围: 10%~25%;
65%基础负载的online business，使用NVME盘运行BR备份期间，p95 latency上涨范围: 8.5%~33.5%;
65%基础负载的online business，使用NAS盘运行BR备份期间，QPS衰减范围: 10.5%~23.5%;
65%基础负载的online business，使用NAS盘运行BR备份期间，p95 latency上涨范围: 10.5%~30%;
25%基础负载的online business，使用NVME盘运行BR备份期间，QPS衰减范围: 7%~15.5%;
25%基础负载的online business，使用NVME盘运行BR备份期间，p95 latency上涨范围: 15.5%~44.5%;
25%基础负载的online business，使用NAS盘运行BR备份期间，QPS衰减范围: 6.8%~11.8%;
25%基础负载的online business，使用NAS盘运行BR备份期间，p95 latency上涨范围: 10.4%~21%;
采用zstd压缩算法进行BR备份，QPS衰减比例会稍微高于lz4方式 , 大概高出: 4%；
采用NVME盘进行BR备份，QPS衰减比例会高于NAS盘备份，大概高出: 3%;

建议：

如果追求更小的online business影响，建议采用lz4压缩算法进行备份；
如果追求更小的online business影响，建议采用NAS盘或S3进行备份；

八、br备份对tikv cpu的影响分析

br备份数据期间对tikv cpu的影响分析

br checksum阶段对tikv cpu的影响分析

数据分析：

backup.num-threads参数配置为4, concurrency参数范围: 4~16, BR备份期间total tikv cpu (AVG)上涨范围: 640%~1100%;
backup.num-threads参数配置为4, concurrency参数范围: 4~16 , BR备份期间total tikv cpu (MAX)上涨范围: 1395%~1899%;
backup.num-threads参数配置为4，BR 执行checksum阶段，单个 tikv cpu (MAX) 上涨: 1200%;
上述第3点：单个 tikv cpu (MAX) 上涨: 1200%，这个1200%受到readpool.unified.max-thread-count配置限制，理论上可以更高；

建议：

如果追求更小的online business影响，建议合理控制backup.num-threads参数与concurrency参数；
如果追求更小的online business影响，建议BR备份期间关闭checksum动作，通过--checksum=false配置进行关闭；

九、影响br备份的核心变量及估算公式

核心影响变量：

集群大小可以参考监控: pd ---> current storage size [变量：X]

集群中单个主机上的tikv实例个数: [变量：Z]

集群中主机层面Vcore数量: [变量: V]

集群中总的tikv机器数量： [变量: N]

BR备份的核心控制参数: backup.num_threads : [变量: T]

估算BR备份的速率公式(落盘速率)：

> BR Backup rate = 6 MB/s * T * Z * N

估算BR备份的耗时公式：

> BR Backup Time = ( X / 3) / {BR Backup rate}

估算BR备份期间单个tikv主机cpu负载公式(MAX值):

> TIKV CPU Usage % = (T * Z ) / V * 100%

十、br备份最佳实践参考

10.1 小型集群 [ DB size <= 10TB ]

备份介质: NAS盘或s3存储
backup.num-threads : 2
concurrency : 16
compression: lz4或zstd
备份命令参考：

mysql >  set config tikv `backup.num_threads`=2;    【这个分配每个tikv节点最大Backup Worker CPU数量为2】

br backup full \
--pd "172.16.201.xx:2359" \
--concurrency 16 \                                 【这个控制16个并发】
--compression "zstd" \                             【这里可以自行调整为lz4】
--checksum=false \                                 【checksum关闭，避免导致cpu突增】
--storage "local:///xxxx/brbackup/xxxx" \
--log-file /xxx/xxx/br_backupfull_xxxx.log \
--log-level "info"

假设备份介质:NAS盘或s3不存在IO瓶颈现象;
假设集群PD监控显示大小为：10TB
假设集群tikv机器数量： 3
假设每个机器上启动tikv实例： 4
假设每个机器Vcore数量: 48
备份配置num-threads: 2

依据以上信息估算BR备份的速率 ≈ 6MB/S * 2 * 4 * 3 ≈ 144MB/s

> 估算公式： BR Backup rate = 6 MB/S * T * Z * N

依据以上信息估算BR备份整个集群的耗时 ≈ ( 10TB/3 ) * 1024 * 1024 / (144MB/s ) ≈ 6.73h

> 估算公式： > BR Backup Time = ( X / 3) / {BR Backup rate}

依据以上信息估算BR备份期间的tikv主机cpu负载 (MAX值) ≈ (2 * 4) / 48 ≈ 16.7%

> 估算公式：TIKV CPU Usage % = (T * Z ) / V

10.2 中型集群 [ 10TB < DB size <= 30TB ]

备份介质: NAS盘或s3存储
backup.num-threads : 4
concurrency : 64
compression: lz4或zstd
备份命令参考：

mysql >  set config tikv `backup.num_threads`=4;    【这个分配每个tikv节点最大Backup Worker CPU数量为4】

br backup full \
--pd "172.16.201.xx:2359" \
--concurrency 64 \                                 【这个控制64个并发】
--compression "zstd" \                             【这里可以自行调整为lz4】
--checksum=false \                                 【checksum关闭，避免导致cpu突增】
--storage "local:///xxxx/brbackup/xxxx" \
--log-file /xxx/xxx/br_backupfull_xxxx.log \
--log-level "info"

假设备份介质:NAS盘或s3不存在IO瓶颈现象;
假设集群PD监控显示大小为： 30TB
假设集群tikv机器数量： 6
假设每个机器上启动tikv实例： 4
假设每个机器Vcore数量: 48
备份配置num-threads: 4

依据以上信息估算BR备份的速率 ≈ 6MB/S * 4 * 4 * 6 ≈ 576MB/s

> 估算公式： BR Backup rate = 6 MB/S * T * Z * N

依据以上信息估算BR备份整个集群的耗时 ≈ ( 30TB/3 ) * 1024 * 1024 / (576MB/s ) ≈ 5h

> 估算公式： > BR Backup Time = ( X / 3) / {BR Backup rate}

依据以上信息估算BR备份期间的tikv主机cpu负载 (MAX值) ≈ (4 * 4) / 48 ≈ 33.3%

> 估算公式：TIKV CPU Usage % = (T * Z ) / V

10.3 大型集群 [ DB size > 30TB ]

备份介质: NAS盘或s3存储
backup.num-threads : 4
concurrency : 128
compression: lz4或zstd
备份命令参考：

mysql >  set config tikv `backup.num_threads`=4;    【这个分配每个tikv节点最大Backup Worker CPU数量为4】

br backup full \
--pd "172.16.201.xx:2359" \
--concurrency 128 \                                 【这个控制128个并发】
--compression "zstd" \                             【这里可以自行调整为lz4】
--checksum=false \                                 【checksum关闭，避免导致cpu突增】
--storage "local:///xxxx/brbackup/xxxx" \
--log-file /xxx/xxx/br_backupfull_xxxx.log \
--log-level "info"

假设备份介质:NAS盘或s3不存在IO瓶颈现象;
假设集群PD监控显示大小为： 60TB
假设集群tikv机器数量： 6
假设每个机器上启动tikv实例： 4
假设每个机器Vcore数量: 96
备份配置num-threads: 4

依据以上信息估算BR备份的速率 ≈ 6MB/S * 4 * 4 * 6 ≈ 576MB/s

> 估算公式： BR Backup rate = 6 MB/S * T * Z * N

依据以上信息估算BR备份整个集群的耗时 ≈ ( 60TB/3 ) * 1024 * 1024 / (576MB/s ) ≈ 10h

> 估算公式： > BR Backup Time = ( X / 3) / {BR Backup rate}

依据以上信息估算BR备份期间的tikv主机cpu负载 (MAX值) ≈ (4 * 4) / 96 ≈ 16.7%

> 估算公式：TIKV CPU Usage % = (T * Z ) / V

十一、br备份注意项summary

BR备份任务配置中, backup.num_threads参数控制在8以内范围，此参数越大，BR备份期间backup max cpu使用率越高;

BR备份任务配置中, concurrency参数控制在256以内，此参数越大，BR备份期间backup thread cpu(avg)使用率越高;

BR备份运行期间，会阻止集群的gc safepoint推进，直到BR备份完成自动释放，需要与业务评估更多Mvcc所带来的影响;

BR备份运行期间，不同的参数配置下，online business受到影响表现不一样，详情参阅第七章节；

BR备份任务配置中，需要关闭checksum，避免触发tikv cpu突增现象，影响在线业务运行；

BR备份任务配置中，ZSTD压缩算法消耗tikv cpu最高，snappy其次，lz4最低；

BR备份任务配置中，ratelimit参数控制的是单个tikv实例的流量，不建议用此参数控制资源消耗;

十二、其他备注说明

br备份速率会受到本身集群环境信息的影响，比如：集群大小、集群拓扑、表数量、数据压缩率，NAS或S3性能配置、tikv主机cpu使用率等；
第十章主要目的是得出：估算公式模型以及在这个模型之上可能的各类耗时及资源占用情况，真实的表现可能因上述各类因素的影响，而对估算结果产生少量差异现象，本文无法穷举所有可能性；
备份速率 <---> 资源消耗之间存在正向相关性，而备份速率 <---> GC safepoint阻塞时长之间存在反向相关性，在制定br备份策略期间需要考虑到这2个关系，避免对online business产生明显影响；
本文内容及结论基于版本信息， TiDB 集群版本：v6.5.3， br版本: v6.5.3;

Thanks

2024.6.13