如何进行MySQL 5.6 xtrabackup 全量和增量的备份及恢复

共计 8380 个字符，预计需要花费 21 分钟才能阅读完成。

今天就跟大家聊聊有关如何进行 MySQL 5.6 xtrabackup 全量和增量的备份及恢复，可能很多人都不太了解，为了让大家更加了解，丸趣 TV 小编给大家总结了以下内容，希望大家根据这篇文章可以有所收获。

xtrabackup 备份和恢复

  较之于 MySQL 自身的备份 mysqldump，类似于 Oracle 的 export。小数据量时效率还行，当数据量达到一定规模时，使用 mysqldump 执行备份的时间也许还可接受，但恢复时间基本就不能忍受了。
这时就需要一种好用又高效的工具，xtrabackup 就是其中一款，号称免费版的 InnoDB HotBackup。
Xtrabackup 提供了两种命令行工具：
xtrabackup：专用于备份 InnoDB 引擎的数据；
innobackupex：这是一个 perl 脚本，在执行过程中会调用 xtrabackup 命令，这样用该命令即可以实现备份 InnoDB，也可以备份 MyISAM 引擎的对象。
 
一、Xtrabackup 备份原理
XtraBackup 基于 InnoDB 的 crash-recovery 功能。它会复制 innodb 的 data file，由于不锁表，复制出来的数据是不一致的，在恢复的时候使用 crash-recovery，使得数据恢复一致。
InnoDB 维护了一个 redo log，又称为 transaction log，事务日志，它包含了 innodb 数据的所有改动情况。当 InnoDB 启动的时候，它会先去检查 data file 和 transaction log，并且会做二步操作：
XtraBackup 在备份的时候，一页一页地复制 innodb 的数据，而且不锁定表，与此同时，XtraBackup 还有另外一个线程监视着 transactions log，一旦 log 发生变化，就把变化过的 log pages 复制走。为什么要急着复制走呢？因为 transactions log 文件大小有限，写满之后，就会从头再开始写，所以新数据可能会覆盖到旧的数据。在 prepare 过程中，XtraBackup 使用复制到的 transactions log 对备份出来的 innodb data file 进行 crash recovery。

注意：xtrabackup 只备份数据文件，并不备份数据表结构 (.frm)，所以使用 xtrabackup 恢复的时候，你必须有对应表结构文件(.frm)。
所以要手动备份一下，以便 xtrabackup 恢复的时候使用。

二、备份操作：
 1 . 全量备份操作：

点击 (此处) 折叠或打开

[root@zhanglin bin]./xtrabackup –backup –log-stream –target-dir=/mysqlbak/xtrabackup/20141022 –datadir=/usr/local/mysql/data

./xtrabackup version 2.2.3 based on MySQL server 5.6.17 Linux (x86_64) (revision id:)

xtrabackup: uses posix_fadvise().

xtrabackup: cd to /usr/local/mysql/data

xtrabackup: open files limit requested 0, set to 1024

xtrabackup: using the following InnoDB configuration:

xtrabackup: innodb_data_home_dir = ./

xtrabackup: innodb_data_file_path = ibdata1:10M:autoextend

xtrabackup: innodb_log_group_home_dir = ./

xtrabackup: innodb_log_files_in_group = 2

xtrabackup: innodb_log_file_size = 50331648

——- 略

[01] Copying ./mdm_pro/org_organ_business_group.ibd to /mysqlbak/xtrabackup/20141022/mdm_pro/org_organ_business_group.ibd

[01] …done

[01] Copying ./mdm_pro/coding_rule.ibd to /mysqlbak/xtrabackup/20141022/mdm_pro/coding_rule.ibd

[01] …done

[01] Copying ./mdm_pro/org_store_channel.ibd to /mysqlbak/xtrabackup/20141022/mdm_pro/org_store_channel.ibd

[01] …done

[01] Copying ./mdm_pro/dim_org_store.ibd to /mysqlbak/xtrabackup/20141022/mdm_pro/dim_org_store.ibd

[01] …done

[01] Copying ./mdm_pro/org_organ_region.ibd to /mysqlbak/xtrabackup/20141022/mdm_pro/org_organ_region.ibd

[01] …done

[01] Copying ./mdm_pro/org_organ_managing_city.ibd to /mysqlbak/xtrabackup/20141022/mdm_pro/org_organ_managing_city.ibd

[01] …done

[01] Copying ./mdm_pro/pro_barcode.ibd to /mysqlbak/xtrabackup/20141022/mdm_pro/pro_barcode.ibd

[01] …done

[01] Copying ./mdm_pro/type_duibi_back.ibd to /mysqlbak/xtrabackup/20141022/mdm_pro/type_duibi_back.ibd

[01] …done

log scanned up to (18573586827)

[01] Copying ./mdm_pro/org_store.ibd to /mysqlbak/xtrabackup/20141022/mdm_pro/org_store.ibd

[01] …done

log scanned up to (18573586827)

xtrabackup: The latest check point (for incremental): \ 18573586827\

xtrabackup: Stopping log copying thread.

. log scanned up to (18573586827)

xtrabackup: Transaction log of lsn (18573586258) to (18573586827) was copied.

[root@zhanglin bin]

2. 增量备份概念：

MySQL 数据库本身提供的工具并不支持真正的增量备份，二进制日志恢复是 point-in-time(时间点)的恢复而不是增量备份。Xtrabackup 工具支持对 InnoDB 存储引擎的增量备份，工作原理如下：
(1)首先完成一个完全备份，并记录下此时检查点的 LSN(Log Sequence Number)。
(2)在进程增量备份时，比较表空间中每个页的 LSN 是否大于上次备份时的 LSN，如果是，则备份该页，同时记录当前检查点的 LSN。
首先，在 logfile 中找到并记录最后一个 checkpoint(“last checkpoint LSN”)，然后开始从 LSN 的位置开始拷贝 InnoDB 的 logfile 到 xtrabackup_logfile；接着，开始拷贝全部的数据文件

.ibd；在拷贝全部数据文件结束之后，才停止拷贝 logfile。
因为 logfile 里面记录全部的数据修改情况，所以，即时在备份过程中数据文件被修改过了，恢复时仍然能够通过解析 xtrabackup_logfile 保持数据的一致。
  在增量备份的目录下，数据文件都是以.delta 结尾的。增量备份只备份上一次全量备份后被修改过的 page，所以增量备份只暂用较少的空间。增量备份可以在增量备份的基础上增量。
增量备份优点：
1、数据库太大没有足够的空间全量备份，作增量备份有效节省空间，且效率高。
2、支持热备份。备份过程不锁表，不受时间限制，不影响用户使用。
3、每日备份只产生少量数据，远程备份传输更方便。同时节省空间。
4、备份恢复基于文件操作，降低直接对数据库操作风险。
5、备份效率更高，恢复效率更高。

提醒一下可能出现的错误：
(a)、在做增量备份的时候，如果 –target-dir 跟全量的一样，就会出现下面的报错
[root@zhanglin bin]# ./xtrabackup –backup –log-stream –target-dir=/mysqlbak/xtrabackup/20141022 –datadir=/usr/local/mysql/data –incremental-

basedir=/mysqlbak/xtrabackup/20141022_full_in
xtrabackup: Error: cannot open /mysqlbak/xtrabackup/20141022_full_in/xtrabackup_checkpoints
xtrabackup: error: failed to read metadata from /mysqlbak/xtrabackup/20141022_full_in/xtrabackup_checkpoints

(b)、同时如果 –incremental-basedir= 参数的最后目录不是 base 也会出错。
[root@zhanglin bin]# ./xtrabackup –backup –log-stream –target-dir=/mysqlbak/xtrabackup/20141022_full_in –datadir=/usr/local/mysql/data –incremental-

basedir=/mysqlbak/xtrabackup/20141022-test
xtrabackup: Error: cannot open /mysqlbak/xtrabackup/20141022-test/xtrabackup_checkpoints
xtrabackup: error: failed to read metadata from /mysqlbak/xtrabackup/20141022-test/xtrabackup_checkpoints

增量备份操作:

点击 (此处) 折叠或打开

[root@zhanglin bin]# ./xtrabackup –backup –log-stream –target-dir=/mysqlbak/xtrabackup/20141022_full_in –datadir=/usr/local/mysql/data –incremental-basedir=/mysqlbak/xtrabackup/base

./xtrabackup version 2.2.3 based on MySQL server 5.6.17 Linux (x86_64) (revision id:)

incremental backup from 16888466657 is enabled.

xtrabackup: uses posix_fadvise().

xtrabackup: cd to /usr/local/mysql/data

xtrabackup: open files limit requested 0, set to 1024

xtrabackup: using the following InnoDB configuration:

xtrabackup: innodb_data_home_dir = ./

xtrabackup: innodb_data_file_path = ibdata1:10M:autoextend

xtrabackup: innodb_log_group_home_dir = ./

xtrabackup: innodb_log_files_in_group = 2

xtrabackup: innodb_log_file_size = 50331648

log scanned up to (18580258871)

log scanned up to (18580258871)

xtrabackup: using the full scan for incremental backup

[01] Copying ./ibdata1 to /mysqlbak/xtrabackup/20141022_full_in/ibdata1.delta

—- 略

[01] Copying ./mdm_pro/mid_org_area.ibd to /mysqlbak/xtrabackup/20141022_full_in/mdm_pro/mid_org_area.ibd.delta

[01] …done

[01] Copying ./mdm_pro/org_organ_business_group.ibd to /mysqlbak/xtrabackup/20141022_full_in/mdm_pro/org_organ_business_group.ibd.delta

[01] …done

[01] Copying ./mdm_pro/coding_rule.ibd to /mysqlbak/xtrabackup/20141022_full_in/mdm_pro/coding_rule.ibd.delta

[01] …done

[01] Copying ./mdm_pro/org_store_channel.ibd to /mysqlbak/xtrabackup/20141022_full_in/mdm_pro/org_store_channel.ibd.delta

[01] …done

[01] Copying ./mdm_pro/dim_org_store.ibd to /mysqlbak/xtrabackup/20141022_full_in/mdm_pro/dim_org_store.ibd.delta

[01] …done

[01] Copying ./mdm_pro/org_organ_region.ibd to /mysqlbak/xtrabackup/20141022_full_in/mdm_pro/org_organ_region.ibd.delta

[01] …done

[01] Copying ./mdm_pro/org_organ_managing_city.ibd to /mysqlbak/xtrabackup/20141022_full_in/mdm_pro/org_organ_managing_city.ibd.delta

[01] …done

[01] Copying ./mdm_pro/pro_barcode.ibd to /mysqlbak/xtrabackup/20141022_full_in/mdm_pro/pro_barcode.ibd.delta

[01] …done

[01] Copying ./mdm_pro/type_duibi_back.ibd to /mysqlbak/xtrabackup/20141022_full_in/mdm_pro/type_duibi_back.ibd.delta

log scanned up to (18580258871)

[01] …done

[01] Copying ./mdm_pro/org_store.ibd to /mysqlbak/xtrabackup/20141022_full_in/mdm_pro/org_store.ibd.delta

[01] …done

xtrabackup: The latest check point (for incremental): \ 18580258871\

xtrabackup: Stopping log copying thread.

. log scanned up to (18580258871)

xtrabackup: Transaction log of lsn (18580258871) to (18580258871) was copied.

[root@zhanglin bin]#

3、xtrabackup 参数介绍：
–defaults-file=#
默认配置文件的路径，如果不该参数，xtrabackup 将从依次从以下位置查找配置文件 /etc/my.cnf、/etc/mysql/my.cnf、/usr/local/etc/my.cnf、~/.my.cnf，并读取配置文件中的 [mysqld] 和

[xtrabackup]配置段。[mysqld]中只需要指定 datadir、innodb_data_home_dir、innodb_data_file_path、innodb_log_group_home_dir、innodb_log_files_in_group、innodb_log_file_size

6 个参数即可让 xtrabackup 正常工作。

–defaults-extra-file=#  如果使用了该参数，在读取了全局配置文件之后，会再读取这里指定的配置文件
–target-dir=name  备份文件的存放目录路径
–backup  实施备份到 target-dir
–prepare  实施对备份文件进行恢复前的准备(生成 InnoDB log file)
–print-param  打印备份或恢复时需要的参数
–use-memory=#  该参数在 prepare 的时候使用，控制 prepare 时 innodb 实例使用的内存量
–suspend-at-end  在 target-dir 目录下产生一个 xtrabackup_suspended 文件，将 xtrabackup 进程挂起，不停地将数据文件的变化同步到备份文件，直到用户手工删除

xtrabackup_suspended 文件
–throttle=#  每秒 IO 次数, 限制 backup 时使用的 I / O 操作量，使备份对数据库正常业务的影响最小化
–log-stream  该参数在 backup 的时候使用，将 xtrabackup_logfile 的内容标准输出，使用该参数时会自动使用 suspend-at-end 参数，innobackupex 脚本的 stream 模式会使用该参数。
–incremental-lsn=name  增量备份时只拷贝 LSN 比该参数指定值新的 ibd pages，前次备份到了哪个 LSN 可以看前次备份集的 xtrabackup_checkpoints 文件
–incremental-basedir=name  该参数在 backup 的时候使用，备份比该参数指定位置的备份集新的 idb pages
–incremental-dir=name  该参数在 prepare 的时候使用，指定 prepare 时产生的.delta 文件和日志文件的存放路径
–tables=name  在备份 file-per-table 类型的数据文件时使用，使用正则表达式指定需要备份的 innodb 表
–datadir=name MySQL 数据库的数据文件目录。

三、全量和增量恢复：
我们需要分别对全量、增量备份各做一次 prepare 操作。如果只是做全量恢复，就只需要执行一次你之前的全量就可以了，这里给出命令。
./xtrabackup –defaults-file=/etc/my.cnf –prepare –target-dir=/mysqlbak/xtrabackup/20141022

./xtrabackup –defaults-file=/etc/my.cnf –prepare –target-dir=/mysqlbak/xtrabackup/20141022_full_in –incremental-basedir=/mysqlbak/xtrabackup/base

提醒：xtrabackup 只备份 InnoDB 数据文件，表结构是不备份的，所以恢复的时候，你必须有对应表结构文件(.frm)。

看完上述内容，你们对如何进行 MySQL 5.6 xtrabackup 全量和增量的备份及恢复有进一步的了解吗？如果还想了解更多知识或者相关内容，请关注丸趣 TV 行业资讯频道，感谢大家的支持。