xtrabackup备份mysql方法简介

MYSQL IT敢客 3个月前 (05-28) 602次浏览 已收录 0个评论 扫描二维码
XtraBackup 是现今为止唯一一款为 InnoDB 和 XtraDB 提供热备的开源工具,这个工具有以下的有点:
(1)备份快速高效而且可靠
(2)备份过程可以做到事物处理不间断
(3)节省磁盘空间和网络带宽
(4)自动备份验证
(5)恢复速度快而高效
XtraBackup 适用于所有版本的 Percona Server, MySQL, 和 MariaDB.而且提供了流式备份,增量备份,全备份,压缩备份的功能。对于 InnoDB, XtraDB, 和 HailDB,XtraBackup 可以实现完全无阻塞的备份。而且它对 MyISAM, Merge, 和 Archive 等存储引擎也有很好的支持,但是在备份的末尾部分要短暂的写入时间造成不可用状态。当然官方也有一个要掏钱的工具 MySQL Enterprise backup,不过大家都很少用的,功能相比 XtraBackup 不多,但是还是收费的,我们不排斥收费,我们只是力挺开源。
我们可以简单先看一下 XtraBackup 能做到那些:
(1)InnoDB 无阻塞备份,如果不是 INNODB 的数据表的话还是回 lock table。
(2)可以为 mysql 提供增量备份
(3)使用流式备份将 mysql 备份传送到另外一台 server
(4)在线在 mysql 数据库之间移动数据表
(5)很轻松创建一个复制的 slave,
(6)对数据库服务器没有太大负载
(7)XtraBackup 提供多种加密备份。
percona 的 XtraBackup 在备份的过程中是回跳过二级索引的备份,直到备份一个完整的数据库备份以后,再去重新创建二级索引,而且 XtraBackup 在备份中是可以导出单个表的,而且导出的表还可以在导入到 percona 库里(版本号大于 5.1 或者 mysql 官方大于 5.6),而且在备份的时候会产生一个备份锁,是个轻量级的替代锁(替代 FLUSH TABLES WITH READ LOCK)。
我们上面已经看到了 XtraBackup 功能的强大之处,下面看一下 XtraBackup 到底是怎么运行的:
其实 XtraBackup 也是基于 INNODB 的 crash-recovery 功能来实现的,他是对于数据文件的直接拷贝,为了保证数据内部的一致性,就需要使用到了 crash-recovery 来确保恢复的数据库是一致性的,而且是可用的。mysql 本身是有一个自己自身的事务日志文件,也就是 redo log,也就是说当 INNODB 启动的时候会做两步操作,事务日志中已经提交的事物会重做,之前没有提交的事物但是已经对数据文件做了修改的就会回滚,借此来保证数据的一致性。大部分关系型数据库都是这个原理。XtraBackup 也是基于 LSN( log sequence number)来工作的,每次启动备份,都会记录 LSN,然后开始拷贝文件,拷贝文件是要花费一部分时间的,所以说这期间一般情况都会有数据交互,所以说所有文件也可能记录的并不是一个时间点的数据,这个时候 XtraBackup 就会启动一个后台进程来观测 mysql 的事务日志,而且把事务日志中的改变记录下来。我们知道事物日志是回重用的(redo log),所以说这个监控事务日志的后台进程从启动那一刻起就会不停的运作,直到备份结束。这个后台监控进程会记录所有的事务日志的改变,这些是保证数据一致性所必须的。
前面有提到,XtraBackup 在备份的时候会用一个备份锁( Backup locks )来取代 FLUSH TABLES WITH READ LOCK,这是一个轻量级的替代锁(percona server 5.6+),XtraBackup 也会利用这个特性自动备份非 INNODB 表数据,可以防止阻塞 DML 语句的操作,当 backup locks 被支持的时候,xtrabackup 就会先拷贝 INNODB 的数据表,运行 LOCK TABLES FOR BACKUP 来拷贝 MYASIM 表和 .frm 文件,当拷贝结束后,在开始拷贝 .frm, .MRG, .MYD, .MYI, .TRG, .TRN, .ARM, .ARZ, .CSM, .CSV, .par, 和.opt 等文件。当然需要注意的是,备份的第一步是先完成 INNODB 的备份(文件和日志),LOCK TABLES FOR BACKUP 只是针对非 INNODB 表来说的。
以上执行完毕以后,XtraBackup 会执行 LOCK BINLOG FOR BACKUP 来锁定日志文件用以记录在日志中的位置,或者是 Exec_Master_Log_Pos 或者 Exec_Gtid_Set 的值,这些记录值是和 SHOW MASTER/SLAVE STATUS 中 report 的是一致的。然后停止拷贝事务日志,记录位置信息,结束以后 unlock 日志和表。
在恢复的准备阶段,XtraBackup 会执行 crash-recovery 执行备份的日志,然后将数据库启动到可用的状态。最终备份的 INNODB 和 MYASIM 表都会数据一致,INNODB 表数据一致是到备份结束的时间点,而不是备份开始的时间点,因为日志是要应用到这个时间点的。这个时间点是和 FLUSH TABLES WITH READ LOCK 是一致的。
下面看一下怎么去 Restoring 一个 backup:
我们可以使用–copy-back 或者 –move-backup 参数来还原一个数据库。在还原的时候,xtrabackup 会首先去读取配置文件里面的一些参数( datadir, innodb_data_home_dir, innodb_data_file_path, innodb_log_group_home_dir)已确定这些目录是否存在。
如果存在的话就回去执行拷贝,首先被拷贝的是 MYASIM 表,索引还有一些其他存储引擎的文件,接下来才会拷贝 INNODB 表和索引,然后是事务日志文件,在复制的时候是要保留源文件的所有属性,所以说这些目录的所有者最好是给 mysql 用户。但是我们要特别注意–move-back 这个参数,它是会移动备份文件,而不仅仅是恢复那么简单。这样的话原来的备份就没有了,是一个很危险的操作,唯一的适用场景就是磁盘空间不足了,只能通过移动的方式来恢复,SO 这个参数还是少用为妙。

安装:

去 percona-xtrabackup 官网上下载,有 rpm 包、tar 包,也有解压直接可用的二进制包。我试验采用的二进制包。

由于里面的 innobackupx 命令实际上是用 perl 语言封装了 xtrabackupx 而成,所以使用 innobackupx 命令要先检查 perl 包以及其依赖包的安装情况。

可以执行 yum install prel perl-DBD perl-Time-HiRes 解决关于 perl 的报错。

当然个人还是推荐 yum 安装,先安装 percona 的 yum 源

yum install https://www.percona.com/downloads/percona-release/redhat/0.1-4/percona-release-0.1-4.noarch.rpm

然后 yum install percona-xtrabackup,所有依赖全搞定

备份有全库备份、部分备份、全量备份、增量备份以及压缩备份等方式。

全库备份指备份数据目录下的所有库;部分备份指备份指定的库/表;全量和增量不在赘述。

   备份权限问题:如果以 root 之外的用户执行备份,备份用户需要有以下权限:

RELOAD and LOCK TABLES (unless the –no-lock option is specified) in order to FLUSH TABLES WITH READ LOCK prior to start copying the files and

REPLICATION CLIENT in order to obtain the binary log position,

CREATE TABLESPACE in order to import tables (see Restoring Individual Tables) and

SUPER in order to start/stop the slave threads in a replication environment.

    my.cnf 文件里面必须指定 datadir=xxx,innobackupx 在备份和恢复阶段从这里获知数据目录的路径。

全库全量备份

innobackupex –user=DBUSER –password=DBUSERPASS /path/to/BACKUP-DIR

并注意观察输出的最后一行,有“complete ok”才算成功。程序会在备份目录下创建一个以当前时间戳为名的目录存储备份的文件。

如果 mysql 配置文件不在默认目录(/etc,/datadir/)下,需要通过以下方式告知程序 my.cnf 的路径

innobackupex –defaults-file=/tmp/other-my.cnf –user=DBUSER –password=DBUSERPASS /path/to/BACKUP

并且–defaults-file 必须作为第一个选项

恢复分为两个步骤:准备阶段—-恢复阶段

innobackupx 备份完之后的数据时不能直接恢复使用的,因为拷贝数据文件的同时,还会有事务提交或回滚,xtrabackup 通过一个额外的线程记录拷贝过程中 binlog 日志中的变化,并在“准备”阶段通过将日志中的改变应用到备份文件中来保证备份文件的数据一致性。

  准备阶段:

执行

innobackupex –apply-log /path/to/BACKUP-DIR

另外可以通过使用–use-memory=xx 选项来加速此过程,例如

innobackupex –apply-log –use-memory=4G /path/to/BACKUP-DIR

此过程执行完,看到最后提示“complete ok”说明已经将日志中记录的的改变应用到备份文件中。

  恢复阶段:

关闭 mysql,清空 datadir(注意:mysql 的 datadir 在恢复过程中必须确保是空的,否则执行不成功),

innobackupex –copy-back /path/to/BACKUP-DIR   

(从 my.cnf 获得 datadir 之后,将最终可用的数据拷贝至 datadir)

提示“complete ok”之后,就可以启动数据库了。注意:在启动数据库前要注意修改数据目录权限,以确保 mysql 对于数据的可读性。

  特定库/表备份

对于特定库/表的备份,官方文档给出了三种方法

–include=’正则表达式’    例如 –include=’^ljk’只备份 ljk 库,在备份目录里还会有其他库的目录,但都是空的

–tables-file=文件   该文件中应该包含 database.table 形式的内容,每行一个表,注意:ljk.*是不生效的。

–databases=’库名[.表名]’  多个库中间以空格隔开,此选项还不完善,官方文档也说明了:此选项只对.frm 文件和非 innodb 表有效,对于 InnoDB 表即使指定了数据库,仍然会备份所有的库。

  恢复过程:执行

innobackupex –apply-log  /path/to/partial/backup

成功后关闭数据库,将制定库/表的备份文件 cp 至数据目录下即可,记得修改权限。

  增量备份

思路:先做全量备份,之后按照下面命令执行增备

innobackupex –user=DBUSER –password=DBUSERPASS /path/to/BACKUP-DIR

innobackupex –user=DBUSER –password=DBUSERPASS –incremental /data/backups –incremental-basedir=BASEDIR

  恢复过程:

思路:将各个增量备份的数据文件合并到最初的全量备份的目录下,最终是从全量备份这个目录下恢复数据。假如现在有一个全量三个增量的备份

innobackupex –apply-log –redo-only BASE-DIR/全备目录   注意;此处增加了–redo-only

innobackupex –apply-log –redo-only BASE-DIR/全备目录 –incremental-dir=INCREMENTAL-DIR-1(第一个增量的目录)

innobackupex –apply-log –redo-only BASE-DIR/全备目录 –incremental-dir=INCREMENTAL-DIR-2(第二个增量的目录)

innobackupex –apply-log BASE-DIR/全备目录 –incremental-dir=INCREMENTAL-DIR-3  (注:最后一个增量目录不需要加–redo-only 选项)

注:“准备”程中,增量备份的路径需要些绝对路径,试验时写相对路径不成功

如果以上都执行成功,则可以继续下一步

innobackupex –apply-log BASE-DIR/全备目录   将记录在日志里的改变应用的数据中,确保数据一致性。

然后可以向全量备份一样执行恢复了

innobackupex –copy-back BASE-DIR/全备目录


IT 敢客 , 版权所有丨如未注明 , 均为原创丨本网站采用BY-NC-SA协议进行授权
转载请注明原文链接:xtrabackup 备份 mysql 方法简介
喜欢 (3)
[313176056@qq.com]
分享 (0)
IT敢客
关于作者:
“我所做的一切都是为了方便我的生活~~~“
发表我的评论
取消评论
表情 贴图 加粗 删除线 居中 斜体 签到

Hi,您需要填写昵称和邮箱!

  • 昵称 (必填)
  • 邮箱 (必填)
  • 网址