海山数据库(He3DB)技术分享:海山MySQL备份redo被覆盖问题分析

本文主要梳理介绍云MYSQL客户端经常发生因redo覆盖导致备份失败原理逻辑。

一. 问题背景

在生产环境中,杭研部分实例备份失败问题,如下图所示:

在这里插入图片描述

排查备份日志,发现如下报错:

在这里插入图片描述

报错日志分析:

如下图xtrabackup备份原理图所示,xtrabackup备份期间会通过2个线程实现一边拷贝redolog,一边拷贝ibd文件,在此期间如果xtrabackup的redolog拷贝速度低于MySQL生成redolog的速率,两者差距会越拉越大,当redolog顺序写满后会从头开始覆盖写入,这时候就会导致xtrabackup再次拷贝redolog时发现对应的redolog已经丢失,于是抛出该错误。

xtrabackup备份原理图:

在这里插入图片描述

结合杭研业务和现网本身,罗列以下几点主要问题原因:

  1. 杭研本身数据量较大,备份时间较长。

  2. 杭研全天24H都会持续有数据写入,并没有所谓的业务低谷期。

  3. 现网MySQL的redolog默认大小为2G,日志容量比较小。

  4. 现网备份是直接备份到S3上,并不会在本地落盘,因此备份效率会折损。

二. redo写入监控

为了排查上述问题,首先需要监控MySQL的redo写入速率,这里通过监控MySQL中的Innodb_os_log_written状态值来实现。
Innodb_os_log_written:The number of bytes written to the InnoDB redo log files.

在这里插入图片描述

通过Innodb_os_log_written状态值,两次相减除以时间,从而获取该时间段内MySQL的平均redo写入速率。

三. 模拟S3备份失败

通过模拟不同redo写入速率情况下,S3备份失败的时间长短,从而总结出一定规律,为后续调整redolog大小给出一定的数据支撑。

测试场景说明

  1. 测试实例规格16c128G,数据量470G,100张表,单表4.7G。

  2. 通过设置不同的sysbench并发线程数,模拟出不同redo写入速率。

  3. 通过备份失败得到该redo写入压力下,xtrabackup拷贝redo的速率。(为什么不通过备份成功来计算redo拷贝速率:因为备份时长会随着数据量而改变,因此用备份时间内产生的redo大小除以备份时长不太精确,而用备份失败来计算则可以得到一个更加临界,也更具有参考意义的redo拷贝速率)

测试命令:

#通过sysbench模拟不同redo写入速率

nohup sysbench --db-driver=mysql --mysql-host=xxx --mysql-port=3306 --mysql-user=test \

--mysql-password='xxxx' --mysql-db=test --table-size=20000000 --tables=100 \

--report-interval=1 --db-ps-mode=disable --time=3600 --threads=4  oltp_write_only run &

#手动执行S3备份命令

xtrabackup --defaults-file=/etc/mysql/my.cnf --user=root --password=${MYSQL_ROOT_PASSWORD} --stream=xbstream \

--parallel=4 --compress  --backup --target-dir=./ | s3cmd --no-ssl --access_key=xxxx --secret_key=xxxxx  \

--host=xxx --host-bucket= put - s3://xxx/full.tar

测试结果

通过模拟不同redo写入速率的情况下,备份报错的时长,绘制了这张表格:

在这里插入图片描述

测试总结

根据上述表格,大概可以总结出以下结论:

  1. redo写入速率越快,备份报错时间越短,我们通过获取备份时间内的redo写入大小除以备份报错时长得到redo写入速率,再根据redolog的总大小除以备份报错时长得到redo拷贝速率,两者相减得到偏差速率(即每秒未完成拷贝的redo大小)。

  2. 通过计算redo写入速率和偏差速率的比率,得到1个相对平均的比率值约等于0.56,即redo写入速率 * 0.56 ≈ 偏差速率。

  3. 另外同样测试了S3备份的平均备份速率,大约为100M/s,例如100G的数据量大约需要100*1024/100 ≈ 1024s ≈ 17min

  4. 最后我们得到了这样1个公式,redo总大小 ≥ 偏差速率 * 备份时长,这样才有可能不会出现备份时redo被覆盖的报错。

针对杭研的实例,下述列举了对应的数据情况:

在这里插入图片描述

四.调整redo大小后验证

对杭研重资源池32个实例统一调整redolog大小为16G,如下图所示:

在这里插入图片描述

经过一周的观察,原本备份会因为redolog偏小而一直引发redo被覆盖导致备份失败,后续增大redolog后,备份成功!!!

在这里插入图片描述

五. 现网redo默认大小建议

通过此次测试,认为现网redo默认2G的大小不太合适,建议增大redo 的默认大小,并且会随着实例的存储规格而进一步提高,下面给出建议方案:

在这里插入图片描述

附录:

实时监控Innodb_os_log_written写入速率脚本:

#!/bin/bash

 
  mysqladmin -P3306 -uroot -p${MYSQL_ROOT_PASSWORD} -h127.0.0.1 -r -i 1 ext |

    awk -F"|" \

      "BEGIN{ count=0; }"'{ if($2 ~ /Variable_name/ && ((++count)%2000000000 == 1)){\

      print "------Time-----|---log_written(KB)---|";\

  }\

  else if ($2 ~ /Innodb_os_log_written/){Innodb_os_log_written=$3/1024;}\

  else if ($2 ~ /Uptime / && count >= 2){\

    printf("%s |%22d \n",strftime("%m-%d %H:%M:%S"),Innodb_os_log_written)\

  }}'

作者:

数据库产品部 - 运维安全组 - 许天云

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值