背景介绍:
目前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盘进行备份;
八、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备份最佳实践参考
9.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"
- 上述BR配置备份速率预计在: 150MB/s [假设为变量: Z]
- 每个tikv实例max cpu预计会增长: 200%
- 每个tikv实例avg cpu预计会增长: 150%
- 备份压缩率可以参考监控: PD --> Statistics balance --> Size amplification [假设为变量: Y]
- 集群大小可以参考监控: pd ---> current storage size [假设为变量:X]
- 依据以上数据估算BR备份整个集群的耗时公式:
> BR Backup Time = (X/3 * Y) / Z
- 假设备份介质:NAS盘或s3不存在IO瓶颈现象;
- 假设集群PD监控显示大小为: 10TB
- 假设集群PD监控显示Size amplification为: 5
- 此时估算BR备份整个集群的耗时 ≈ ( 10TB/3 ) * 5 * 1024 * 1024 / 150 = 32h
- BR备份会阻止GC savepoint推进32h;
9.2 中型集群 [ 10TB < DB size <= 30TB ]
- 备份介质: NAS盘或s3存储
- backup.num-threads : 4
- concurrency : 32
- 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 32 \ 【这个控制32个并发】
--compression "zstd" \ 【这里可以自行调整为lz4】
--checksum=false \ 【checksum关闭,避免导致cpu突增】
--storage "local:///xxxx/brbackup/xxxx" \
--log-file /xxxx/xxxx/br_backupfull_xxxx.log \
--log-level "info"
- 这个配置大概备份速率在: 500MB/s [假设为变量: Z]
- 每个tikv实例峰值cpu预计会增长: 400%
- 每个tikv实例均值cpu预计会增长: 300%
- 备份压缩率可以参考监控: PD --> Statistics balance --> Size amplification [假设为变量: Y]
- 集群大小可以参考监控: pd ---> current storage size [假设为变量:X]
- 依据以上数据估算BR备份整个集群的耗时公式:
- > BR Backup Time = (X/3 * Y) / Z
- 假设备份介质:NAS盘或s3不存在IO瓶颈现象;
- 假设集群PD监控显示大小为: 30TB
- 假设集群PD监控显示Size amplification为: 5
- 此时估算BR备份整个集群的耗时 ≈ ( 30TB/3 ) * 5 * 1024 * 1024 / 500 = 29h
- BR备份会阻止GC savepoint推进29h;
9.3 大型集群 [ DB size > 30TB ]
- 备份介质: NAS盘或s3存储
- backup.num-threads : 8
- concurrency : 128
- compression: lz4或zstd
- 备份命令参考:
mysql > set config tikv `backup.num_threads`=8; 【这个分配每个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 /xxxx/xxxx/br_backupfull_xxxx.log \
--log-level "info"
- 这个配置大概备份速率在: 800MB/s [假设为变量: Z]
- 每个tikv实例峰值cpu预计会增长: 800%
- 每个tikv实例均值cpu预计会增长: 800%
- 备份压缩率可以参考监控: PD --> Statistics balance --> Size amplification [假设为变量: Y]
- 集群大小可以参考监控: pd ---> current storage size [假设为变量:X]
- 依据以上数据估算BR备份整个集群的耗时公式:
- > BR Backup Time = (X/3 * Y) / Z
- 假设备份介质:NAS盘或s3不存在IO瓶颈现象;
- 假设某个集群PD监控显示大小为: 60TB
- 假设某个集群PD监控显示Size amplification为: 5
- 此时估算BR备份整个集群的耗时 ≈ ( 60TB/3 ) * 5 * 1024 * 1024 / 800 = 36h
- BR备份会阻止GC savepoint推进36h;
十、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实例的流量,不建议用此参数控制资源消耗;
2024.6.12