MySQL 备份恢复（四）

前面三篇已经介绍了 MySQL 备份相关的原理与方法，要是还没有来得及看的可以戳此查看『MySQL 备份恢复（三）』，那么今天就接着继续谈谈备份恢复相关内容之 Xtrabackup 的原理、安装与使用，备份恢复最后一篇，文章不是有点长，而是很长，请耐心看完。

目录

XtraBackup 简介

XtraBackup 原理

Xtrabackup 优点

XtraBackup 备份过程

XtraBackup 安装

XtraBackup 备份恢复操作

XtraBackup 简介

热备中主要有逻辑备份和裸文件备份，裸文件备份要比逻辑备份在速度上快一些，mysqldump 备份方式是采用的逻辑备份，其最大的缺陷是备份和恢复速度较慢，如果数据库大于 50G，mysqldump 备份就不太适合。而 XtraBackup 是一种物理备份工具，支持热备，在备份时复制所有 MySQL 的数据文件以及一些事务日志信息，在还原时将复制的数据文件放回至 MySQL 数据目录，并应用日志保证数据一致。

XtraBackup 是 percona 公司的开源项目，据官方介绍它是世界上唯一一款开源的能够对 InnoDB 和 XtraDB 数据库进行热备的工具。Xtrabackup 有两个主要的工具：xtrabackup、innobackupex。innobackupex 是 XtraBackup 的一个软连接，之前的版本 innobackupex 是一个 perl 脚本，它既可以备份 InnoDB 表，也可以备份 MyISAM 这类非事务表的需要，但会在备份过程中锁表。

XtraBackup 原理

对于 InnoDB 来说，XtraBackup 是基于 InnoDB 的 crash recovery 功能进行备份的。crash recovery 则是在 InnoDB 内部维护了一个 redo log，又叫事务日志 transaction log，它包含了 InnoDB 数据的所有更改信息；在 InnoDB 启动时，会先检查 datafile 和 transaction log ,然后前滚所有已提交的事务并回滚所有未提交的事务。

XtraBackup 在备份时并不会锁表，而是一页页地去复制 InnoDB 的数据，这样复制出来的数据是不一致的。要想保证数据的一致性，需要在恢复时使用 crash recovery 进行操作，XtraBackup 还有另外一个线程监视着 redo log ,当 redo log 写满之后发生变化，则会去复制变化过的 log pages。在复制全部数据文件完之后，停止复制 redo log。

Xtrabackup 优点

1、备份速度快，物理备份可靠

2、备份过程不会打断正在执行的事务（无需锁表）

3、能够基于压缩等功能节约磁盘空间和流量

4、自动备份校验

5、还原速度快

6、可以流传将备份传输到另外一台机器上

7、在不增加服务器负载的情况备份数据

XtraBackup 备份过程

整个过程如下图所示：

MySQL 备份恢复（四）

来源：http://mysql.taobao.org/monthly/2016/03/07/

XtraBackup 安装

软件下载地址（注意此地址也会动态变化，如无法访问，请前去官方查看下载）

https://www.percona.com/downloads/Percona-XtraBackup-2.4/LATEST/

注意：下载时需要找到对应的安装包，否则若安装版本过高会报错，请按照正确的方式下载安装。

[root@JiekeXu bin]# ./innobackupex --version

此报错是没有动态库中要求的 GCC 版本 “GLIBCXX_3.4.15”，所以需要进行升级一下我们的 GCC 版本，但没有网络 yum 源，故无法安装。

MySQL 备份恢复（四）

下载完之后上传至服务器，然后可解压，注意的是需要下载对应系统的包，这里坑比较多，没有网络 yum 源要更加注意。

我这里的环境是 Red Hat Enterprise Linux Server release 6.7。执行以下命令安装：

[root@JiekeXu percona-xtrabackup]# cat /etc/issue

MySQL 备份恢复（四）

这样就算安装完成了，折腾这么久算完事了，可以好好的玩耍了，使用innobackupex --help 查看更多帮助命令。

XtraBackup 备份恢复操作

1****、创建备份账号

我们可以使用 MySQL 的 root 用户进行备份工作，也可以单独创建一个用于数据库备份的用户，过程如下。

CREATE USER 'backupdbuser'@'192.168.8.8' IDENTIFIED BY 'backupdbuser';

为 backupdbuser 用户授权，如下权限为正常备份的最小权限

GRANT RELOAD,LOCK TABLES,REPLICATION CLIENT,PROCESS ON *.* TO ' backupdbuser'@'192.168.8.8';

如果使用到某些高级备份功能，还需要其他权限的授权，例如 CREATE TABLESPACE、CREATE、INSERT、SELECT、SUPER 等，可根据实际情况添加，具体权限对应的高级功能可查看官方手册。

MySQL 备份恢复（四）

创建完账号，当然得建立一个备份的目录了，我们选择一个比较合适的目录存放备份数据，并在开始全备时不采用系统默认的备份集文件名称，使用 --no-timestamp 参数，自己重命名文件，。这里为 all_2019-05-04_bak。

mkdir –p /opt/backup

2****、全备命令如下：

innobackupex --defaults-file=/etc/my.cnf --no-timestamp --user backupdbuser --host 192.168.8.8  --password backupdbuser /opt/backup/all_2019-05-04_bak

MySQL 备份恢复（四）

使用此命令便开始备份了，看备份的日志，有开始备份时显示 MySQL 配置信息，提示信息、备份使用账号、版本号、备份工具依赖版本号等等信息。

MySQL 备份恢复（四）

备份结束时，最后会显示 completed OK！

3****、备份内容

MySQL 备份恢复（四）

现在来看看备份都备了些啥，从上图中可以看出，备份的有配置文件 my.cnf、buffer_pool、ibdata1 以及 testdb 等各个数据库，剩下就就是以 xtrabackup 开头的四个文件。

xtrabackup_binlog_info 文件记录二进制日志和偏移量，若开启了 gtid 功能，还记录了 gtid 位置信息，为在线搭建从库做准备。

xtrabackup_checkpoints 文件记录了备份类型，full-backuped 为全备，以及开始和结束的 lsn 号等信息。

xtrabackup_info 文件记录了备份的详细信息，如备份命令，备份工具版本号、MySQL 版本号、备份开始和结束时间，binlog 以及 gtid 信息。

xtrabackup_logfile 文件是二进制文件，不能通过普通的 cat、more 等命令打开，需要使用 strings xtrabackup_logfile 打开。

MySQL 备份恢复（四）

4****、利用全备恢复数据

假设有运维人员不小心将数据库 testdb 删除，那么数据库中的表也将不复存在。

MySQL 备份恢复（四）

报错了，首先想到的是查看日志，DBA 利用二进制日志能否查看到蛛丝马迹，又因为二进制日志无法打开，则通过系统自带的 mysqlbinlog 命令解析出可查看的日志来。通过分析数据库 testdb 被删除了，则只能利用备份恢复了。

[root@JiekeXu mysql]# /usr/local/mysql/bin/mysqlbinlog  --no-defaults -v -v--base64-output=decode-rows /opt/mysql/mysql-binlog.000009 > bin.log

MySQL 备份恢复（四）

恢复时需要加参数 --apply-log ，此参数作用主要是通过回滚未提交的事务及同步已经提交的事务至数据文件，使数据库的数据文件保持一致性。

innobackupex --defaults-file=/etc/my.cnf  --no-timestamp --user backupdbuser --host 192.168.8.8  --password backupdbuser --apply-log  /opt/backup/all_2019-05-04_bak

MySQL 备份恢复（四）

当出现 “**completed OK!**” 则证明备份集校检成功，离最后的恢复只差一步了。

最后，先将 MySQL 实例停掉，重命名原来的数据目录，改备份 /opt/backup/all_2019-05-04_bak 为 /opt/mysql，并赋予 mysql 权限，重启实例，具体命令如下所示。

mysqladmin -u root -p root shutdown

MySQL 备份恢复（四）

恢复完成了，但是数据文件中比原来备份多了xtrabackup_binlog_pos_innodb 文件，此文件中记录了 binlog 文件和 position 号，在搭建主从架构时，如果均是 InnoDB 引擎表，则 xtrabackup_binlog_pos_innodb 此文件记录的是标准的 binlog 和 position 号，如若有其他混合引擎，则以 xtrabackup_binlog_info 文件记录的为准。

MySQL 备份恢复（四）

5****、Xtrabackup 增量备份

增量备份，顾名思义是在全量基础上的备份，第一次的增量备份必须要基于上一次的全备，之后的每次增备都是基于上一次的增备，最终达到一致性的增备。

先做一次全备，然后查看表 t ，然后在插入数据，做一次增备，查看备份的相关信息，然后在做一次增备，检查备份相关信息后模拟故障删除表 t ,实现一个增量备份恢复的过程。

innobackupex --defaults-file=/etc/my.cnf --no-timestamp --user backupdbuser --host 192.168.8.8  --password backupdbuser/opt/backup/all_2019-05-09_bak

MySQL 备份恢复（四）

以上查看了表中的数据，在看一眼 xtrabackup_checkpoints 文件中 full-backuped 全备，from_lsn 初始值为 0，结束时的 to_lsn 值为 2567739。接着在表 t 里插入数据。

insert into t (id,name,sex) values(4,'xh','man');

插入完数据后，就已经到 5 月 10 日了，今天有一个增量备份，增备需要添加一个参数 --incremental ，增备的文件为 /opt/backup/all_2019-05-10_incr 。而且要使用 --incremental_basedir 参数代表在全备的基础上做增备。

增备命令如下：

innobackupex --defaults-file=/etc/my.cnf --no-timestamp --user backupdbuser --host 192.168.8.8  --password backupdbuser --incremental  /opt/backup/all_2019-05-10_incr --incremental_basedir=/opt/backup/all_2019-05-09_bak

MySQL 备份恢复（四）

增备完成后，来瞅一眼 xtrabackup_checkpoints 文件，备份类型是增备，备份开始的 lsn 是上个全备结束的 lsn 为 2567739，之后的备份以此类推。那么，我么在往表 t 插入一条数据：

root@db 23:56:  [testdb] insert into t (id,name,sex) values(7,'mjz','f');

假设已经过了一天了，然后我们来进行第二次增量备份操作，这个备份是基于上个备份做的。命令如下：

innobackupex --defaults-file=/etc/my.cnf --no-timestamp --user backupdbuser--host 192.168.8.8  --password backupdbuser --incremental /opt/backup/all_2019-05-11_incr --incremental_basedir=/opt/backup/all_2019-05-10_incr

备份成功后在来看一下 lsn 和备份类型，这个的备份类型还是增备，起始的 lsn 是上一个增备结束的 lsn .

cat /opt/backup/all_2019-05-11_incr/xtrabackup_checkpoints

MySQL 备份恢复（四）

6****、Xtrabackup 增量备份的恢复

首先模拟故障将表 t 删除：

use testdb;

首先在恢复的过程中将全备恢复，然后将两个增量备份恢复到全备中，在停掉实例，替换原来的数据文件目录，更改权限重启即可。值得注意的是前两个过程需要添加参数 --redo-only,它意味着只前滚 Xtrabackup 备份中已经提交的事务，并不回滚那些还没有提交的事务信息。最后一个过程就是对整体全备进行恢复，这时可以去掉 --redo-only 参数了，意味着需要回滚那些还没有提交的事务。

恢复过程如下：

全备恢复：

innobackupex --defaults-file=/etc/my.cnf  --user backupdbuser --host 192.168.8.8 --password backupdbuser --apply-log --redo-only /opt/backup/all_2019-05-09_bak

第一个增量备份恢复到全备中：

innobackupex --defaults-file=/etc/my.cnf  --user backupdbuser --host 192.168.8.8 --password backupdbuser --apply-log --redo-only /opt/backup/all_2019-05-09_bak  --incremental-dir=/opt/backup/all_2019-05-10_incr

第二个增量备份恢复到全备中：

innobackupex --defaults-file=/etc/my.cnf  --user backupdbuser --host 192.168.8.8 --password backupdbuser --apply-log --redo-only /opt/backup/all_2019-05-09_bak  --incremental-dir=/opt/backup/all_2019-05-11_incr

第三次恢复，将前面新恢复的备份进行一次完全恢复，回滚那些还未提交的数据。注意：这一次不需要添加--redo-only 参数了。

innobackupex --defaults-file=/etc/my.cnf  --user backupdbuser --host 192.168.8.8 --password backupdbuser --apply-log  /opt/backup/all_2019-05-09_bak

这时，文件中已经恢复了所有的数据，剩下的就是关库，替换数据目录，赋权，重启，相关命令如下：

mysqladmin –uroot –proot shutdown

MySQL 备份恢复（四）

7****、Xtrabackup 流式化备份

流式化备份可以理解为不占用本地磁盘空间，节省本地服务器磁盘空间，流式化备份有两个输出格式，一种是基于 tar 格式的，一种是基于 xbstream 的，这里主要看一下 tar 格式的备份。

流式化备份重要的一个参数就是 --stream,有压缩格式和非压缩格式。

innobackupex  --defaults-file=/etc/my.cnf --no-timestamp --user backupdbuser --host 192.168.8.8  --password backupdbuser --stream=tar /tmp  |gzip - >/opt/backup/all_20190512.tar.gz



innobackupex  --defaults-file=/etc/my.cnf --no-timestamp --user backupdbuser --host 192.168.8.8  --password backupdbuser --stream=tar /tmp > /opt/backup/all.tar

MySQL 备份恢复（四）

远程备份

远程备份就是考虑到数据库的数据量巨大，几个 T 的数据存放到本地磁盘太占空间，则考虑到远程服务器。首先配置好两台服务器的互信，建立远程服务器上的备份目录，利用 SSH 远程登录。

innobackupex  --defaults-file=/etc/my.cnf --no-timestamp --user backupdbuser --host 192.168.8.8  --password backupdbuser --stream=tar /tmp  |gzip |ssh root@192.168.8.9 "cat - > /data2/backup/all_2019-05-12.tar.gz"

看到这里就结束了，感谢您的阅读，佩服您的耐心，能够看完全文，非常感谢。MySQL 备份相关的知识点应该是全部结束了，其他几篇可以查看历史记录。备份恢复的时候翻出来瞅瞅，大概率是有帮助的，有帮助我也很欣慰，好久没开过赞赏了，要是下面能出现你的头像，那我会更加欣慰的!

在这母亲节之际，拿起手机打个电话发个视频，多点陪伴多点关怀，唠唠家常，比铺天盖地的朋友圈的祝福好上千倍万倍！另外，今天是“5·12****全国防灾减害日”，还记得 5·12 汶川地震么？还记得那些可爱的人儿吗？十一年，美好的人生，美好的时光，一生能有多少个十一年，且行且珍惜！