A-A+

使用xtrabackup完成高负载机器的备份及重做Slave

2015年06月15日 TenDB 暂无评论

这两天某DBA同学反馈某业务的某两台Master DB负载太高,Slave由于单线程跟进SQL线程延迟太大,大量的relay-log文件已经把中继日志所在的硬盘分区撑爆;目前该Slave已断开跟进。

而在尝试重做Slave的时候,发现mysqldump逻辑备份跑了接近两天还未完成,原因是机器IO Util太高了。IO利用率及每五分钟的Question量如下图所示:

xtra_11 xtra_22

看下该机器的整体情况:100G左右的数据文件,每3-4分钟产生256M的binlog。机型是老A5(12块SAS盘,单盘146G),Raid结构是:2Raid1+10Raid10,/data分区103G;按该机器binlog的增长速度一天90G,/data只能存放一天的binlog文件。

如何解决上面说了两个问题:

  • DB负载高,QPS高,同机型的A5,DR无法跟进
  • DB binlog保存时间短,逻辑备份时间太长,无法重建新DR

针对上面的第一个问题,可以采用如下三种方法解决:
a) 替换DR到更强的FIO机型Z3(scale up)

  1. b) 采用mysql 5.6库级或mysql 5.7表级的并行同步功能,但因为DB的mysql版本是5.0.67,如果升级到更高版本的mysql,后续出现Master 故障切换到Slave ,可能会对业务有所影响
  2. c) 联合开发一起拆库(scale out),将DB的QPS降低

 

无论是采用哪种方案,从最小化业务停机时间的角度,都需要先将热备做起来(解决上面说的第二个问题)。而前面说过,逻辑备份无法胜任这项工作,即使我们使用nfs挂了一台远程的Z3机器, mysqldump出来的数据落到该Z3上面。

不得已得采用物理备份,虽然上面说了机器的IO Util很高,但实际整个IO的吞吐能力没用满,如下可以看出磁盘读写量rKB/s + wKB/s还比较低(参考下图红框内的数据),还远达不到老A5的磁盘吞吐能力:

xtra_33

故源码编译了xtrabackup 0.7版本(基于mysql5.0.67的源码),在该机器上100G数据文件备份仅需要45分钟,远低于逻辑备份的2 day+。由于物理备份会占用较多的磁盘吞吐量,故做备份期间会有少量慢查询(充分知会业务侧,少量慢查询可以接受),下面是做物理xtrabackup的慢查询的每五分钟的量:

xtra_44

在备份的时间窗口内:磁盘吞吐能力明显增加了

xtra_55

物理备份做好了,后面按照做Slave 步骤,物理恢复 + 授权 + change master to都比较简单了。

 

下面简要记录一下xtrabackup编译及使用步骤,最终文章附件会带上编译好的xtrabackup的可执行文件(仅适用mysql5.0.67,适用于 64位SuSE及TLinux或Centos内核):

 

【编译安装】

  • 下载xtrabackup-0.7.tar的源码文件及mysql-5.0.67.tar的源码文件
  • 分别解压xtrabackup及mysql tar包,进入xtrabackup目录拷贝到mysql源码的innobase目录下
greatdba_release:/data/home/felixliang/ # cp -r xtrabackup-0.7 mysql-5.0.67/innobase/
  • 给mysql 5.0.67打上xtrabackup的补丁,命令及输出如下
greatdba_release:/data/home/felixliang/mysql-5.0.67/innobase # patch -p2 < ./xtrabackup-0.7/fix_innodb_for_backup.patchpatching file buf/buf0buf.cpatching file buf/buf0rea.c

patching file fil/fil0fil.c

patching file include/mem0mem.h

patching file include/mem0mem.ic

patching file include/srv0start.h

patching file include/ut0byte.ic

patching file log/log0log.c

patching file log/log0recv.c

patching file mem/mem0mem.c

patching file os/os0file.c

patching file os/os0thread.c

patching file srv/srv0start.c

patching file trx/trx0trx.c

  • 编译mysql及xtrabackup
       # configuregreatdba_release:/data/home/felixliang/mysql-5.0.67/ # ./configure# make

greatdba_release:/data/home/felixliang/mysql-5.0.67/ # make

# 再次在xtrabackup的目录下make,不需要make install即可得到xtrabackup的可执行文件

greatdba_release:/data/home/felixliang/mysql-5.0.67/innobase/xtrabackup-0.7 # make

  • 得到可执行文件innobackupex-1.5.1及xtrabackup,其中innobackupex-1.5.1是个wrapper

 

【使用步骤】

1、备份数据

./innobackupex-1.5.1 --user=ADMIN --password=*** /data1/dbbak/xtraDIR --no-timestamp

 

2、准备还原数据,应用备份的redo日志

./innobackupex-1.5.1 --apply-log /data1/dbbak/xtraDIR

 

3、还原数据

./innobackupex-1.5.1 --copy-back /data1/dbbak/xtraDIR

 

其中,备份、应用redo日志及还原数据库,均需要看到”innobackup completed OK”关键字才证明命令执行是成功的。

 

注:本文使用xtrabackup解决的是老版本mysql的问题(5.0.67的mysql版本),需要编译xtrabackup使用。

原创文章,转载请注明: 转载自腾讯游戏DBA团队

本文链接地址: 使用xtrabackup完成高负载机器的备份及重做Slave

文章的脚注信息由WordPress的wp-posturl插件自动生成

Copyright © 腾讯游戏DBA团队 保留所有权利.  

用户登录

分享到: