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

57次阅读
没有评论

共计 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 行业资讯频道,感谢大家的支持。

正文完
 
丸趣
版权声明:本站原创文章,由 丸趣 2023-07-19发表,共计8380字。
转载说明:除特殊说明外本站除技术相关以外文章皆由网络搜集发布,转载请注明出处。
评论(没有评论)