mysql/mariadb知识点总结(29):xtrabackup理论总结

  • A+
所属分类:mysql  数据库

这篇文章总结了Xtrabackup备份工具的相关理论。

mysql/mariadb知识点总结(29):xtrabackup理论总结

在本博客中,"mysql"是一个系列文章,这些文章主要对mysql/mariadb的常用知识点进行了总结,每一篇博客总结的知识点有所不同,具体内容可参考mysql文章列表。

mysql文章列表直达链接:mysql知识点总结

 

一些历史

MariaDB直到5.5版本,都一直依照MySQL的版本,所以,我们使用MariaDB5.5即可了解到MySQL5.5的所有功能,而MariaDB并没有所谓的5.6版本,而是直接将5.5之后的版本定义为MariaDB 10.0,MariaDB 10.0是建立在MariaDB5.5的基础上的,并且它拥有MySQL5.6的补丁功能以及一些其他的新特性。

 

percona公司是mysql领域比较有名的咨询公司,这个公司对innoDB存储引擎进行了性能增强,被percona增强后的innoDB存储引擎叫做Percona XtraDB,Centos7中默认提供Mariadb5.5数据库,而MariadDB5.5的默认的存储引擎就是XtraDB,因为XtraDB完全兼容InnoDB,所以我们可以无差别的使用他们,在MariadDB5.5中使用show engines命令查看存储引擎时,会发现引擎的名称为InnoDB,但是对应的描述中,InnoDB却被描述为Percona-XtraDB,因为兼容,所以引擎名称为InnoDB,但是实际上我们使用的是Percona公司的XtraDB存储引擎。

 

percona也有自己的mysql分支,叫做Percona Server for MySQL,不过这里不是我们讨论的重点,我们此处要说的percona出品的一款mysql innodb数据库备份工具:XtraBackup,XtraBackup是一款免费软件,因此,它是商业备份工具InnoDB Hot Backup的一个很好的替代品,percona官网将XtraBackup与InnoDB Hot Backup进行了对比,链接如下

https://www.percona.com/software/mysql-database/percona-xtrabackup/feature-comparison

 

一些概念

xtrabackup支持对innodb进行热备、增量备份、差量备份。

xtrabackup支持对myisam进行温备,因为在备份myisam表时,会对myisam表添加读锁,而且不能对myisam表进行增量备份,每次备份myisam数据都是全量,即使名义上是增量,但是实际上仍然是全量。

 

与mysqldump不同,xtrabackup是一种物理备份工具,但是,它是需要通过协议连接到mysql服务端(这一点与mysqldump相同,它们都是客户端工具,都需要连接到服务端),然后读取并复制innodb底层的"数据块",完成所谓的"物理备份"。

综上所述,xtrabackup是一种客户端工具,我们能够通过它对mysql数据库实现物理备份。

 

xtrabackup怎样实现物理备份

xtrabackup是怎样对innodb存储引擎实现所谓的物理备份的呢?

如果想要搞清楚这一点,需要回顾一下innodb的存储结构,借用一张网上流传比较广的innodb逻辑存储结构图,如下

mysql/mariadb知识点总结(29):xtrabackup理论总结

innodb存储引擎的逻辑结构如上图所示,逻辑单元从大到小分别为:表空间(tablesapce)、段(segment)、区(extent)、页(page)、行(row),如上图所示,每个大的逻辑单元中都包含了N个小的逻辑单元。

 

而我们只要关心上图中的extent逻辑单元和page逻辑单元即可,我们可以把上图中Extent区域中的每个"小方块(page)"当做xtrabackup需要备份的"数据块",因为数据存放于行中,行存在于page中,所以,我们备份对应page,即可备份出对应的数据,当我们使用xtrabackup连接到mysql服务端的时候,xtrabackup会读取innodb中的page,进行备份。

 

xtrabackup怎样实现增量备份

每个Page都有自己的LSN号码,LSN是一个全局递增的号码,每次对page中的记录进行修改时,都会有对应的LSN号码,因为LSN是全局递增的,所以,LSN只会越来越大,之后的修改产生的LSN肯定比之前的操作产生的LSN大,每个page中的数据被更改时,都会在这个page中记录下本次的LSN号码,所以,如果这个page中记录的LSN越大,就证明这个Page中的数据越新(最近被修改)。

而xtrabackup就是通过LSN,实现对innodb表的增量备份的,每次备份开始时,xtrabackup会记录下当前备份到的LSN号码,当下次进行增量备份时,xtrabackup就只会拷贝出LSN大于上次记录的page,那些LSN号码小于上次记录的page则会被跳过,如果page中的LSN小于上次备份时记录的LSN号码,则证明这个page自从上次备份以来并没有被修改过,同理,如果page中的LSN大于上次备份时记录的LSN号,则证明这个page在上次备份以后,已经被修改了,所以,备份出这些page,即可实现增量备份的目的。

 

如果你还是没有理解,那么我们画一个简易的示意图,再来理解一遍。

假设,我们第一次备份的数据如下,所有数据由如下6个page组成,下图中的黄色方块代表page,黄色方块右上角的号码代表当前page的LSN,从下图可以看出,目前最大的LSN号码为5。

mysql/mariadb知识点总结(29):xtrabackup理论总结

假设,备份完成后,我们修改了数据,而这次修改的数据存在于上图中的page C与page E中,所以,上图中的pageC与pageE的LSN就变成了6,因为刚才最大的LSN是5,而LSN是全局递增的,所以,如果page中的LSN越大,证明此page越新,被修改的时间越近,如下图所示

mysql/mariadb知识点总结(29):xtrabackup理论总结

如果此时要做增量备份,那么,我们只需要备份出自上次备份以后变化的数据即可,所以,我们只要从上图中找到LSN大于5的Page,即上图中的pageC与pageE,即可得出变化的增量数据,得出上图中的增量page后,再将增量page覆盖到上次的备份中,即可得到最新的数据。

 

一些注意点

当我们开始备份innodb数据时,我们还需要同时备份对应的事务日志,因为在开始备份时,有些事务已经存在于事务日志中,这些事务可能已经提交了,但是还没有同步到datafile中,所以我们要重放这些已经提交的事务,有些事务可能还未提交,所以我们要回滚这些没有提交的事务。

xtrabackup就是这样做的,在备份开始时,同时运作两个线程,一个线程负责备份innodb中的page,另一个线程负责备份innodb的事务日志(redo log),事务日志都会被xtrabackup记录到自己的日志文件中,那么,备份结束后,我们会得到两份文件,一份是不可用的备份文件,一份是备份时的事务日志,备份文件之所以不可用,是因为有一部分不确定的数据可能在事务日志中,而且热备过程中数据也可能会发生改变,所以我们要通过这两份文件,制作出一份可用的备份文件,没错,就是通过应用事务日志的方式,让最终的备份成为一个可用的备份,事务日志会被应用,事务日志文件中已经提交的事务需要replayed,未提交的事务需要roolback,  整个过程类似于mysql崩溃后恢复的过程,但是这个过程在xtrabackup中被称为"prepare","prepare"操作保证了备份出的数据的一致性,没有经过prepare的备份数据是不可用的,我们可以理解为如果想要得到一个可用的备份,则需要进行这些所谓的"准备"工作或者所谓的"数据恢复"的工作。

 

说到这里,就必须考虑另外一个问题,我们刚才提到,想要备份数据可用,则必须进行prepare工作,那么,先不考虑存在增量备份的情况,当不存在增量备份时,我们在对数据进行prepare时,需要应用事务日志,对于已经写入redologfile中但是还没有写入datafile中的已提交事务进行同步,对于未提交的的事务所作出的修改进行回滚,这是没有增量的情况下,但是,如果存在增量备份时,xtrabackup会将所有增量都合并到之前的全量上,然后使用最后的完整数据进行还原,那么,在合并数据的过程中,上一次未提交的事务有可能在下次的增量备份中已经提交了,所以,如果存在多个增量备份的时候,我们在进行prepare工作时,只需要将已经提交的事务同步到数据文件中即可,未提交的事务不用进行回滚,因为在增量中,这些事务可能已经提交了,只需要在最后一份增量数据进行prepare时,将对应的未提交的事务回滚即可。

 

而我们知道,xtrabackup能对innodb做热备,能对myisam做温备,对myisam做温备时会对myisam表添加读锁,也就是说,备份出的myisam表中的数据应该是一致的 ,但是如果数据库中既有myisam表又有innodb表时,如果想要整体的所有数据都一致,则只能以myisam的一致性时间点作为最终备份的一致性时间点,所以,xtrabackup在备份时,会先备份inndb数据,备份完innodb数据后,再备份非innodb数据,当我们需要将备份的数据"prepare"时,只操作innodb数据即可,非innodb数据不用动,prepare完成后,innodb的一致性时间点与非innodb数据的一致性时间点是相同的。

 

好了,这篇文章总结了xtrabackup中的一些理论知识,实际的操作会单独总结在其他文章中,直达链接如下

安装xtrabackup并进行全量备份

希望这篇文章能够对你有所帮助。

 

weinxin
我的微信公众号
关注"实用运维笔记"微信公众号,当博客中有新文章时,可第一时间得知哦~
朱双印

发表评论

:?: :razz: :sad: :evil: :!: :smile: :oops: :grin: :eek: :shock: :???: :cool: :lol: :mad: :twisted: :roll: :wink: :idea: :arrow: :neutral: :cry: :mrgreen:

目前评论:8   其中:访客  5   博主  3

    • avatar 杜嘉嘉 2

      非常感谢楼主无私分享,收益良多。楼主可以建个qq群,大家一起讨论!希望你的博客越来越好。

      • avatar yong 3

        博主我几个小疑问,希望能解答一下:
        1)为什么不直接备份行(raw)?这个问题是不是很傻…

        2)page最初的LSN号码是在什么时候产生的?是第一次数据写入时吗?

          • avatar yong 3

            @yong 3)relayed和roolback能来点通俗的解释吗?

              • avatar 朱双印 Admin

                @yong 不好意思,这两天公司搬迁到临时驻点,比较忙,回复晚了见谅。
                1、innodb存储引擎的最小物理存储分配单位是page,所以物理备份的单元不能比page更小。
                2、是的。
                3、这个···暂时没有,先继续,回过头来再看可能更容易理解。

                  • avatar yong 3

                    @朱双印 博主,太客气了。能在百忙之中,抽空回答我的小疑问,真是太感动了。
                    嗯嗯…第三问题现在,已经有点小头绪了。
                    现在还有点小疑问:已提交但未同步的事务 存放在 redo log中,那未提交的事务存放在哪里呢?log buffer中吗?

                      • avatar 朱双印 Admin

                        @yong :?: 这个我也不确定 :shock: ,不能随便回答你,兄弟,等我搞清楚以后再和你探讨啊~~或者你搞清楚了分享出来~~ :oops:

                          • avatar yong 3

                            @朱双印 嗯嗯…这个问题我是这样理解的,不知道对不对?
                            已提交的事务和未提交的事务,应该都是被记录在事务日志中的,也就是redo log中,这样就能解释relayed和roolback了。
                            xtrabackup在备份时,会备份redo log和数据文件;
                            当进行数据恢复时,在应用日志(–applay-log)时,会将已提交但未同步的事务和未提交的事务都relayed到数据文件中,最后要对未提交的事务进行rollback(事务的一致性)。

                            以上就是个人愚见,理解的好像很牵强,望博主纠正.

                              • avatar 朱双印 Admin

                                @yong 兄弟客气了 :oops: 好久没搞数据库了,说实话我已经快忘完了,兄弟,你坚定了我复习的决心 :mrgreen: 不管对错,能思考就是好的,加油~兄弟~