A-A+

基于Xtrabackup的物理备份解决方案预研

2014年03月29日 TenDB, Tool 暂无评论

【预研背景】

马年伊始,TenDB开发团队发布了dbbackup v2.0.5。作为TenDB逻辑备份解决方案的一次升级,新版dbbackup除了增加对binary字符集备份的支持外,通过在备份过程中拆分大单表的方法,进一步加强大表在恢复时的并发性,从而极大缩减备份介质在恢复时所需时间。dbbackup v2.0.5目前覆盖42项业务,652个实例。

对于例如XYZ广东1区这样大数据业务,虽然dbbackup v2.0.5将恢复时间从20小时减少到7小时,但这个时间间隔依然不能满足快速恢复的业务需求。寻求一种快速、稳定、安全的数据备份与恢复解决方案,是TenDB开发团队必须面对的挑战之一。

【预研方案】

在业界,诸如facebook这样坐拥数据金矿的互联网公司已经完成了从mysqldump往percona xtrabackup迁移。我们的物理备份解决方案是在Xtrabackup-2.1.6基础上展开的。Xtrabackup是一款功能强大的开源工具,支持非停机环境下的全量备份、增量备份、流式备份、内压缩、多线程拷贝与压缩等。在备份和恢复过程中,直接对物理文件进行IO操作,相比dbbackup这样依赖tmysqldump的逻辑备份方案而言,Xtrabackup具有更快、CPU开销更小、且一致性依然得到保证等优势。

然而,我们的TenDB-1.4是基于mysql-5.5.24开发的,并且在线加字段等重大功能点的实现已经对mysql内核做出一定程度的修改,TenDB团队在源代码层面将Xtrabackup无缝迁移到TenDB-1.4内核上,确保两者能够互相兼容,正常运作。

【收益评测】

我们的性能压测选取了XYZ广东1区业务作为数据源,在Z3机器上搭建TenDB实例,实际物理文件所占磁盘空间423G,采用停机全库备份(即备份过程中数据不再更新,这和现网环境有差异:现网环境的备份虽然在凌晨3点到早晨9点,但还是有一些更新操作发生)。

经多次测试,同现网dbbackup v2.0.5对XYZ广东1区业务进行备份/恢复相比,我们发现Xtrabackup至少在以下2个方面,有重大收益:

  1. 备份时间从6小时缩短为2小时,备份速度提升200%;
  2. 恢复时间从7小时缩短为近2小时,恢复速度提升250%;

具体测试数据如下图所示:

wps_clip_image-20384

与此同时,我们比对了Xtrabackup在运行时的机器性能数据,发现无论备份还是恢复,Xtrabackup在CPU上的消耗都小于dbbackup,磁盘的利用率略高于dbbackup

如下图所示:

1

3

2

最后,TenDB团队在预研过程中确认了Xtrabackup以下功能点:

  • 支持Point-In-Time(基于时间点)的一致性备份
  • 支持流模式备份时的内部压缩,磁盘占用相对可控
  • 支持在线热备

【优缺点比较】

Xtrabackup备份的优势

  1. 备份和恢复非常快
  2. 增量备份
  3. 流式备份
  4. (解)压缩算法相比逻辑备份的zlib库更快
  5. 自身多线程支持

Xtrabackup备份的劣势

  1. 不够灵活,无法单独备份指定表、指定库
  2. 无法同逻辑备份那样grep特定业务存在的字符串
  3. 空间损耗,且不支持逻辑备份恢复时的碎片整理功能
  4. 依赖于备份过程中生成的redo log大小,若过大会极大的影响备份和恢复速度
  5. 逻辑备份在不同mysql版本中,兼容性较好;而Xtrabackup作为物理备份方案,对mysql server的版本依赖性较强,扩展性较差

【预研开发】

Xtrabackup同时兼容了多个版本的MySQL,包括mysql-5.1.70/mysql-5.5.31/mysql-5.6.11。然而,如前所述,TenDB-1.4是基于mysql-5.5.24开发的,并且在此基础上做了较大改动,从而引发了如下几个问题:

  1. mysql-5.5.24和mysql-5.5.31接口兼容,代码细节却存差异,无法确认Xtrabackup是否对一些私有接口和宏产生依赖;
  2. 一些“宏开关”的细微差别,导致同名结构体定义出现偏差,给调试、定位问题带来诸多困扰;
  3. TenDB在线加字段等大功能点的实现对mysql-5.5.24底层日志格式做出一定程度的修改,尤其是Xtrabackup依赖redo log机制实现保证一致性备份,这需要将两者在源码级别做兼容,否则无法正常运作;
  4. Xtrabackup在编译阶段会将mysql“打补丁”,会将一些内部私有接口外露,在外部调用mysql内核更为底层的代码逻辑,这会使得mysql工程出现重定义、未定义的链接错误,以及全局变量命名污染等问题;
  5. Xtrabackup本身的源代码依赖于mysql工程的多个库,出于兼容性的考虑,使用了自定义的编译策略,这使得不能兼容TenDB的某些子模块的编译行为;

TenDB团队在逐步了解Xtrabackup原理和代码细节的基础上,逐一将这些难点逐一攻破。测试阶段,通过多次在腾讯游戏业务上做DR,一方面测试Xtrabackup在备份、恢复、压缩时的性能表现,另一方面重点验证了其正一致性是否得到保证。

关于mysql一致性校验,使用如下代码进行测试:

[bash]/home/mysql/monitor/dba-toolkit/mk-table-checksum -uMONITOR -pMONITOR --port 20000 --chunk-size=20M --chunk-size-exact=yes --ignore-databases=mysql,information_schema,db_infobase,test --chunk-size-limit=10 --replicate=db_infobase.checksum --throttle-method=none --no-check-replication-filters --create-replicate-table xx.xx.xx.xx[/bash]

关于Xtrabackup是备份、恢复等一系列操作手册,可以猛击这里[使用XtraBackup只需6步即可创建Slave]

【原理概述】

Xtrabackup备份恢复原理可以如下概括:备份innodb表时,Xtrabackup若干个线程拷贝独立表空间的.ibd文件,并不停监视此过程中redo log的变化,添加到自己的事务日志文件(xtrabackup_logfile)中。在此过程中,发生的物理写操作越多,xtrabackup_logfile越大。在拷贝完成后的第一个prepare阶段,Xtrabackup采用类似于innodb崩溃恢复的方法,把数据文件恢复到与日志文件一致的状态,并把未提交的事务回滚。如果同时需要备份myisam表以及innodb表结构等文件,那么就需要用flush tables with lock来获得全局锁,开始拷贝这些不再变化的文件,同时获得binlog位置,拷贝结束后释放锁,也停止对redo log的监视。

过程1. 创建备份(create)的示意图如下图所示:

wps_clip_image-18058

过程2. 应用redo log(apply-log)的示意图如下图所示:

wps_clip_image-27506

wps_clip_image-12307

过程3. 恢复(copy-back)的示意图如下图所示:

wps_clip_image-12309

【待跟进点】

  1. Xtrabackup备份磁盘占用量从120G上涨到170G,这也是目前来看Xtrabackup最大的局限所在,需要针对业务再次考量;
  2. 当前压力测试是在数据库静态环境下进行的,Xtrabackup在备份时会检测底层页面的更改操作,并记录在自己的日志中,这部分日志量取决于备份时DB真正物理写操作的量级,这需要针对不同业务再次考量;
  3. 如何与现有备份中心、GCS系统、逻辑备份解决方案紧密结合;
  4. Xtrabackup增量备份和加密备份功能点还有待确认和测试;
  5. 修改后的Xtrabackup已经兼容TenDB-1.4,但对官方版本mysql-5.5的兼容性还有待测试;

【小结】

Xtrabackup作为mysql物理备份开源工具,其丰富的功能点以及优异的性能表现,让我们没有理由再拒绝它。建立在Xtrabackup基础之上,结合TenDB特性,针对某些大数据业务的解决方案已经开始提上议程。

然而,现有的Xtrabackup也并非一劳永逸的完美方案,在数据备份恢复方面,我们会立足于业务,具体问题具体分析,将dbbackup逻辑备份工具和xtrabackup物理备份工具结合起来,为构建互娱数据安全、稳定、高效的存储备份体系而不断添砖加瓦。

后续,TenDB开发团队将加深理解Xtrabackup底层源码,并逐步落实规划,配合业务灰度,敬请期待!

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

本文链接地址: 基于Xtrabackup的物理备份解决方案预研

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

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

用户登录

分享到: