写点什么

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

  • 2024-06-14
    北京
  • 本文字数:5281 字

    阅读完需:约 17 分钟

作者: Chad 原文来源:https://tidb.net/blog/801ebc6b

背景介绍:

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


  • 依据详尽的观测数据来评估各类 BR 备份参数的影响;

  • 依据详尽的观测数据来评估备份介质、表数量对 BR 备份的影响;

  • 依据详尽的观测数据来评估 BR 备份对于在线业务 QPS 与 latency 的影响;

  • 依据详尽的观测数据来评估 BR 备份对 tikv cpu 的影响;

  • 依据相近的观察数据来预估 BR 备份任务的耗时公式、对 GC 阻塞时长的影响;

  • 依据上述:BR 各参数影响分析的结论,以及本身 BR 备份可能产生的影响,评估得出 BR 备份的最佳实践建议;

一、compression 配置影响分析


  • 数据分析:


  1. lz4 压缩方式,对 tikv 侧 cpu 消耗最低,备份速率适中,备份压缩率最低 ;

  2. snappy 压缩方式,对 tikv 侧 cpu 消耗适中,备份速率最快,备份压缩率适中;

  3. zstd 压缩方式,对 tikv 侧 cpu 消耗最高,备份速率最慢,备份压缩率最高 ;


  • 建议:


  1. 如果追求更小的备份空间使用,建议选择 zstd 备份压缩方式;(默认 zstd 方式)

  2. 如果追求更快的备份速度,建议选择 snappy 备份压缩方式;

  3. 如果追求更小的业务影响,建议选择 lz4 备份压缩方式;

二、compression-level 配置影响分析

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



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



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



  • 数据分析:


  1. lz4 压缩方式下,调整不同 compression-level,备份压缩率与备份速率几乎无影响;

  2. snappy 压缩方式下,调整不同 compression-level,备份压缩率与备份速率几乎无影响;

  3. zstd 压缩方式下,compression-level =1 时,备份速度最快 ;

  4. zstd 压缩方式下,compression-level = 16 时,备份压缩率最高 ;


  • 建议:


  1. lz4 与 snappy 压缩算法,不建议人为去调整 compression-level,保持默认即可;

  2. zstd 压缩方式下,如果追求更小的备份空间使用,可以调整 compression-level = 16;

  3. zstd 压缩方式下,如果追求更快的备份速度,可以调整 compression-level = 1;

  4. zstd 压缩方式下,如果追求备份速度与备份空间使用的平衡,compression-level 保持默认 3 即可;


  • compression-level 参数详解:


  1. compression-level 参数控制 BR 备份压缩算法使用的压缩等级;

  2. compression-level 参数目前支持的等级范围: lz4 是 1 ~ 12 , zstd 是 -7 ~ 22;

  3. compression-level 参数配置为 0,不代表关闭压缩,配置 0 目前是无效配置 ;

三、concurrency 参数配置影响分析


  • 数据分析:


  1. concurrency 参数配置越大,备份速度越快;

  2. concurrency 参数配置越大,tikv backup thread cpu (AVG) 越高 ;

  3. concurrency 参数配置越大,tikv backup thread cpu (AVG) 值越趋近于 tikv backup thread cpu (MAX) 值 ;


  • 建议:


  1. 如果追求更小的业务影响, concurrency 参数建议默认 4 即可;

  2. 如果追求更快的备份速度, concurrency 参数建议调大,参数值范围控制在 4~256 区间;


  • concurrency 参数详解:


  1. concurrency 参数配置为 8,表示 BR 会同时启动 8 个表的备份任务;

  2. concurrency 参数配置合理与否,与备份任务涉及的表个数相关,2 者数值越相近,备份效率越高,相应的 tikv 侧资源消耗越高;

四、ratelimit 配置影响分析


  • 数据分析:


  1. ratelimit 参数配置大于 64,对备份任务无明显影响;

  2. ratelimit 参数在 128,256,512 时,备份耗时、备份速度基本持平;

  3. 当 concurrency 被自动调整为 1 后,ratelimit 继续调大,对于备份速度以及流量控制无实际意义;


  • 建议:


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


  • ratelimit 参数详解:


  1. ratelimit 参数控制:备份文件存储到外部存储的速度;

  2. 当启用 ratelimit 配置的情况下,备份任务 concurrency 自动调节为 1*;*

  3. ratelimit 参数控制的是:单个 tikv 实例的备份速率,并不是整个集群的备份速率;

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


  • 数据分析:


  1. backup.num-threads 参数配置越大,备份速度越快,tikv cpu 消耗越高;

  2. backup.num-threads 参数配置越小,备份速度越慢,tikv cpu 消耗越低 ;


  • 建议:


  1. 如果追求更快的备份速度,建议调大 backup.num-threads 参数,但通常不建议超过 8;

  2. 如果追求更小的业务影响,更少的资源使用,建议调小 backup.num-threads 参数,以控制 tikv 侧 cpu 资源 max 位;

  3. 如果追求更小的业务影响,更少的资源使用,建议调小 backup.num-threads 参数 + 调小 concurrency 参数,以控制 tikv 侧 cpu max 位与 avg 位;


  • backup.num_threads 参数详解:


  1. backup.num-threads 参数是 tikv 层 config 配置,可以 edit-config 进行修改 reload,也可以 set config tikv backup.num-threads=8 在线调整生效;

  2. backup.num-threads 参数控制的是 tikv backup thread cpu 的 max 位,也就是最大使用量,配置为 2,代表:tikv backup thread cpu max 值最大到 200%;

六、表数量影响分析


  • 数据分析:


  1. 图中 10,100, 1000,分别代表集群中存在 10 个表、 100 个表、1000 个表的 3 种情况,总数据量是相同的;

  2. 表个数越多,备份速度越慢,tikv cpu 消耗越低,备份耗时越长;

  3. 表个数越小,备份速度越快,tikv cpu 消耗越高,备份耗时越短;


  • 建议:


  1. 如果集群中存在大量的 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)



  • 数据分析:


  1. 65% 基础负载是指:没有启动 BR 备份,online business 运行期间 tikv 主机层面 cpu 使用率是 65%;

  2. 25% 基础负载是指:没有启动 BR 备份,online business 运行期间 tikv 主机层面 cpu 使用率是 25%;

  3. 65% 基础负载的 online business,使用 NVME 盘运行 BR 备份期间,QPS 衰减范围: 10%~25%;

  4. 65% 基础负载的 online business,使用 NVME 盘运行 BR 备份期间,p95 latency 上涨范围: 8.5%~33.5%;

  5. 65% 基础负载的 online business,使用 NAS 盘运行 BR 备份期间,QPS 衰减范围: 10.5%~23.5%;

  6. 65% 基础负载的 online business,使用 NAS 盘运行 BR 备份期间,p95 latency 上涨范围: 10.5%~30%;

  7. 25% 基础负载的 online business,使用 NVME 盘运行 BR 备份期间,QPS 衰减范围: 7%~15.5%;

  8. 25% 基础负载的 online business,使用 NVME 盘运行 BR 备份期间,p95 latency 上涨范围: 15.5%~44.5%;

  9. 25% 基础负载的 online business,使用 NAS 盘运行 BR 备份期间,QPS 衰减范围: 6.8%~11.8%;

  10. 25% 基础负载的 online business,使用 NAS 盘运行 BR 备份期间,p95 latency 上涨范围: 10.4%~21%;

  11. 采用 zstd 压缩算法进行 BR 备份,QPS 衰减比例会稍微高于 lz4 方式 , 大概高出: 4%;

  12. 采用 NVME 盘进行 BR 备份,QPS 衰减比例会高于 NAS 盘备份,大概高出: 3%;


  • 建议:


  1. 如果追求更小的 online business 影响,建议采用 lz4 压缩算法进行备份;

  2. 如果追求更小的 online business 影响,建议采用 NAS 盘或 S3 进行备份;

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

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



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



  • 数据分析:


  1. backup.num-threads 参数配置为 4, concurrency 参数范围: 4~16, BR 备份期间 total tikv cpu (AVG) 上涨范围: 640%~1100%;

  2. backup.num-threads 参数配置为 4, concurrency 参数范围: 4~16 , BR 备份期间 total tikv cpu (MAX) 上涨范围: 1395%~1899%;

  3. backup.num-threads 参数配置为 4,BR 执行 checksum 阶段,单个 tikv cpu (MAX) 上涨: 1200%;

  4. 上述第 3 点 :单个 tikv cpu (MAX) 上涨: 1200%,这个 1200% 受到 readpool.unified.max-thread-count 配置限制,理论上可以更高;


  • 建议:


  1. 如果追求更小的 online business 影响,建议合理控制 backup.num-threads 参数与 concurrency 参数;

  2. 如果追求更小的 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

  • 备份命令参考:

  • 假设备份介质:NAS 盘或 s3 不存在 IO 瓶颈现象 ;

  • 假设集群 PD 监控显示大小为:10TB

  • 假设集群 tikv 机器数量: 3

  • 假设每个机器上启动 tikv 实例: 4

  • 假设每个机器 Vcore 数量: 48

  • 备份配置 num-threads: 2


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

  • 依据以上信息估算 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

  • 备份命令参考:

  • 假设备份介质:NAS 盘或 s3 不存在 IO 瓶颈现象 ;

  • 假设集群 PD 监控显示大小为: 30TB

  • 假设集群 tikv 机器数量: 6

  • 假设每个机器上启动 tikv 实例: 4

  • 假设每个机器 Vcore 数量: 48

  • 备份配置 num-threads: 4


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

  • *** 依据以上信息估算 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

  • 备份命令参考:

  • 假设备份介质:NAS 盘或 s3 不存在 IO 瓶颈现象 ;

  • 假设集群 PD 监控显示大小为:*** 60TB***

  • 假设集群 tikv 机器数量: 6

  • 假设每个机器上启动 tikv 实例: 4

  • 假设每个机器 Vcore 数量: 96

  • 备份配置 num-threads: 4


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

  • *** 依据以上信息估算 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


发布于: 刚刚阅读数: 2
用户头像

TiDB 社区官网:https://tidb.net/ 2021-12-15 加入

TiDB 社区干货传送门是由 TiDB 社区中布道师组委会自发组织的 TiDB 社区优质内容对外宣布的栏目,旨在加深 TiDBer 之间的交流和学习。一起构建有爱、互助、共创共建的 TiDB 社区 https://tidb.net/

评论

发布
暂无评论
TiDB br备份参数影响分析与最佳实践参考_备份 & 恢复_TiDB 社区干货传送门_InfoQ写作社区