使用xtrabackup对mariadb数据库进行增量备份以及恢复

时间  2020-07-19
标签 使用 xtrabackup mariadb 数据库 进行 增量 备份 以及 恢复 栏目 SQL 繁體版
原文   原文链接

因为最近的老生常谈的问题，zabbix数据库里面的数据量开始愈来愈大了，常规的mysqldump工具有份数据库的时候将致使zabbix服务异常，产生大量报警。因而，就有了以前那篇文章关于zabbix数据库的备份以及表分区。mysql

由于个人zabbix是使用的innodb存储引擎，而percona公司开发的xtradbbackup数据库备份软件对于innodb数据库备份比mysqldump效率高不少，并且能够实现增量备份，不锁表备份。因此很适合个人需求，今天闲来无事就来研究一下xtradbbackup这款数据库备份工具。sql

首先，须要在percona官网下载xtradbbackup，连接在这：https://www.percona.com/downloads/XtraBackup/LATEST/ 数据库

能够下载源码包安装，也能够下载rpm包安装，我这里下载的是centos 7的rpm包安装的，包名是：percona-xtrabackup-2.2.12-1.el7.x86_64.rpmcentos

在安装rpm包以前须要安装bash

yum -y install perl-DBD-MySQL

以后安装的时候发现还有两个报错，须要安装两个包：服务器

yum -y install libaio
yum -y install perl-Digest-MD5

而后再安装xtradbbackup：app

rpm -ivh percona-xtrabackup-2.2.12-1.el7.x86_64.rpm

安装好后可使用innobackupex --help查看命令参数。ide


语法：innobackupex --user=DBUSER --password=DBUSERPASS  /path/to/BACKUP-DIR/工具

/path/to/BACKUP-DIR/文件为xtrabackup的备份文件，在备份的同时，innobackupex还会在备份目录中建立以下文件：测试

xtrabackup_checkpoints —— 备份类型（如彻底或增量）、备份状态（如是否已经为prepared状态）和LSN(日志序列号)范围信息； 每一个InnoDB页(一般为16k大小)都会包含一个日志序列号，即LSN。LSN是整个数据库系统的系统版本号，每一个页面相关的LSN可以代表此页面最近是如何发生改变的。 

xtrabackup_binlog_info —— mysql服务器当前正在使用的二进制日志文件及至备份这一刻为止二进制日志事件的位置。 

xtrabackup_binlog_pos_innodb —— 二进制日志文件及用于InnoDB或XtraDB表的二进制日志文件的当前position。 

xtrabackup_binary —— 备份中用到的xtrabackup的可执行文件； 

backup-my.cnf —— 备份命令用到的配置选项信息；

   说明：在使用innobackupex进行备份时，还可使用--no-timestamp选项来阻止命令自动建立一个以时间命名的目录；如此一来，innobackupex命令将会建立一个BACKUP-DIR目录来存储备份数据。

经常使用选项：

--defaults-file            #数据库的配置文件路径，感受本地备份不写也能够，远程没测试过。

--apply-log                #准备在一个备份上启动mysql服务。

--copy-back               #从备份目录拷贝数据，索引，日志到my.cnf文件里规定的初始位置。

--no-timestamp         #建立备份时不自动生成时间目录，能够自定义备份目录名例如： /backups/mysql/base 

--databases                #用于指定要备份的数据库, 多个库文件使用方法: “database1 database2″ 

--incremental             #在全备份的基础上进行增量备份，后跟增量备份存贮目录路径 

--incremental-basedir=DIRECTORY      #增量备份所须要的全备份路径目录或上次作增量备份的目录路径 

--incremental-dir=DIRECTORY             #增量备份存贮的目录路径 

--redo-only                 #用于准备增量备分内容把数据合并到全备份目录，配合–incremental-dir 增量备份目录使用。 

--force-non-empty-directories            #若是是特定库备份还原，不须要删掉整个mysql目录，只是特定库的及相关文件就能够，还原时加上此参数就不会报错。

好了，接下来就须要测试使用xtradbbackup对数据库进行全备以及恢复的过程了。


首先建立备份目录：

mkdir -p /opt/backup

注意在使用innobackupex进行备份时，还可使用--no-timestamp选项来阻止命令自动建立一个以时间命名的目录；如此一来，innobackupex命令将会建立一个BACKUP-DIR目录来存储备份数据。

innobackupex --user=root --password=xxxxxx /opt/backup （PS:该状况将会自动在/opt/backup下面建立一个以时间命名的全备目录）
innobackupex --user=root --password=xxxxxx --no-timestamp /opt/backup1(PS:这样将会在/opt/backup1目录下生成全备的文件及目录)

下面是备份出来的目录文件：

ls 2015-10-12_16-09-18/
backup-my.cnf  CrazyEyes  ibdata1  mysql  performance_schema  test  xtrabackup_binlog_info  xtrabackup_checkpoints  xtrabackup_info  xtrabackup_logfile  zabbix

备份的文件说明：

(1)xtrabackup_checkpoints —— 备份类型（如彻底或增量）、备份状态（如是否已经为prepared状态）和LSN(日志序列号)范围信息；

每一个InnoDB页(一般为16k大小)都会包含一个日志序列号，即LSN。LSN是整个数据库系统的系统版本号，每一个页面相关的LSN可以代表此页面最近是如何发生改变的。

cat xtrabackup_checkpoints 
backup_type = full-backuped        #注明这是全备
from_lsn = 0                  #全备的lsn起始号
to_lsn = 2026561686             #全备记录到的最大序列号
last_lsn = 2026562643           #全备完成后当前的日志序列号
compact = 0                  #注明没有进行打包

(2)xtrabackup_binlog_info —— mysql服务器当前正在使用的二进制日志文件及至备份这一刻为止二进制日志事件的位置。

cat xtrabackup_binlog_info 
mysql-bin.0000011371180-1-175

(3)backup-my.cnf —— 备份命令用到的配置选项信息和备份无关的不会记录，备份配置文件的话须要单独备份。

cat backup-my.cnf 
# This MySQL options file was generated by innobackupex.
# The MySQL server
[mysqld]
innodb_checksum_algorithm=innodb
innodb_log_checksum_algorithm=innodb
innodb_data_file_path=ibdata1:12M:autoextend
innodb_log_files_in_group=2
innodb_log_file_size=50331648
innodb_page_size=16384
innodb_log_block_size=512
innodb_undo_directory=.
innodb_undo_tablespaces=0

(4)xtrabackup_info —— 记录了mariadb的版本信息和一些属性信息，还原是检测版本匹配度时用到。

cat xtrabackup_info 
uuid = a2443721-70b8-11e5-ae53-000c29bc81b7
name = 
tool_name = innobackupex
tool_command = --user=root --password=... /backup/
tool_version = 1.5.1-xtrabackup
ibbackup_version = xtrabackup version 2.2.12 based on MySQL server 5.6.24 Linux (x86_64) (revision id: 8726828)
server_version = 10.0.17-MariaDB-log
start_time = 2015-10-12 16:09:18
end_time = 2015-10-12 16:10:00
lock_time = 3
binlog_pos = filename 'mysql-bin.000001', position 137118, GTID of the last change '0-1-175'
innodb_from_lsn = 0
innodb_to_lsn = 2026561686
partial = N
incremental = N
format = file
compact = N
compressed = N

建立好备份文件后这时数据尚且不能用于恢复操做，由于备份的数据中可能会包含还没有提交的事务或已经提交但还没有同步至数据文件中的事务。所以，此时数据文件仍处于不一致状态。“准备”的主要做用正是经过回滚未提交的事务及同步已经提交的事务至数据文件也使得数据文件处于一致性状态。

须要使用innobakupex命令的--apply-log选项来使数据文件同步。

innobackupex --apply-log 2015-10-12_16-09-18
同步后的目录结构：
ls 2015-10-12_16-09-18
backup-my.cnf  ibdata1      ib_logfile1  performance_schema  xtrabackup_binlog_info        xtrabackup_checkpoints  xtrabackup_logfile
CrazyEyes      ib_logfile0  mysql        test                xtrabackup_binlog_pos_innodb  xtrabackup_info         zabbix

在实现“准备”的过程当中，innobackupex一般还可使用--use-memory选项来指定其可使用的内存的大小，默认一般为100M。若是有足够的内存可用，能够多划分一些内存给prepare的过程，以提升其完成速度。

命令以下：

innobackupex --user=root --password=xxxxx --no-timestamp --use-memory=500MB /backup2

设定准备数据时使用的内存限定为500M,而且不建立以时间命名的文件夹。


模拟数据库损坏以及恢复数据：

首先，删除mysql数据库的data目录下的全部数据：

rm -fr /data/mysql/*
ll /data/mysql/

总用量 0

这时候没法直接关闭数据库：

service mysqld stop
 ERROR! MySQL server PID file could not be found!

可使用pkill杀死数据库主进程：

pkill mysql
ps aux|grep mysql
root     27381  0.0  0.0 112656   976 pts/1    R+   18:10   0:00 grep --color=auto mysql

而后检查数据库配置文件中是否在[mysqld]设置了datadir路径（PS:若是这里没有设置路径的话在恢复数据的时候将会报错，我这里设置的路径为：datadir=/data/mysql）

my.cnf文件所在路径为/etc/my.cnf

如今须要进行数据恢复：

（PS:在还原数据以前，首先须要检查datadir路径中是否含有文件，假如含有文件，恢复时将会报错）

innobackupex命令的--copy-back选项用于执行恢复操做，其经过复制全部数据相关的文件至mysql服务器DATADIR目录中来执行恢复过程。innobackupex经过backup-my.cnf来获取DATADIR目录的相关信息。

语法：

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

当数据恢复至DATADIR目录之后，还须要确保全部数据文件的属主和属组均为正确的用户，如mysql，不然，在启动mysqld以前还须要事先修改数据文件的属主和属组。

innobackupex --copy-back /backup2/

就能够恢复数据了。以后修改数据库datadir路径的文件属主和属组：

chown -R mysql.mysql /data/mysql/

这时候能够正常的启动数据库了。

service mysqld start
Starting MySQL. SUCCESS!

这个时候启动起来是从新记录二进制日志的。这样，一次全备以及数据库全备恢复的过程就结束了。


数据库增量备份以及对增量备份数据恢复：

提示：在恢复完成以后应该再次作一次彻底备份，后期的增量备份都依照此次的彻底备份来作。

innobackupex --user=root --password=xxxxxx --use-memory=500MB /backup3
innobackupex --apply-log /backup3/2015-10-13_08-48-25/
ls /backup3
2015-10-13_08-48-25


以后就可使用innobackupex进行增量备份

每一个InnoDB的页面都会包含一个LSN信息，每当相关的数据发生改变，相关的页面的LSN就会自动增加。这正是InnoDB表能够进行增量备份的基础，即innobackupex经过备份上次彻底备份以后发生改变的页面来实现。

要实现第一次增量备份，可使用下面的命令进行：

innobackupex --user=root --password=xxxxxx --incremental /backup/ --incremental-basedir=BASEDIR

其中，BASEDIR指的是彻底备份所在的目录，此命令执行结束后，innobackupex命令会在/backup/目录中建立一个新的以时间命名的目录以存放全部的增量备份数据。另外，在执行过增量备份以后再一次进行增量备份时，其--incremental-basedir应该指向上一次的增量备份所在的目录。

须要注意的是，增量备份仅能应用于InnoDB或XtraDB表，对于MyISAM表而言，执行增量备份时其实进行的是彻底备份。

命令以下：

第一次增量备份：innobackupex --user=root --password=xxxxxx --incremental /backup3/ --incremental-basedir=/backup3/2015-10-13_08-48-25/
第二次增量备份：innobackupex --user=root --password=xxxxxx --incremental /backup3/ --incremental-basedir=/backup3/2015-10-13_08-52-12/

“准备”(prepare)增量备份与整理彻底备份有着一些不一样，尤为要注意的是：

(1)须要在每一个备份(包括彻底和各个增量备份)上，将已经提交的事务进行“重放”。“重放”以后，全部的备份数据将合并到彻底备份上。

(2)基于全部的备份将未提交的事务进行“回滚”。 

因而，操做就变成了：

innobackupex --apply-log --redo-onlyBASE-DIR
innobackupex --apply-log --redo-only /backup3/2015-10-13_08-48-25/
接着执行：
innobackupex --apply-log --redo-only BASE-DIR --incremental-dir=INCREMENTAL-DIR-1
innobackupex --apply-log --redo-only /backup3/2015-10-13_08-48-25/ --incremental-dir=/backup3/2015-10-13_08-52-12/
然后是第二个增量：
innobackupex --apply-log --redo-only BASE-DIR --incremental-dir=INCREMENTAL-DIR-2
innobackupex --apply-log --redo-only /backup3/2015-10-13_08-48-25/ --incremental-dir=/backup3/2015-10-13_08-52-59/

             

其中BASE-DIR指的是彻底备份所在的目录，而INCREMENTAL-DIR-1指的是第一次增量备份的目录，INCREMENTAL-DIR-2指的是第二次增量备份的目录，其它依次类推，即若是有屡次增量备份，每一次都要执行如上操做；

cat /backup3/2015-10-13_08-48-25/xtrabackup_checkpoints 
backup_type = log-applied
from_lsn = 0
to_lsn = 2063010964
last_lsn = 2063010964
compact = 0
cat /backup3/2015-10-13_08-52-59/xtrabackup_checkpoints 
backup_type = incremental
from_lsn = 2062984015
to_lsn = 2063010964
last_lsn = 2063010964
compact = 0

能够看到目前全部的增量备份都还原到了全备上面，这时候就能够进行数据恢复了。

rm -fr /data/mysql/*
pkill mysql
ps aux|grep mysql
root     15699  0.0  0.0 112656   980 pts/1    R+   09:29   0:00 grep --color=auto mysql
rm -fr /data/mysql/*
innobackupex --copy-back /backup3/2015-10-13_08-48-25/
chown -R mysql.mysql /data/mysql/
service mysqld start
Starting MySQL...... SUCCESS!

好了，模拟数据丢失以及增量备份恢复作完了，假如在数据损毁不像我这样直接rm -fr这么干净的话能够在最近的一次增量备份合并到全备上面并恢复数据库以后将最近的一个binlog日志导入并恢复数据。

cat /backup3/2015-10-13_08-48-25/xtrabackup_binlog_info 
mysql-bin.000001133183220-1-31629
mysqlbinlog --start-position=13318322 /data/mysql/mysql-bin.000001 > /tmp/statements.sql

这样就能够恢复到出故障前的数据库状态了。（PS这个操做要在启动数据库以前进行操做）

相关文章
相关标签/搜索
每日一句
    每一个你不满意的现在，都有一个你没有努力的曾经。
本站公众号
   欢迎关注本站公众号,获取更多信息
联系我们 最近搜索 最新文章 沪ICP备13005482号-10 MyBatis教程 SQL 教程 MySQL教程 Java 教程 Thymeleaf 教程 Hibernate教程 Spring教程 Redis教程