Percona xtrabackup备份细节是怎样的

今天就跟大家聊聊有关Percona xtrabackup备份细节是怎样的，可能很多人都不太了解，为了让大家更加了解，小编给大家总结了以下内容，希望大家根据这篇文章可以有所收获。

xtrabackup为了完成备份会做两个主要的工作：

任务一：

xtrabackup会在后台开启一个log-copying的线程，该线程会对redo log file进行监视，并把从lsn1(lsn1是Xtrabackup在启动时会从redo log file中获取最近一次的checkpoint对应的log sequence number lsn1 )开始增加的数据块（日志记录）不断的复制到备份集中一个叫xtrabackup_logfile的文件里面。日志copy操作，会在整个备份过程中一直进行，因为备份集做恢复的时候需要从lsn1开始到备份结束时所有日志记录，恢复原理就是 crash recover 的过程。

注：

log-copying 线程每一秒都会去 check 事务日志，看是否有新写入的需要copy走的日志项.但是有种可能性：

log-copying 线程的copy的速度比写入redofile 的速度慢，有可能事务日志循环一周，造成会有一部分日志

还没有被读取就被覆盖了,此时 log—copying 线程会报错，备份失败。

…

任务二：

xtrabackup在进行copy redo 日志的同时会copy innodb的data file ， 当然这不是简单的复制，它使用了跟innodb类似的方式访问数据文件,访问数据字典，并以数据页为单位来进行copy。具体的细节如下：

  xtrabackup是以读写的方式打开数据文件的，尽管它不会修改数据。这是因为它使用内置的innodb的lib库

来访问数据文件的，也隐含了你要用对数据文件有读写权限的用户来进行备份。innodb的lib库使用读写方式打

开是因为正常情况下代开文件就预示着写数据。

  在copy数据到备份目标目录的过程中，xtrabackup 每次读取1M数据（不可配置），copy日志文件的时候，

每次读写512字节，同样不可以配置。数据读取之后，xtrabackup会对这1M的缓存数据块进行扫描，并对每一个

数据页使用buf_page_is_corrupted()函数进行验证，看起是否损坏，如果page损坏了，对其重新读取并重新

验证。如果重读10次都失败了，本次备份失败，那么备份失败。

注 ： (It skips this check on the doublewrite buffer)

xtraback备份结尾

当数据文件复制完成，xtrabackup 会停掉log-copying线程，并在备份目录下创建一个

xtrabackup_checkpoints 的文件，该文件包含备份的类型，还有备份开始时的log sequence number，还有结束时的log sequence number 。备份过程中，我们会看到数据文件copy信息，也会看到日志复制线程重复的扫描日志文件，并进程copy的信息，信息如下：

>> log scanned up to (3646475465483)

>> log scanned up to (3646475517369)

>> log scanned up to (3646475581716)

>> log scanned up to (3646475636841)

>> log scanned up to (3646475718082)

>> log scanned up to (3646475988095)

>> log scanned up to (3646476048286)

>> log scanned up to (3646476102877)

>> log scanned up to (3646476140854)

[01] Copying /usr/local/mysql/var/ibdata1

to /usr/local/mysql/Backups/2011-04-18_21-11-15/ibdata1

[01]        ...done

the log file thread repeatedly scanning the log files and copying from it

看完上述内容，你们对Percona xtrabackup备份细节是怎样的有进一步的了解吗？如果还想了解更多知识或者相关内容，请关注行业资讯频道，感谢大家的支持。