MySQL中xtrabackup备份恢复全攻略(r12笔记第11天)

XtraBackup是Percona推出的一款备份工具,算是对于mysqldump的一个补充。对于大批量数据的导入使用mysqldump会出现一定的瓶颈,这一点做过一些数据迁移项目的同学可能感同身受。

数据迁移中的数据量,小有小的好,大有大的招,见招拆招,找到适合的场景是最佳的。

如果现在去Percona官网下载,就会发现最新的版本已经是2.4.6了。下载可以选择一个完整的打包,或者逐个的rpm根据需求来安装也可以。完整的工具大概在60M左右。

而目前的MySQL版本大多都在5.5, 5.6, 对于5.7相对来说要新一些。中间会有一些时间的过渡,在多年前,可能相对来说用2.0版本一下的还比较多。

XtraBackup其实包含两个工具,一个是xtrabackup,另外一个是innobackupex。我们暂且以一个较早的版本作为演示,然后使用新版本来对比下。

# xtrabackup --version xtrabackup version 1.6.5 for Percona Server 5.1.59

innobackupex --version InnoDB Backup Utility v1.5.1-xtrabackup; Copyright 2003, 2009 Innobase Oy and Percona Inc 2009-2012. All Rights Reserved.

可以看到这两个工具的版本还有一些差别,

xtrabackup主要是用于热备份innodb,或者是 xtradb表中数据的工具,不能备份其他类型的表,也不能备份数据表结构;

innobackupex是将xtrabackup进行封装的perl脚本,可以备份和恢复MyISAM表以及数据表结构。

所以总体来看InnoDB的使用场景虽然最为普遍,但是还得考虑到MyISAM,两者总体来说,使用innobackex的场景会多一些。

备份浅析

使用innobackupex备份,命令选项还不少,可以使用innobackupex --help来查看明细的参数使用。

比如我需要做一个全备。可以采用如下类似的方式,在备份命令中加几个辅助选项,备份使用socket连接,备份目录在/home/databak/full/20170322下。

innobackupex --socket=/home/mysql/mysql.sock  /home/databak/full/20170322  --no-timestamp --no-lock --throttle=100

备份后查看对应的目录,备份的数据情况如下,其中红色的几个文件是备份中额外生成的。整体看来和源库的目录结构一样。

# du -sh ./* 2.6G ./backend 4.0K ./backup-my.cnf 646M ./gm 1.0G ./ibdata1 99M ./mobile_activity 5.0G ./mobile_billing 1.1M ./mysql 2.0G ./oem_mon 212K ./performance_schema 112K ./test 4.0K ./xtrabackup_binary 4.0K ./xtrabackup_checkpoints 4.0K ./xtrabackup_logfile

对于上面生成的文件,我们简单看一下。

binary结尾的文件是备份中用到的可执行文件,这个可以对应几个版本,比如xtrabackup_51,xtrabackup_55等

# more xtrabackup_binary xtrabackup_55

logfile结尾的文件的内容无法直接查看,但是可以用strings来看。通过strings解析可以看到对应的二进制日志,当然事务的Xid也有的。

# strings xtrabackup_logfile
xtrabkup 170322 16:33:40
{       ';{
        ';{
MySQLXid
./mysql-bin.000009
        393102654
08360000000039DB

下面的这个文件就更特别了,这个是作为数据的备份恢复的关键,里面有着备份恢复所有的检查点LSN,从下面的数据来看,这是一个全备,因为from_lsn=0.

# cat xtrabackup_checkpoints backup_type = full-backuped from_lsn = 0 to_lsn = 30754980731 last_lsn = 30754980731

而在源库的目录结构下,我们稍作过滤,也会得到一个几乎和这个工具备份出来一样的目录结构来。

# du -sh ./*|grep -v mysql-bin|grep -v innodb|grep -v log 2.6G ./backend 646M ./gm 1.0G ./ibdata1 4.5M ./ib_lru_dump 99M ./mobile_activity 5.0G ./mobile_billing 1.1M ./mysql 4.0K ./mysql.pid 0 ./mysql.sock 2.0G ./oem_mon 212K ./performance_schema 112K ./test

所以xtrabackup这样一个工具就是一个热备工具,有点类似有文件级别的拷贝,但是不止于此,我们往下看。

全库恢复模拟

数据恢复是DBA最重要的工作之一,多年之前,这个“之一“的字眼还要去掉。数据无法恢复,则备份无意义。

数据的恢复还是使用innobackupex这个工具,这是参数有些差别。

这里的数据恢复分为两个步骤,prepare和还原恢复,prepare的意义就在于,如果我们备份数据的时候,存在未提交的事务,但是数据却存在于备份中,这样就是一个数据不一致的状态,在启动数据库的时候需要走一个前滚,然后是一个回滚的操作。这个体现主要就在于logfile和ibdata。是使用apply-log这个选项实现的。

我们使用如下的方式来做。

innobackupex --defaults-file=/home/databak/full/20170322/backup-my.cnf --user=root --apply-log /home/databak/full/20170322

这个过程其实就会隐式调用xtrabackup_55这个可执行文件,调用的命令类似于:

xtrabackup_55 --defaults-file="/home/databak/full/20170322/backup-my.cnf"

默认会使用100M的内存,也可以使用选项--use-memory来调整,整个过程会重构redo日志文件和ibdata.

这个步骤完成之后就是最关键的地方了,还原恢复。这个过程是使用copy-back的选项实现的。

innobackupex --defaults-file=/home/databak/full/20170322/backup-my.cnf --user=root --copy-back /home/databak/full/20170322

整个过程就是大量的拷贝工作。

完成之后需要修改一下文件的属主,默认是root,然后启动即可。

增量备份恢复 我们接下来看看增量备份和恢复,先来创建一些数据。我们在数据库test下创建一个表test2.

> create table test2 (id int); Query OK, 0 rows affected (0.01 sec) > insert into test2 values(1),(2); Query OK, 2 rows affected (0.00 sec) Records: 2 Duplicates: 0 Warnings: 0

因为刚刚已经做了全备,我们继续做一个增备。

使用的命令如下:

innobackupex --defaults-file=/etc/my.cnf --user=root --incremental-basedir=/home/databak/incre/20170322 --incremental /home/databak/incre/20170322

但是很不幸,执行失败了。这个错误带有典型的意义。

170322 18:05:34 innobackupex: Starting ibbackup with command: xtrabackup_55 --defaults-file="/etc/my.cnf" --backup --suspend-at-end --target-dir=/home/databak/incre/20170322/2017-03-22_18-05-32 --incremental-basedir='/home/databak/incre/20170322' innobackupex: Waiting for ibbackup (pid=4079) to suspend innobackupex: Suspend file '/home/databak/incre/20170322/2017-03-22_18-05-32/xtrabackup_suspended' ... xtrabackup: Error: cannot open /home/databak/incre/20170322/xtrabackup_checkpoints xtrabackup: error: failed to read metadata from /home/databak/incre/20170322/xtrabackup_checkpoints innobackupex: Error: ibbackup child process has died at /usr/bin/innobackupex line 349.

原因就在于里面的一个关键文件 _checkpoints

使用增备得有一个参考点,从哪里开始,即从哪个LSN开始,这个LSN在指定的参数--incremental-basedir=/home/databak/incre/20170322 下不存在,因为这个是一个新目录,所以需要指向全库备份的目录。

然后修复后备份就没问题了,英为有了这个参考点LSN,所以需要要说明的是这个备份其实有累计增量和差异增量了。

这个怎么理解呢,比如周日做一个全备,周一做一个增备,周二做一个周日全备到周二的一个增备,这就是一个累计增量备份,而周三的时候做一个周二至周三数据变化的备份,就是一个差异增量备份。

下面的是一个累计增量备份。因为基准是上次的一个全备,备份后会自动生成一个目录,比如 2017-03-22_18-07-38

innobackupex --defaults-file=/etc/my.cnf --user=root --incremental-basedir=/home/databak/full/20170322 --incremental /home/databak/incre/20170322

为了区别两次增量,我继续插入两行数据。

> insert into test2 values (3),(4); Query OK, 2 rows affected (0.00 sec)

这样表test2就有4条数据了,每次插入2条。

下面的是一个差异增量备份。基于上一次的增备。

innobackupex --defaults-file=/etc/my.cnf --user=root --incremental-basedir=/home/databak/incre/20170322/2017-03-22_18-07-38 --incremental /home/databak/incre/20170322

整个恢复的过程是下面的形式,还是一个prepare的过程,首先是全备:

innobackupex --defaults-file=/etc/my.cnf --user=root --apply-log --redo-only /home/databak/full/20170322然后是增备,注意这里标红的参数。

innobackupex --defaults-file=/etc/my.cnf --user=root --apply-log --redo-only /home/databak/full/20170322 --incremental-dir=/home/databak/incre/20170322/2017-03-22_18-07-38

这样做其实是一个merge的过程,对于增备来说,会生成如下的几个文件,都是.delta, .meta之类的文件。

[test]# ll total 132 -rw-r--r-- 1 mysql mysql 61 Mar 22 17:58 db.opt -rw-rw---- 1 mysql mysql 8556 Mar 22 18:03 test2.frm -rw-r--r-- 1 root root 81920 Mar 22 18:08 test2.ibd.delta -rw-r--r-- 1 root root 18 Mar 22 18:08 test2.ibd.meta

增备目录下的checkpoint文件就有意思了。有一个很清晰的LSN的增量描述。

[ 2017-03-22_18-07-38]# cat *checkpoints backup_type = incremental from_lsn = 30754980731 to_lsn = 30754984465 last_lsn = 30754984465

而prepare之后的全备里面的checkpoint文件其实已经发生了变化

# cat *checkpoints backup_type = full-prepared from_lsn = 0 to_lsn = 30754984465 last_lsn = 30754984465

这个时候我们使用如下的方式来还原恢复。

#innobackupex --defaults-file=/etc/my.cnf --user=root --copy-back /home/databak/incre/20170322/2017-03-22_18-07-38

这个时候表test2里面的数据是几条? 是2条。

这个过程我们相当于完成了一个全备+一个增备的数据恢复过程。

而我们在一个增备之后又插入了一些数据,这个怎么继续恢复呢,还是prepare的过程。这个路径需要注意,还是merge到全备中。

innobackupex --defaults-file=/etc/my.cnf --user=root --apply-log --redo-only /home/databak/full/20170322 --incremental-dir=/home/databak/incre/20170322/2017-03-22_18-11-26

继续还原恢复。

innobackupex --defaults-file=/etc/my.cnf --user=root --copy-back /home/databak/full/20170322

再次查看数据,我们要恢复的4条数据都恢复回来了。

> select *from test2; +------+ | id | +------+ | 1 | | 2 | | 3 | | 4 | +------+ 4 rows in set (0.06 sec)

备份中的选项补充

innobackupex中的选项很多,有几个还是比较有特色的,比如stream选项,--slave-info选项能够方便搭建从库,生成偏移量的信息,比如并行--parallel等,还可以根据LSN来备份,选项是--incremental-lsn

对于stream选项,默认是打包,可以结合管道来实现压缩,比如:innobackupex --defaults-file=/etc/my.cnf --user=root --stream=tar /home/databak/full/20170322_2 | gzip > /home/databak/full/20170322_2/20170322_2.tar.gz

备份中的常用场景

很多时候其实我不想备份整个库,我只想备份一个表,那么这个操作如何来实现呢。

innobackupex --defaults-file=/etc/my.cnf --user=root --include='test.test2' /home/databak/full/20170322_2

这里有几点需要注意,工具还是会逐个去扫描,只是那些不符合的会被忽略掉,也就意味着备份出来的情况和全备的目录结构是一样的,但是指定的表会备份出ibd,frm文件。

[test]# ll total 1036 -rw-r--r-- 1 mysql mysql 8556 Mar 22 18:34 test2.frm -rw-r--r-- 1 root root 1048576 Mar 22 19:26 test2.ibd [ test]# cd ../mysql [ mysql]# ll total 0

而且有一点值得吐槽一下的是,ibdata也会完整备份出来,如果这个文件很大,那就相当不给力了。

不过也别对这种备份失去信心,有一个场景还是很实用的。那就是迁移表。

迁移表

还是刚刚的这个场景,如果表test2需要拷贝到另外一套环境中,我们可以使用Innobackupex来做物理备份,然后还原导入,达到迁移的目的。

下面的命令会声明指定目录下的备份需要导出对象。

innobackupex --apply-log --export /home/databak/full/20170322_2/2017-03-22_19-26-46

这个过程的直接产物就是生成了一个.exp文件,在MySQL原生版本中是.cfg文件

[ test]# ll total 1052 -rw-r--r-- 1 root root 16384 Mar 22 19:29 test2.exp -rw-r--r-- 1 mysql mysql 8556 Mar 22 18:34 test2.frm -rw-r--r-- 1 root root 1048576 Mar 22 19:26 test2.ibd

对表test2做数据信息截断。

> alter table test2 discard tablespace; Query OK, 0 rows affected (0.07 sec)

然后就是物理拷贝,复制.exp文件和.ibd文件到指定目录下,修改属主权限。

然后使用import的方式即可完成导入。

> alter table test2 import tablespace; Query OK, 0 rows affected (0.00 sec)

有另外一点值得说的是,这个.exp文件是不是必须的,其实也不是。

我们只拷贝.ibd文件也照样可以。可能在新版本中会有一些警告提示,我们重新来做一下。

[test]> alter table test2 discard tablespace; Query OK, 0 rows affected (0.03 sec)

同时删除刚刚拷贝过来的.exp文件。

然后拷贝ibd文件到指定目录,赋权限

导入表空间信息。

[test]> alter table test2 import tablespace; Query OK, 0 rows affected (0.00 sec)

查看数据的情况,发现数据还是回来了。

[test]> select *from test2; +------+ | id | +------+ | 1 | | 2 | | 3 | | 4 | +------+ 4 rows in set (0.00 sec)

当然这个过程中还是有很多需要注意的地方。

原文发布于微信公众号 - 杨建荣的学习笔记(jianrong-notes)

原文发表时间:2017-03-22

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏有困难要上,没有困难创造困难也要上!

CentOS5.5使用yum时报错Error: Cannot find a valid baseurl for repo: addons

421100
来自专栏运维技术迷

试试Linux下的ip命令

linux的ip命令和ifconfig类似,但前者功能更强大,并旨在取代后者。使用ip命令,只需一个命令,你就能很轻松地执行一些网络管理任务。ifconfig是...

48350
来自专栏Aloys的开发之路

如何发布Maven依赖到中央仓库

平时我们都是从Maven中央仓库下载依赖,如果我们想发布我们自己写的Maven依赖到中央仓库供别人下载使用应该怎么办?这里以上传自己写的simian-maven...

36530
来自专栏Java进阶架构师

「mysql优化专题」主从复制面试宝典!面试官都没你懂得多!(11)

主从复制,是用来建立一个和主数据库完全一样的数据库环境,称为从数据库;主数据库一般是准实时的业务数据库。

12230
来自专栏Java学习123

ORA-28000: the account is locked的解决办法

30580
来自专栏我的博客

同步文件Rsync命令

环境 A:10.200.11.224 B:10.200.11.230 需求:将A机器上文件推送到B机器 将A机器的pubkey添加到B机器authori...

501100
来自专栏喵了个咪的博客空间

Otter-入门篇2(Manager安装配置)

Otter-入门篇2(Manager安装配置) ? 前言 上一节已经简单介绍了Otter的基本信息,本节我们就来开准备搭建一个我们自己的Otter环境,因为一个...

449110
来自专栏张首富-小白的成长历程

用户相关的文件及命令

Linux system每个文件和进程,都需要对应一个用户和组, Linux system是通过UID和GID来识别用户和组的。用户名相当于人名,UID相当于×...

14740
来自专栏程序员的诗和远方

React-Native For Android 环境搭建及踩坑

安装环境 本文默认以MacOS为系统,毕竟除了用React Native搞Android,你也会想用它搞iOS。 首先当然是Android的环境搭建,这里还是推...

34160
来自专栏文渊之博

SQLServer 延迟事务持久性

SQL Server 2014新功能 -- 延迟事务持久性(Delayed Transaction Durability) SQL Server事务提交默认...

26280

扫码关注云+社区

领取腾讯云代金券