MySQL 5.7使用Xtrabackup搭建GTID主从

MySQL版本是5.7.17

操作系统是CentOS 7

MySQL数据目录:/alidata1/mysql

MySQL备份目录:/alidata1/backup/full_mysql

在master及slave机器安装xtrabackup软件

[root@iz2ze6jo3o3bqbcongnypqz innobackupex]# rpm -ivh percona-xtrabackup-24-2.4.9-1.el7.x86_64.rpm
warning: percona-xtrabackup-24-2.4.9-1.el7.x86_64.rpm: Header V4 DSA/SHA1 Signature, key ID cd2efd2a: NOKEY
error: Failed dependencies:
libev.so.4()(64bit) is needed by percona-xtrabackup-24-2.4.9-1.el7.x86_64
perl(DBD::mysql) is needed by percona-xtrabackup-24-2.4.9-1.el7.x86_64
perl(Digest::MD5) is needed by percona-xtrabackup-24-2.4.9-1.el7.x86_64
rsync is needed by percona-xtrabackup-24-2.4.9-1.el7.x86_64

libev.so.4()的解决到下面这里下载操作系统对应的版本,本例下载的是libev-4.15-7.el7.x86_64.rpm

http://rpmfind.net/linux/rpm2html/search.php?query=libev.so.4%28%29%2864bit%29&submit=Search+...&system=&arch=

perl(DBD::mysql)和perl(Digest::MD5),需要安装mysql-community-libs-compat-5.7.17-1.el7.x86_64.rpm,在安装包里找到即可

在master机器操作

1、在数据库创建备份账号

CREATE USER xtrabk@'localhost' IDENTIFIED BY 'onlyxtrabk!@#$';
GRANT RELOAD, LOCK TABLES, REPLICATION CLIENT,Process ON *.* TO xtrabk@'localhost';
FLUSH PRIVILEGES;

2、备份主库

innobackupex --defaults-file=/etc/my.cnf --user=xtrabk --password='onlyxtrabk!@#$' --parallel=4 /alidata1/backup/full_mysql --no-timestamp

在slave机器操作

1、停止mysql,删除或者重命名Mysql数据目录

systemctl stop mysqld.service
rm -rf /alidata1/mysql/data
rm -rf /alidata1/mysql/redolog

2、应用日志及数据库还原

innobackupex --defaults-file=/etc/my.cnf --apply-log /alidata1/backup/full_mysql
innobackupex --defaults-file
=
/
etc
/
my
.
cnf --copy-back
/
alidata1
/
backup
/
full_mysql

3、修改数据目录的宿主权限

chown -R mysql:mysql /alidata1/mysql

4、启动mysql

systemctl start mysqld.service

5、过滤掉已执行过的gtid

cat /alidata1/backup/full_mysql/xtrabackup_info |grep binlog_pos
[root@iz2ze6jo3o3bqbcongnyppz full_mysql]# cat /alidata1/backup/full_mysql/xtrabackup_info |grep binlog_pos
binlog_pos = filename 'bin.000131', position '615481029', GTID of the last change 'c9c73c70-c089-11e7-8544-00163e0ad76e:1-107089934'

6、查看slave已执行的gtid是否为空,如果不为空,需要执行reset MASTER进行清理,否则无法设置gtid。

mysql> show master status G;
*************************** 1. row ***************************
             File: bin.000001
         Position: 154
     Binlog_Do_DB:
 Binlog_Ignore_DB:
Executed_Gtid_Set: c9c73c70-c089-11e7-8544-00163e0ad76e:1-106016597
1 row in set (0.00 sec)

7、执行reset master

8、执行GTID_PURGED

SET @MYSQLDUMP_TEMP_LOG_BIN = @@SESSION.SQL_LOG_BIN;
SET @@SESSION.SQL_LOG_BIN= 0;
SET @@GLOBAL.GTID_PURGED='c9c73c70-c089-11e7-8544-00163e0ad76e:1-107089934';
SET @@SESSION.SQL_LOG_BIN = @MYSQLDUMP_TEMP_LOG_BIN;

9、change master

change master to
master_host='192.168.2.71',
master_port=3306,
master_user='repl',
master_password='REPLsafe!@#$71',
MASTER_AUTO_POSITION = 1;

10、start slave ;

11、show slave statusG;

通过Xtrabackup日志来恢复检查点文件

最近积压了很多朋友的问题,我想起来的时候就回复一下,别见怪,不是我有势利眼。

前几天有个朋友问我的问题,是在xtrabackup的时候,没有特别保留checkpoints文件,想问问能否通过日志来推理得到里面的LSN信息呢,背景条件是做全备。

一个参考的日志如下:

171208 11:21:54 [01] Copying ./sbtest/dba_xtrabackupresult.frm to /data/backup/sbtest/dba_xtrabackupresult.frm

171208 11:21:54 [01] ...done

171208 11:21:54 Finished backing up non-InnoDB tables and files

171208 11:21:54 [00] Writing /data/backup/xtrabackup_binlog_info

171208 11:21:54 [00] ...done

171208 11:21:54 Executing FLUSH NO_WRITE_TO_BINLOG ENGINE LOGS...

xtrabackup: The latest check point (for incremental): ' 3985406424'

xtrabackup: Stopping log copying thread.

....171208 11:21:55 >> log scanned up to ( 4060591382)

171208 11:21:55 >> log scanned up to ( 4060591382) 171208 11:21:55 Backup created in directory '/data/backup/'

MySQL binlog position: filename 'mysqlbin.000017', position ' 96607849'

171208 11:21:55 [00] Writing /data/backup/backup-my.cnf

171208 11:21:55 [00] ...done

171208 11:21:55 [00] Writing /data/backup/xtrabackup_info

171208 11:21:55 [00] ...done

xtrabackup: Transaction log of lsn ( 3597739074) to ( 4060591382) was copied.

171208 11:21:57 completed OK!

可以看到日志里面出现了很多的LSN的信息,首先是能够根据日志得到LSN的信息,然后是如果可以的话,这些LSN是如何做选择的。

我们必然要引入xtrabackup的原理和过程图

总体来说xtrabackup会通过物理拷贝的方式,然后来补充增量的数据变化。整个过程和Oracle的热备有些类似。日志中的信息相对来说还是很全的,作为参考是足够的。

然后如何恢复呢,我们需要知道有哪些LSN是需要的。

一般来说,一个checkpoints文件需要如下的LSN信息

[root@tk-dba-mysql10-202 backup]# cat *checkpoints

backup_type = full-backuped

from_lsn = xx

to_lsn = xx

last_lsn = xx

compact = 0

recover_binlog_info = 0

为了避免干扰,我做了一些过滤,可以看到基本是由FROM_LSN,TO_LSN,LAST_LSN组成的,如果是全备,from_lsn应该是0,如果数据库没有负载,或者在这个备份的过程中没有什么写入,那么to_lsn和last_lsn是一致的。

可是上面的日志很明显,是在数据库比较繁忙的情况下做的备份,所以产生了很多的临界点的 LSN,所以通过这些细节就需要我们知道整个xtrabackup的过程中LSN的变化

我就不兜圈子了,通过模拟,得到的一个初步结论如下:

[root@tk-dba-mysql10-202 backup]# cat *checkpoints

backup_type = full-backuped

from_lsn = 0

to_lsn = 3985406424

last_lsn = 4060591382

compact = 0

recover_binlog_info = 0

这个过程是怎么模拟的呢,是在前端通过sysbench做压力测试,然后使用xtrabackup来备份。整个过程还是比较快的,大概半个小时内能够验证完成。

解决xtrabackup备份时出现的socket报错

今天为公司新建的uat数据库备份时,出现了报错,将解决方法整理、做一下备忘:

服务器系统:

[root@uat-mysql-master tmp]# cat /etc/redhat-release
 CentOS Linux release 7.3.1611 (Core) 
mysql版本号:
mysql> select version();
+----------------+
| version()      |
+----------------+
| 5.5.47-cll-lve |
+----------------+
1 row in set (0.00 sec)

报错如下:

[root@uat-mysql-master tmp]# innobackupex  --defaults-file=/etc/my.cnf --user=backup --password=****** --stream=tar /home/backup/ | gzip >/home/backup/`date +%F_%H-%M-%S`.tar.gz
171120 17:10:42 innobackupex: Starting the backup operation
IMPORTANT: Please check that the backup run completes successfully.
           At the end of a successful backup run innobackupex
           prints "completed OK!".
    171120 17:10:42  version_check Connecting to MySQL server with DSN 'dbi:mysql:;mysql_read_default_group=xtrabackup' as 'backup'  (using password: YES).
Failed to connect to MySQL server: DBI connect(';mysql_read_default_group=xtrabackup','backup',...) failed: Can't connect to local MySQL server through socket '/var/lib/mysql/mysql.sock' (2) at - line 1314.
171120 17:10:42 Connecting to MySQL server host: localhost, user: backup, password: set, port: not set, socket: not set
Failed to connect to MySQL server: Can't connect to local MySQL server through socket '/var/lib/mysql/mysql.sock' (2).

解决办法:

在命令行中添加

--host=127.0.0.1

参数;

备注:网上有的说,通过

# find / -name "mysql.sock"

查到socket参数,然后在配置文件中修改,但测试后,不一定能解决问题。

xtrabackup恢复备份后,mysql无法启动,报Job failed to start

今天测试 mysql的备份与备份恢复,因为数据量比较大,所以选用的xtrabackup.之前打算用binlog2sql,后来看到不支持建表等其他操作,就选用xtrabackup.这里记录下使用过程中遇到的坑:

1. 要先停止数据库.

本来是直接运行:

innobackupex
--copy-back /extrabackup/2016-04-27_07-30-48/

结果报错,说是/var/lib/mysql(我设置的data文件夹,根据自己情况查看)不为空.好吧,先停止数据库服务,删除目录下的所有文件,在重新启动,结果启动不了.

2. mysql: Job failed to start.

查看出错日志(具体路径可看配置文件my.cnf),说是 mysql 目录下的ibdata1是只读权限.好吧,我干脆把整个mysql 给完全权限 : chmod a+x mysql,结果还是不行.
ll命令查看后,发现ibdata1的拥有者是当前用户,不是mysql用户,最后运行:

chown -R mysql:mysql /var/lib/mysql  (目录是data 的目录)

ok了.

利用Xtrabackup工具备份及恢复(MySQL DBA的必备工具)

Xtrabackup——MySQL DBA的必备工具

注意:

  1. 文档参照http://www.percona.com/docs/wiki/percona-xtrabackup:start

  2. mysql要使用5.1.50版本或以上。

一、Xtrabackup简介及安装

1、Xtrabackup 是percona的一个开源项目,可以热备份innodb ,XtraDB,和MyISAM(会锁表),可以看做是InnoDB Hotbackup的免费替代品。

Percona Support for MySQL

未分类

参考:http://www.percona.com/mysql-support/

先看看如何安装Xtrabackup,最简单的安装方式是使用RPM包,不过想使用源代码方式安装的话,其安装方式有点古怪,因为它采用的在MySQL源代码上打补丁构建的方式安装的。

2、安装:

wget http://www.percona.com/downloads/XtraBackup/XtraBackup-1.4/Linux/binary/i686/

tar zxf xtrabackup-1.4.tar.gz

cd xtrabackup-1.4

./configure

make

进行到这里时,千万别make install,那样就会接着安装MySQL了,正确方法是:

cd innobase/xtrabackup/

make

make install

安装参照:http://www.percona.com/docs/wiki/percona-xtrabackup:installation:from-source

3、如此一来,就会在/usr/bin目录里安装上两个有用的工具:xtrabackup、innobackupex

  1. xtrabackup 只能备份InnoDB和XtraDB两种数据表,支持在线热备份,可以在不加锁的情况下备份Innodb数据表,不过此工具不能操作Myisam引擎表

  2. innobackupex 是一个脚本封装,封装了xtrabackup,能同时处理Innodb和Myisam,但在处理Myisam时需要加一个读锁。

按如上的介绍,由于操作Myisam时需要加读锁,这会堵塞线上服务的写操作,而Innodb没有这样的限制,所以数据库中Innodb表类型所占的比例越大,则越有利。实际应用中一般是直接使用innobackupex方法,它主要有三种操作方式,按手册中的介绍:

Usage:

innobackup [--sleep=MS] [--compress[=LEVEL]] [--include=REGEXP] [--user=NAME]

[--password=WORD] [--port=PORT] [--socket=SOCKET] [--no-timestamp]

[--ibbackup=IBBACKUP-BINARY] [--slave-info] [--stream=tar]

[--defaults-file=MY.CNF]

[--databases=LIST] [--remote-host=HOSTNAME] BACKUP-ROOT-DIR

innobackup --apply-log [--use-memory=MB] [--uncompress] [--defaults-file=MY.CNF]

[--ibbackup=IBBACKUP-BINARY] BACKUP-DIR

innobackup --copy-back [--defaults-file=MY.CNF] BACKUP-DIR

——————————————————————————————————

第一个命令行是热备份mysql数据库。

带有–apply-log选项的命令是准备在一个备份上启动mysql服务。

带有–copy-back选项的命令从备份目录拷贝数据,索引,日志到my.cnf文件里规定的初始位置。

Xtrabackup还可以用来moving InnoDB tables between servers,更多的内容可以参考官方文档及例子。

参考链接:

  1. 官方文档:http://www.percona.com/docs/wiki/percona-xtrabackup:xtrabackup_manual

  2. Xtrabackup online backup for InnoDB/XTraDB(pdf):

http://www.percona.com/ppc2009/PPC2009_xtrabackup.pdf

二、innobackupex 和 xtrabackup备份详解

注:innobackupex会根据/et/my.cnf来确定MySQL的数据位置。

1. 普通备份:

innobackupex [--defaults-file=/etc/my.cnf] --user=root [--host=192.168.1.52] [--password=xxx] [--port=3306]   /data/back_data/    2>/data/back_data/1.log

备份的目录是/data/back_data/,这里的2>/data/back_data/1.log,是将备份过程中的输出信息重定向到1.log

innobackupex-1.5.1 –slave-info …..

–slave-info会记录复制主日志的 复制点,便于重新做复制用。(用在备份从机器用)

备份后的文件:

xtrabackup_binlog_info — 存放binlog的信息。(binlog需要另外拷贝备份,如果需要binlog的话)

xtrabackup_checkpoints — 存放备份的起始位置和结束位置。

恢复:

首先停掉数据库,然后删除数据库目录下的所有数据库文件.

cd /data/mysql_data

rm -rf * # 删除数据目录里的所有文件

innobackupex-1.5.1 --user=root --apply-log /data/back_data/2010-10-26_16-09-37 # 应用日志

innobackupex-1.5.1 --user=root --copy-back /data/back_data/2010-10-26_16-09-37

默认innobackupex-1.5.1会将二进制日志信息存放在文件xtrabackup_binlog_info中发(方便做Slave)。

cd /data

chown -R mysql:mysql mysql_data/

重启mysql服务

2. 打包(Tar)备份:

innobackupex-1.5.1 --user=root [--password=xxx] --stream=tar /data/back_data/2/ 2>/data/back_data/2.log   1>/data/back_data/2.tar

还原:

#cd /data/back_data/2/

#tar ixvf 2.tar

# ls

2.tar backup-my.cnf ibdata1 ibdata2 mablevi mysql xtrabackup_binlog_info xtrabackup_checkpoints  xtrabackup_logfile

准备还原

# innobackupex-1.5.1 --user=xxx [--password=xxx]--apply-log /data/back_data/

……

innobackupex: completed OK!

删除数据目录里的所有文件

rm -rf /data/mysql_data/*

拷贝:

# innobackupex-1.5.1 --user=xxx [--password=xxx] --copy-back  /data/back_data/

……

innobackupex: completed OK!

cd /data

chown -R mysql:mysql mysql_data/

重启mysql服务

3. 压缩(tar gzip)备份

innobackupex-1.5.1 --user=root [--password=xxx] --stream=tar

/data/back_data/2/  2>/data/back_data/2.log | gzip > /data/back_data/2.tar.gz

这里使用了管道|将innobackupex-1.5.1作为gzip的标准输入。恢复,只需要使用tar -izxvf 解压对应的文件后,操作完全同普通备份。

还原:

使用tar –izxvf 解压对应的文件后,操作完全同普通备份。

#cd /data/back_data/2/

#tar ixvf 2.tar

# ls

backup-my.cnf ibdata1 ibdata2 mablevi mysql xtrabackup_binlog_info xtrabackup_checkpoints  xtrabackup_logfile

准备还原:

# innobackupex-1.5.1 --user=xxx [--password=xxx] --apply-log /data/back_data/2/

……

innobackupex: completed OK!

删除数据目录里的所有文件

rm -rf /data/mysql_data/*

# innobackupex-1.5.1 --user=xxx [--password=xxx] --copy-back   /data/back_data/2/

cd /data

chown -R mysql:mysql mysql_data/

重启mysql服务

———————————————————————————————————————

xtrabackup 备份和恢复

备份:

xtrabackup --defaults-file=/etc/my.cnf --backup --target-dir=/data/back_data/

恢复:

需要执行两次xtrabackup –prepare

xtrabackup --defaults-file=/etc/my.cnf --prepare --target-dir=/data/back_data/

xtrabackup --defaults-file=/etc/my.cnf --prepare --target-dir=/data/back_data/

注意,xtrabackup只备份数据文件,并不备份数据表结构(.frm),所以使用xtrabackup恢复的时候,你必须有对应表结构文件(.frm)。

增量备份:

1、全量备份

xtrabackup --defaults-file=/etc/my.cnf --backup --target-dir=/data/back_data/

2、增量备份

xtrabackup --defaults-file=/etc/my.cnf --backup --target-dir=/data/back_data_inc/ --incremental-

basedir=/data/back_data/

在增量备份的目录下,数据文件都是以.delta结尾的。增量备份只备份上一次全量备份后被修改过的page,所以增量备份只暂用较少的空间。增量备份可以在增量备份的基础上增量。

增量备份恢复:

我们需要分别对全量、增量备份各做一次prepare操作。

xtrabackup --defaults-file=/etc/my.cnf --prepare --target-dir=/data/back_data/2010-10-26_16-09-37

xtrabackup --prepare --target-dir=/data/back_data/2010-10-26_16-09-37--incremental-

dir=/data/back_data_inc

xtrabackup --prepare --target-dir=/data/back_data/ #这一步不是必须的

这样,/data/back_data/下的数据文件就可以直接放到你的MySQL数据目录下,恢复数据了。

再次提醒,xtrabackup只备份InnoDB数据文件,表结构是不备份的,所以恢复的时候,你必须有对应表结构文件(.frm)。

rm -rf /data/mysql_data/ib*

cp -i /data/back_data/2010-10-26_16-09-37/ib* /data/mysql_data/

cd /data

chown -R mysql:mysql mysql_data/

3、innobackupex 与 xtrabackup 相结合

首先,innobackupex全备份:

innobackupex  --user=root /data/back_data/ 2>/data/back_data/1.log #会生成一个时间文件夹,这里假如是2010-10-29_15-57-44

然后,xtrabackup 做增量备份:

xtrabackup --defaults-file=/etc/my.cnf --backup --target-dir=/data/back_data_inc/4 --incremental-basedir=/data/back_data/2010-10-29_15-57-44

恢复:

首先停掉数据库,备份二进制日志(如果有的话),然后删除数据库目录下的所有数据库文件.

cd /data/mysql_data

rm -rf * # 删除数据目录里的所有文件

恢复全量备份:

innobackupex  --user=root --apply-log /data/back_data/2010-10-29_15-57-44 # 应用日志

innobackupex  --user=root --copy-back /data/back_data/2010-10-29_15-57-44 # 拷贝文件

恢复增量备份:

xtrabackup --prepare --target-dir=/data/back_data/2010-10-29_15-57-44 --incremental-dir=/data/back_data_inc/5

cd /data

chown -R mysql:mysql mysql_data/

重启mysql服务。

xtrabackup备份还原MySQL数据库

mysqldump 备份鉴于其自身的某些特性(锁表,本质上备份出来insert脚本或者文本,不支持差异备份),不太适合对实时性要求比较高的情况

Xtrabackup可以解决mysqldump存在的上述的一些问题,生产环境应用的也会更多一些。

本文简单测试一下Xtrabackup对MySQL数据库的备份还原操作。

本着先把功能先撸起来再深入细节的原则,粗略地实现了一个备份还原,并未深入细节。

网上有不少xtrabackup的文章,因为环境不一样,有些需要配置xtrabackup的配置文件,
但是我在xtrabackup 2.4.7版本下测试就需要需求任何配置文件。可能是每个版本都的细节上都不一样,因此参考资料的时候要注意版本和环境。

innobackupex 备份

xtrabackup和MySQL的版本如下

未分类

完整备份

innobackupex --defaults-file=/etc/my.cnf --user=root --password=root --socket=/var/lib/mysql/mysql.sock /data/backup

说明:

1、 –defaults-file=/etc/my.cnf文件必须在最前面
2、 –user=root –password=root,–use=与 –password= 中间一定要有空格,

如截图,完整备份完成

未分类

如截图,完整备份会创建一个日期(年月日时分秒,yyyy-MM-dd_hh-mm-ss)命名的文件

完整备份出来的内存,实际上是对所备份的数据库的数据文件的copy加上备份时候产生的一些信息,
比如xtrabackup_checkpoints就是当前完整备份的一些个信息,这个信息对差异备份非常重要。

未分类

差异备份

差异备份之所以能够做到差异,就是依赖于完整备份的,在完整备份的基础上进行完整备份之后的差异的备份。
  
而如何确定完整的备份之后备份到哪里,就依赖于完整备份之后的xtrabackup_checkpoints这个文件的。
 

innobackupex --defaults-file=/etc/my.cnf --user=root --password=root --socket=/var/lib/mysql/mysql.sock --incremental /data/backup --incremental-basedir=/data/backup/2017-06-22_13-40-29

如截图,差异备份完成

未分类

如果在进行差异备份的时候,指定的完整备份的文件错误或者是未指定完整备份文件,会发现xtrabackup提示找不到xtrabackup_checkpoints这个文件。

未分类

innobackupex 还原

准备阶段

1、 恢复完整备份,也即完整备份应用(–apply-log)日志
    

innobackupex --defaults-file=/etc/my.cnf --apply-log --redo-only --socket=/var/lib/mysql/mysql.sock /data/backup/2017-06-22_13-40-29

2、 分别将增量备份应用到完整备份
  

innobackupex --defaults-file=/etc/my.cnf --apply-log --redo-only --socket=/var/lib/mysql/mysql.sock --incremental /data/backup/2017-06-22_13-40-29 --incremental-basedir=/data/backup/2017-06-22_13-41-48

未分类 

如果有多个差异备份,分别应用差异备份到完整备份。

恢复阶段

1、 完成差异备份的全部应用到完整备份之后,将恢复后的差异备份copy到原数据目录
    
默认情况下,如果数据路径下存在文件,则copy失败,需要清空数据文件路径下的文件。
    

innobackupex --copy-back /data/backup/2017-06-22_13-40-29

如截图,完成copy-back

未分类

2、启动MySQL服务

启动mysql服务,发现启动失败

未分类

看一下错误日志(启动错误信息),mysql5.7yum安装默认的errorlog位于/var/log/mysqld.log中,且默认不会滚动,意味着所有的错误信息都记录在这个文件中。

未分类

数据文件还原之后,需要读数据文件路径授予可读写的权限
  
这里直接授权数据文件路径777,chmod -R 777 /var/lib/mysql
  
然后启动mysql服务,可以正常启动。

未分类  

xtrabackupex才刚刚开始,留下一大堆问题,有时间再一个一个验证。

1、 怎么实现单个库(表)的备份与还原,毕竟实际环境中,因为每个库备份的频率和方式(备份方案)是不一样的?

2、 怎么用全备+差异备份然后结合二进制日志做基于时间点的方式还原?

3、 如何验证备份文件的有效性?

xtrabackup增量、全量备份mysql innodb教程

xtrabackup是Percona公司CTO Vadim参与开发的一款基于InnoDB的在线热备工具,具有开源,免费,支持在线热备,备份恢复速度快,占用磁盘空间小等特点,并且支持不同情况下的多种备份形式。xtrabackup的官方下载地址为http://www.percona.com/software/percona-xtrabackup。

xtrabackup包含两个主要的工具,即xtrabackup和innobackupex,二者区别如下:

  • xtrabackup只能备份innodb和xtradb两种引擎的表,而不能备份myisam引擎的表;

  • innobackupex是一个封装了xtrabackup的Perl脚本,支持同时备份innodb和myisam,但在对myisam备份时需要加一个全局的读锁。还有就是myisam不支持增量备份。

一、备份过程

innobackupex备份过程如下图:

未分类
(图1 innobackupex备份过程,本文中所有图都是google所得)

在图1中,备份开始时首先会开启一个后台检测进程,实时检测mysql redo的变化,一旦发现redo中有新的日志写入,立刻将日志记入后台日志文件xtrabackup_log中。之后复制innodb的数据文件和系统表空间文件ibdata1,待复制结束后,执行flush tables with read lock操作,复制.frm,MYI,MYD,等文件(执行flush tableswith read lock的目的是为了防止数据表发生DDL操作,并且在这一时刻获得binlog的位置)最后会发出unlock tables,把表设置为可读可写状态,最终停止xtrabackup_log。

二、全备恢复

这一阶段会启动xtrabackup内嵌的innodb实例,回放xtrabackup日志xtrabackup_log,将提交的事务信息变更应用到innodb数据/表空间,同时回滚未提交的事务(这一过程类似innodb的实例恢复)。恢复过程如下图:

未分类
(图2 innobackupex 恢复过程)

三、增量备份

innobackupex增量备份过程中的”增量”处理,其实主要是相对innodb而言,对myisam和其他存储引擎而言,它仍然是全拷贝(全备份)

“增量”备份的过程主要是通过拷贝innodb中有变更的”页”(这些变更的数据页指的是”页”的LSN大于xtrabackup_checkpoints中给定的LSN)。增量备份是基于全备的,第一次增备的数据必须要基于上一次的全备,之后的每次增备都是基于上一次的增备,最终达到一致性的增备。增量备份的过程如下,和全备的过程很类似,区别仅在第2步。

未分类
( 图 3 innobackupex增量备份过程)

四、增量备份恢复

和全备恢复类似,也需要两步,一是数据文件的恢复,如图4,这里的数据来源由3部分组成:全备份,增量备份和xtrabackup log。二是对未提交事务的回滚,如图5所示:

未分类
( 图4 innobackupex 增量备份恢复过程1)

未分类
( 图5 innobackupex增量备份恢复过程2)

五、innobackupex使用示例

1、安装使用xtrabackup

安装比较简单,我们使用二进制编译好的就行了,这种工具无需源码编译,因为没有什么功能需要俺们定制。

[root@MySQL-01 ~]# wget http://www.percona.com/redir/downloads/XtraBackup/LATEST/binary/Linux/x86_64/percona-xtrabackup-2.1.8-733-Linux-x86_64.tar.gz
[root@MySQL-01 ~]# tar xf percona-xtrabackup-2.1.8-733-Linux-x86_64.tar.gz -C /usr/local/
[root@MySQL-01 ~]# mv /usr/local/percona-xtrabackup-2.1.8-Linux-x86_64/ /usr/local/xtrabackup
[root@MySQL-01 ~]# echo "export PATH=$PATH:/usr/local/xtrabackup/bin" >> /etc/profile
[root@MySQL-01 ~]# source /etc/profile
[root@MySQL-01 ~]#

2、全量备份

创建备份用户:

mysql> create user 'backup'@'%' identified by 'yayun';
Query OK, 0 rows affected (0.01 sec)

mysql> grant reload,lock tables,replication client,create tablespace,super on *.* to 'backup'@'%';
Query OK, 0 rows affected (0.00 sec)

mysql>

进行全备份

备份数据存放在/data/backup/下面,innobackupex会自动创建一个文件夹,是当前系统的时间戳

mysql> select * from yayun.t1;
+------+-------+
| id   | name  |
+------+-------+
|    1 | yayun |
|    2 | atlas |
+------+-------+
2 rows in set (0.00 sec)

mysql>

测试数据就是yayun库中的t1表 (错误:–host=192.168.199.1

[root@MySQL-01 ~]# innobackupex --user=backup --password=yayun --socket=/tmp/mysqld.sock --defaults-file=/etc/my.cnf /data/backup/
xtrabackup: Creating suspend file '/data/backup/2014-04-07_23-05-04/xtrabackup_log_copied' with pid '57608'
xtrabackup: Transaction log of lsn (5324782783) to (5324782783) was copied.
140407 23:06:14  innobackupex: All tables unlocked
innobackupex: Backup created in directory '/data/backup/2014-04-07_23-05-04'
innobackupex: MySQL binlog position: filename 'mysql-bin.000014', position 2983
140407 23:06:14  innobackupex: Connection to database server closed
140407 23:06:14  innobackupex: completed OK!
[root@MySQL-01 ~]#

上面的过程中处理过,主要看最后是否提示innobackupex completed ok,可以看见备份成功。我们看看/data/backup目录下产生了什么复制代码

[root@MySQL-01 backup]# pwd
/data/backup
[root@MySQL-01 backup]# ll
total 4
drwxr-xr-x 12 root root 4096 Apr  7 23:06 2014-04-07_23-05-04
[root@MySQL-01 backup]# cd 2014-04-07_23-05-04/
[root@MySQL-01 2014-04-07_23-05-04]# ll
total 845888
-rw-r--r-- 1 root root       261 Apr  7 23:05 backup-my.cnf
drwx------ 2 root root      4096 Apr  7 23:06 employees
drwx------ 2 root root      4096 Apr  7 23:06 host
-rw-r----- 1 root root 866123776 Apr  7 23:05 ibdata1
drwx------ 2 root root      4096 Apr  7 23:06 menagerie
drwxr-xr-x 2 root root      4096 Apr  7 23:06 mysql
drwxr-xr-x 2 root root      4096 Apr  7 23:06 performance_schema
drwx------ 2 root root      4096 Apr  7 23:06 sakila
drwx------ 2 root root      4096 Apr  7 23:06 test
drwx------ 2 root root      4096 Apr  7 23:06 world_innodb
drwxr-xr-x 2 root root      4096 Apr  7 23:06 world_myisam
-rw-r--r-- 1 root root        13 Apr  7 23:06 xtrabackup_binary
-rw-r--r-- 1 root root        24 Apr  7 23:06 xtrabackup_binlog_info
-rw-r----- 1 root root        95 Apr  7 23:06 xtrabackup_checkpoints
-rw-r----- 1 root root      2560 Apr  7 23:06 xtrabackup_logfile
drwx------ 2 root root      4096 Apr  7 23:06 yayun
[root@MySQL-01 2014-04-07_23-05-04]#

可以看见有对应数据库的名字,比如yayun,还有一个以时间戳命名的目录。我们看看对应文件里面的内容,这几个比较重要

[root@MySQL-01 2014-04-07_23-05-04]# cat xtrabackup_checkpoints 
backup_type = full-backuped
from_lsn = 0
to_lsn = 5324782783
last_lsn = 5324782783
compact = 0
[root@MySQL-01 2014-04-07_23-05-04]# cat xtrabackup_binlog_info 
mysql-bin.000014        2983
[root@MySQL-01 2014-04-07_23-05-04]#

可以看见相关文件记录了LSN,日志偏移量,还可以看见这次是全备份,相信聪明的童鞋们一眼就看懂了。^_^

删除数据库,然后恢复全备(线上不要这样搞)

mysql> drop database yayun;
Query OK, 1 row affected (0.04 sec)

mysql>

恢复全备

恢复备份到mysql的数据文件目录,这一过程要先关闭mysql数据库,重命名或者删除原数据文件目录都可以,再创建一个新的数据文件目录,将备份数据复制到新的数据文件目录下,赋权,修改权限,启动数据库

[root@MySQL-01 ~]# /etc/init.d/mysqld stop
Shutting down MySQL.....                                   [  OK  ]
[root@MySQL-01 ~]# mv /data/mysql /data/mysql_bak
[root@MySQL-01 ~]# mkdir /data/mysql
[root@MySQL-01 ~]#
[root@MySQL-01 ~]# innobackupex --apply-log /data/backup/2014-04-07_23-05-04/ 
xtrabackup: starting shutdown with innodb_fast_shutdown = 1
140407 23:22:36  InnoDB: Starting shutdown...
140407 23:22:40  InnoDB: Shutdown completed; log sequence number 5324784140
140407 23:22:40  innobackupex: completed OK!

以上对应的目录就是innobackupex全备份自己创建的目录。

[root@MySQL-01 ~]# innobackupex --defaults-file=/etc/my.cnf --copy-back --rsync /data/backup/2014-04-07_23-05-04/
innobackupex: Starting to copy InnoDB log files
innobackupex: in '/data/backup/2014-04-07_23-05-04'
innobackupex: back to original InnoDB log directory '/data/mysql'
innobackupex: Copying '/data/backup/2014-04-07_23-05-04/ib_logfile1' to '/data/mysql/ib_logfile1'
innobackupex: Copying '/data/backup/2014-04-07_23-05-04/ib_logfile0' to '/data/mysql/ib_logfile0'
innobackupex: Finished copying back files.
140407 23:27:38  innobackupex: completed OK!
[root@MySQL-01 ~]#

可以看见已经成功恢复,修改数据目录权限,启动mysql,效验数据是否正常,查看yayun库下面的t1表中的数据。

[root@MySQL-01 ~]# chown -R mysql.mysql /data/mysql
[root@MySQL-01 ~]# /etc/init.d/mysqld start
Starting MySQL.................                            [  OK  ]
[root@MySQL-01 ~]#
mysql> use yayun
Reading table information for completion of table and column names
You can turn off this feature to get a quicker startup with -A

Database changed
mysql> select * from t1;
+------+-------+
| id   | name  |
+------+-------+
|    1 | yayun |
|    2 | atlas |
+------+-------+
2 rows in set (0.00 sec)

mysql>

发现数据已经成功恢复。

3、增量备份

在进行增量备份时,首先要进行一次全量备份,第一次增量备份是基于全备的,之后的增量备份是基于上一次的增量备份,以此类推。

全备份放在/data/backup/full,增量备份放在/data/backup/incremental

[root@MySQL-01 ~]# tree /data/backup/
/data/backup/
├── full
└── incremental

2 directories, 0 files
[root@MySQL-01 ~]#

废话少说,咱们先来一次全备份

[root@MySQL-01 ~]# innobackupex --user=backup --password=yayun --socket=/tmp/mysqld.sock --defaults-file=/etc/my.cnf /data/backup/full/
innobackupex: Backup created in directory '/data/backup/full/2014-04-07_23-37-20'
innobackupex: MySQL binlog position: filename 'mysql-bin.000001', position 107
140407 23:38:29  innobackupex: Connection to database server closed
140407 23:38:29  innobackupex: completed OK!
[root@MySQL-01 ~]#

为了测试效果,我们在t1表中插入数据

mysql> select * from t1;
+------+-------+
| id   | name  |
+------+-------+
|    1 | yayun |
|    2 | atlas |
+------+-------+
2 rows in set (0.00 sec)

mysql> insert into t1 select 1,'love sql';
Query OK, 1 row affected (0.01 sec)
Records: 1  Duplicates: 0  Warnings: 0

mysql> select * from t1;                  
+------+----------+
| id   | name     |
+------+----------+
|    1 | yayun    |
|    2 | atlas    |
|    1 | love sql |
+------+----------+
3 rows in set (0.00 sec)

mysql>

现在来一次增量备份1

[root@MySQL-01 ~]# innobackupex --user=backup --password=yayun --socket=/tmp/mysqld.sock --defaults-file=/etc/my.cnf --incremental /data/backup/incremental/ --incremental-basedir=/data/backup/full/2014-04-07_23-37-20/ --parallel=2
innobackupex: Backup created in directory '/data/backup/incremental/2014-04-07_23-42-46'
innobackupex: MySQL binlog position: filename 'mysql-bin.000001', position 301
140407 23:43:25  innobackupex: Connection to database server closed
140407 23:43:25  innobackupex: completed OK!
[root@MySQL-01 ~]#

我们看看增量备份的大小以及文件内容

[root@MySQL-01 ~]# du -sh /data/backup/full/2014-04-07_23-37-20/
1.2G    /data/backup/full/2014-04-07_23-37-20/
[root@MySQL-01 ~]# du -sh /data/backup/incremental/2014-04-07_23-42-46/
3.6M    /data/backup/incremental/2014-04-07_23-42-46/
[root@MySQL-01 ~]#

看见增量备份的数据很小吧,就是备份改变的数据而已。

[root@MySQL-01 2014-04-07_23-42-46]# pwd
/data/backup/incremental/2014-04-07_23-42-46
[root@MySQL-01 2014-04-07_23-42-46]# cat xtrabackup_checkpoints 
backup_type = incremental
from_lsn = 5324784718
to_lsn = 5324785066
last_lsn = 5324785066
compact = 0
[root@MySQL-01 2014-04-07_23-42-46]#

上面已经明显说明是增量备份了,该工具很人性化吧,呵呵

我们再次向t1表插入数据,然后创建增量备份2

mysql> select * from t1;
+------+----------+
| id   | name     |
+------+----------+
|    1 | yayun    |
|    2 | atlas    |
|    1 | love sql |
+------+----------+
3 rows in set (0.00 sec)

mysql> insert into t1 select 1,'mysql dba';
Query OK, 1 row affected (0.00 sec)
Records: 1  Duplicates: 0  Warnings: 0

mysql> select * from t1;                   
+------+-----------+
| id   | name      |
+------+-----------+
|    1 | yayun     |
|    2 | atlas     |
|    1 | love sql  |
|    1 | mysql dba |
+------+-----------+
4 rows in set (0.00 sec)

mysql>

创建增量备份2(这次是基于上次的增量备份哦)

[root@MySQL-01 ~]# innobackupex --user=backup --password=yayun --socket=/tmp/mysqld.sock --defaults-file=/etc/my.cnf --incremental /data/backup/incremental/ --incremental-basedir=/data/backup/incremental/2014-04-07_23-42-46/ --parallel=2
innobackupex: Backup created in directory '/data/backup/incremental/2014-04-07_23-51-15'
innobackupex: MySQL binlog position: filename 'mysql-bin.000001', position 496
140407 23:51:55  innobackupex: Connection to database server closed
140407 23:51:55  innobackupex: completed OK!
[root@MySQL-01 ~]#

[root@MySQL-01 ~]# ls -ltr /data/backup/full/
total 4
drwxr-xr-x 12 root root 4096 Apr  7 23:38 2014-04-07_23-37-20
[root@MySQL-01 ~]# ls -ltr /data/backup/incremental/
total 8
drwxr-xr-x 12 root root 4096 Apr  7 23:43 2014-04-07_23-42-46
drwxr-xr-x 12 root root 4096 Apr  7 23:51 2014-04-07_23-51-15
[root@MySQL-01 ~]#

4、增量备份恢复

增量备份的恢复大体为3个步骤

  • 恢复完全备份

  • 恢复增量备份到完全备份(开始恢复的增量备份要添加–redo-only参数,到最后一次增量备份去掉–redo-only参数)

  • 对整体的完全备份进行恢复,回滚那些未提交的数据

恢复完全备份(注意这里一定要加–redo-only参数,该参数的意思是只应用xtrabackup日志中已提交的事务数据,不回滚还未提交的数据)

[root@MySQL-01 ~]# innobackupex --apply-log --redo-only /data/backup/full/2014-04-07_23-37-20/
xtrabackup: starting shutdown with innodb_fast_shutdown = 1
140407 23:59:43  InnoDB: Starting shutdown...
140407 23:59:43  InnoDB: Shutdown completed; log sequence number 5324784718
140407 23:59:43  innobackupex: completed OK!

将增量备份1应用到完全备份

[root@MySQL-01 ~]# innobackupex --apply-log --redo-only /data/backup/full/2014-04-07_23-37-20/ --incremental-dir=/data/backup/incremental/2014-04-07_23-42-46/
innobackupex: Copying '/data/backup/incremental/2014-04-07_23-42-46/mysql/func.frm' to '/data/backup/full/2014-04-07_23-37-20/mysql/func.frm'
innobackupex: Copying '/data/backup/incremental/2014-04-07_23-42-46/mysql/help_relation.frm' to '/data/backup/full/2014-04-07_23-37-20/mysql/help_relation.frm'
innobackupex: Copying '/data/backup/incremental/2014-04-07_23-42-46/mysql/help_category.MYD' to '/data/backup/full/2014-04-07_23-37-20/mysql/help_category.MYD'
innobackupex: Copying '/data/backup/incremental/2014-04-07_23-42-46/mysql/ndb_binlog_index.frm' to '/data/backup/full/2014-04-07_23-37-20/mysql/ndb_binlog_index.frm'
140408 00:02:07  innobackupex: completed OK!
[root@MySQL-01 ~]#

将增量备份2应用到完全备份(注意恢复最后一个增量备份时需要去掉–redo-only参数,回滚xtrabackup日志中那些还未提交的数据)

[root@MySQL-01 ~]# innobackupex --apply-log /data/backup/full/2014-04-07_23-37-20/ --incremental-dir=/data/backup/incremental/2014-04-07_23-51-15/
innobackupex: Copying '/data/backup/incremental/2014-04-07_23-51-15/mysql/help_relation.frm' to '/data/backup/full/2014-04-07_23-37-20/mysql/help_relation.frm'
innobackupex: Copying '/data/backup/incremental/2014-04-07_23-51-15/mysql/help_category.MYD' to '/data/backup/full/2014-04-07_23-37-20/mysql/help_category.MYD'
innobackupex: Copying '/data/backup/incremental/2014-04-07_23-51-15/mysql/ndb_binlog_index.frm' to '/data/backup/full/2014-04-07_23-37-20/mysql/ndb_binlog_index.frm'
140408 00:04:33  innobackupex: completed OK!
[root@MySQL-01 ~]#

把所有合在一起的完全备份整体进行一次apply操作,回滚未提交的数据:

[root@MySQL-01 ~]# innobackupex --apply-log /data/backup/full/2014-04-07_23-37-20/
xtrabackup: starting shutdown with innodb_fast_shutdown = 1
140408  0:06:32  InnoDB: Starting shutdown...
140408  0:06:36  InnoDB: Shutdown completed; log sequence number 5324785676
140408 00:06:36  innobackupex: completed OK!

把恢复完的备份复制到数据库目录文件中,赋权,然后启动mysql数据库,检测数据正确性

[root@MySQL-01 ~]# /etc/init.d/mysqld stop
Shutting down MySQL.                                       [  OK  ]
[root@MySQL-01 ~]# mv /data/mysql /data/mysql_bak
[root@MySQL-01 ~]# mkdir /data/mysql
[root@MySQL-01 ~]# innobackupex --defaults-file=/etc/my.cnf --copy-back --rsync /data/backup/full/2014-04-07_23-37-20/
innobackupex: Starting to copy InnoDB log files
innobackupex: in '/data/backup/full/2014-04-07_23-37-20'
innobackupex: back to original InnoDB log directory '/data/mysql'
innobackupex: Copying '/data/backup/full/2014-04-07_23-37-20/ib_logfile1' to '/data/mysql/ib_logfile1'
innobackupex: Copying '/data/backup/full/2014-04-07_23-37-20/ib_logfile0' to '/data/mysql/ib_logfile0'
innobackupex: Finished copying back files.
140408 00:12:42  innobackupex: completed OK!
[root@MySQL-01 ~]# chown -R mysql.mysql /data/mysql
[root@MySQL-01 ~]# /etc/init.d/mysqld start
Starting MySQL....                                         [  OK  ]
[root@MySQL-01 ~]#

查看数据是否正确

mysql> select * from t1;
+------+-----------+
| id   | name      |
+------+-----------+
|    1 | yayun     |
|    2 | atlas     |
|    1 | love sql  |
|    1 | mysql dba |
+------+-----------+
4 rows in set (0.00 sec)

mysql>

5、克隆slave

在日常工作中,我们有时候需要在线添加从库,比如线上有一主一从两个数据库,但是由于业务的需要,一台从库的读取无法满足现在的需求,这样就需要我们在线添加从库,由于出于安全考虑,我们通常需要在从库上进行在线克隆slave。

克隆slave时,常用参数–slave-info和–safe-slave-backup。

–slave-info会将master的binlog文件名和偏移量位置保存到xtrabackup_slave_info文件中

–safe-slave-backup会暂停slave的SQL线程直到没有打开的临时表的时候开始备份。备份结束后SQL线程会自动启动,这样操作的目的主要是确保一致性的复制状态。

下面的例子,将介绍一主一从情况下在线搭建新的从库,环境如下:

master 192.168.0.10    #主库

slave    192.168.0.20    #从库

newslave 192.168.0.100 # 新的从库

在上述示例中,newslave即为要新搭建的从库。在老的从库上面进行备份:

[root@MySQL-02 ~]# innobackupex --user=root --password=12345 --socket=/tmp/mysqld.sock --defaults-file=/etc/my.cnf --slave-info --safe-slave-backup --no-timestamp /data/cloneslave
innobackupex: Backup created in directory '/data/cloneslave'
innobackupex: MySQL binlog position: filename 'mysql-bin.000022', position 107
innobackupex: MySQL slave binlog position: master host '192.168.0.10', filename 'mysql-bin.000006', position 732
140413 23:25:13  innobackupex: completed OK!

这里的/data/cloneslave 目录要不存在,如果存在是会报错的。

查看目录下生成的文件:

[root@MySQL-02 ~]# ll /data/cloneslave/
total 26668
-rw-r--r-- 1 root root      261 Apr 13 23:24 backup-my.cnf
-rw-r--r-- 1 root root 27262976 Apr 13 23:24 ibdata1
drwxr-xr-x 2 root root     4096 Apr 13 23:25 mysql
drwxr-xr-x 2 root root     4096 Apr 13 23:25 performance_schema
drwxr-xr-x 2 root root     4096 Apr 13 23:25 sakila
drwxr-xr-x 2 root root     4096 Apr 13 23:25 world_innodb
-rw-r--r-- 1 root root       13 Apr 13 23:25 xtrabackup_binary
-rw-r--r-- 1 root root       23 Apr 13 23:25 xtrabackup_binlog_info
-rw-r--r-- 1 root root       79 Apr 13 23:25 xtrabackup_checkpoints
-rw-r--r-- 1 root root     2560 Apr 13 23:25 xtrabackup_logfile
-rw-r--r-- 1 root root       72 Apr 13 23:25 xtrabackup_slave_info
drwxr-xr-x 2 root root     4096 Apr 13 23:25 yayun
[root@MySQL-02 ~]#

查看xtrabackup_slave_info文件内容,这个内容就是为搭建从库时需要change master to的参数:

[root@MySQL-02 ~]# cat /data/cloneslave/xtrabackup_slave_info 
CHANGE MASTER TO MASTER_LOG_FILE='mysql-bin.000006', MASTER_LOG_POS=732
[root@MySQL-02 ~]#

在老的slave服务器上进行还原,即192.168.0.20

[root@MySQL-02 ~]# innobackupex --apply-log --redo-only /data/cloneslave/
xtrabackup: starting shutdown with innodb_fast_shutdown = 1
140413 23:30:37  InnoDB: Starting shutdown...
140413 23:30:37  InnoDB: Shutdown completed; log sequence number 12981048
140413 23:30:37  innobackupex: completed OK!
[root@MySQL-02 ~]#

将还原的文件复制到新的从库newslave,即192.168.0.100

[root@MySQL-02 data]# rsync -avprP -e ssh /data/cloneslave/ 192.168.0.100:/data/mysql/

在主库master上添加对新从库newslave的授权:

mysql> grant replication slave on *.* to 'repl'@'192.168.0.100' identified by '123456';
Query OK, 0 rows affected (0.00 sec)

mysql> flush privileges;
Query OK, 0 rows affected (0.02 sec)

mysql>

拷贝老的从库的配置文件到新的从库newslave,并且修改server-id参数,修改完毕后,启动新的从库;

[root@MySQL-02 data]# scp /etc/my.cnf 192.168.0.100:/etc/
 root@192.168.0.100's password: 
 my.cnf                                                                                                             100% 4881     4.8KB/s   00:00 
[root@MySQL-02 data]#
[root@newslave mysql]# egrep 'log-slave|^server-id|skip_slave' /etc/my.cnf 
server-id       = 3
skip_slave_start
log-slave-updates=1
[root@newslave mysql]#
[root@newslave mysql]# chown -R mysql.mysql .
[root@newslave mysql]# /etc/init.d/mysqld restart
Shutting down MySQL.                                       [  OK  ]
Starting MySQL..                                           [  OK  ]
[root@newslave mysql]#

查找老的从库备份后生成的xtrabackup_slave_info文件,提取其中的master_log_file和master_log_pos信息,然后在新的从库上进行change master to操作:

在新的从库上进行同步:

mysql> CHANGE MASTER TO MASTER_HOST='192.168.0.10',MASTER_USER='repl', MASTER_PASSWORD='123456',MASTER_LOG_FILE='mysql-bin.000006', MASTER_LOG_POS=732;
Query OK, 0 rows affected (0.09 sec)

mysql>

启动io线程和sql线程,并观察复制是否正常:

mysql> start slave;
Query OK, 0 rows affected (0.00 sec)

mysql>
mysql> show slave  statusG
*************************** 1. row ***************************
               Slave_IO_State: Waiting for master to send event
                  Master_Host: 192.168.0.10
                  Master_User: repl
                  Master_Port: 3306
                Connect_Retry: 2
              Master_Log_File: mysql-bin.000006
          Read_Master_Log_Pos: 1309
               Relay_Log_File: MySQL-02-relay-bin.000002
                Relay_Log_Pos: 830
        Relay_Master_Log_File: mysql-bin.000006
             Slave_IO_Running: Yes
            Slave_SQL_Running: Yes
              Replicate_Do_DB: 
          Replicate_Ignore_DB: 
           Replicate_Do_Table: 
       Replicate_Ignore_Table: 
      Replicate_Wild_Do_Table: yayun.%
  Replicate_Wild_Ignore_Table: 
                   Last_Errno: 0
                   Last_Error: 
                 Skip_Counter: 0
          Exec_Master_Log_Pos: 1309
              Relay_Log_Space: 989
              Until_Condition: None
               Until_Log_File: 
                Until_Log_Pos: 0
           Master_SSL_Allowed: No
           Master_SSL_CA_File: 
           Master_SSL_CA_Path: 
              Master_SSL_Cert: 
            Master_SSL_Cipher: 
               Master_SSL_Key: 
        Seconds_Behind_Master: 0
Master_SSL_Verify_Server_Cert: No
                Last_IO_Errno: 0
                Last_IO_Error: 
               Last_SQL_Errno: 0
               Last_SQL_Error: 
  Replicate_Ignore_Server_Ids: 
             Master_Server_Id: 1
1 row in set (0.00 sec)

mysql>

查看主库,发现已经有两个线程(Binlog Dump)

mysql> show processlistG
*************************** 1. row ***************************
     Id: 8
   User: slave
   Host: 192.168.0.20:44251
     db: NULL
Command: Binlog Dump
   Time: 1088
  State: Master has sent all binlog to slave; waiting for binlog to be updated
   Info: NULL
*************************** 2. row ***************************
     Id: 9
   User: root
   Host: localhost
     db: yayun
Command: Query
   Time: 0
  State: NULL
   Info: show processlist
*************************** 3. row ***************************
     Id: 10
   User: repl
   Host: 192.168.0.100:45844
     db: NULL
Command: Binlog Dump
   Time: 124
  State: Master has sent all binlog to slave; waiting for binlog to be updated
   Info: NULL
3 rows in set (0.00 sec)

mysql>

正常工作,到此在线克隆slave就结束啦。

MySQL备份工具Xtrabackup锁问题

从XtraBackup的备份过程可以看出,XtraBackup可以实现Innodb表的无锁备份,但是一个数据库中,即使所有的业务表都是innodb表,但是还存在一些MySQL系统库下的user表等,均是myisam表(MySQL 8.0均替换为InnoDB),同时备份过程需要获取Binlog文件名和位置,也要保证表定义文件的一致性,所以从整个实例的角度,即使用XtraBackup还是有一段时间需要执行Flush table with read lock全局锁的,会对用户访问产生影响,同时由于Flush table with read lock的一些特殊性,如果稍不注意,可能会对用户访问数据库产生致命影响。

MySQL官网文档对Flush tables with read lock的解释:

Closes all open tables and locks all tables for all databases with a global read lock.

If the thread that is doing FLUSH TABLES has a lock on some tables, it will first close the locked tables, then wait until all other threads have also closed them, and then reopen them and get the locks. After this it will give other threads a chance to open the same tables.

从上面的这段话,我们可以得到两个结论:

  • Flush tables with read lock会上一个实例级别的全局锁,该锁与Lock tables或者Select for update等互斥,即如果前面有上述锁,会导致Flush tables with read lock阻塞。

  • Flush tables with read lock首先需要关闭所有的表,然后再打开所有的表。如果有线程正在扫描表,Flush tables with read lock会被阻塞,一直等到该表允许被关闭为止。如果有一个select count(*)的慢查询,会阻塞Flush tables with read lock。

可能大家认为Flush tables with read lock仅仅是一把读锁,即使阻塞了也不会影响正常的读,但是事实不是这个样子的。Peter Zaitsev 在文献【1】中提到了Flush tables with read lock的潜在风险。概括的讲,如果Flush table with read lock执行完毕,成功获取到了全局实例锁,后续的快照读和S锁的读是没有问题的,只是阻塞DDL、写;但是如果一旦因为表无法关闭或者因为其他的锁导致无法正常获取到表锁使得Flush table with read lock阻塞,这个后果将是灾难性的,所有的读,无论是快照读,还是S锁或者X锁的读,均会被阻塞,因为Flush table with read lock需要关闭表,这点是需要所有数据库运维人员警惕的,我们的数据库也因此导致了服务的长时间不可用。

XtraBackup从1.4到2.1.3均存在这样的隐患,在2.1.4的Release Notes中我们找到了相关描述:

Percona XtraBackup has introduced additional options to handle the locking during the FLUSH TABLES WITHREAD LOCK.These options can be used to minimize the amount of the time when MySQL operates in the read-only mode.

显然,Percona已经意识到了这个问题的严重性,提供了两种解决问题的思路:

1、设置超时时间

XtraBackup设置一个超时时间,避免无限期的等待。Xtrabackup提供了一下参数实现该功能:

  • –lock-wait-timeout=SECONDS :一旦Flush table with read lock被阻塞超过预定时间,则XtraBackup出错返回退出,该值默认为0,也就是说一旦阻塞,立即返回失败。

  • –lock-wait-query-type=all|update :该参数允许用户指定,哪类的SQL语句是需要Flush table with read lock等待的,同时用户可以通过–lock-wait-threshold=SECONDS设置等待的时间,如果不在query-type指定的类型范围内或者超过了wait-threshold指定的时间,XtraBackup均返回错误。如果指定update类型,则UPDATE/ALTER/REPLACE /INSERT 均会等待,ALL表示所有的SQL语句。

2、kill其他阻塞线程

Kill掉所有阻塞Flush table with read lock的线程:

  • –kill-long-queries-timeout=SECONDS :参数允许用户指定了超过该阈值时间的查询会被Kill,同时也允许用户指定Kill SQL语句的类型。

  • –kill-long-query-type=all|select :默认值为ALL,如果选择Select,只有Select语句会被Kill,如果Flush table with read lock是被Update语句阻塞,则XtraBackup不会处理。

数据库运维人员在备份数据库时,应选择正确的XtraBackup版本规避该问题。同时,个人在使用XtraBackup在Slave做备份时,还碰到跟SQL线程产生死锁的情况。MariaDB并行复制,死锁信息如下:

mysql> show processlist;
+---------+-------------+----------------------+--------------------+-------------+---------+--------------------------------------------------------------------------------+-----------------------------+----------+
| Id      | User        | Host                 | db                 | Command     | Time    | State                                                                          | Info                        | Progress |
+---------+-------------+----------------------+--------------------+-------------+---------+--------------------------------------------------------------------------------+-----------------------------+----------+
| 3335182 | system user |                      | NULL               | Connect     | 9556202 | Waiting for master to send event                                               | NULL                        |    0.000 |
| 3335183 | system user |                      | NULL               | Connect     |   15622 | Waiting for prior transaction to start commit before starting next transaction | NULL                        |    0.000 |
| 3335184 | system user |                      | NULL               | Connect     |   15622 | Waiting for global read lock                                                   | NULL                        |    0.000 |
| 3335185 | system user |                      | NULL               | Connect     |   14920 | Waiting for prior transaction to commit                                        | NULL                        |    0.000 |
| 3335195 | system user |                      | NULL               | Connect     |   15622 | Waiting for prior transaction to start commit before starting next transaction | NULL                        |    0.000 |
| 3335196 | system user |                      | NULL               | Connect     |   14920 | Waiting for global read lock                                                   | NULL                        |    0.000 |
| 3335197 | system user |                      | NULL               | Connect     |   14920 | Waiting for prior transaction to start commit before starting next transaction | NULL                        |    0.000 |
| 3335198 | system user |                      | NULL               | Connect     |   14920 | Waiting for prior transaction to start commit before starting next transaction | NULL                        |    0.000 |
| 3335199 | system user |                      | NULL               | Connect     |   21335 | Waiting for room in worker thread event queue                                  | NULL                        |    0.000 |
| 4525735 | backupuser  | localhost            | NULL               | Query       |   14920 | Waiting for commit lock                                                        | FLUSH TABLES WITH READ LOCK |    0.000 |
+---------+-------------+----------------------+--------------------+-------------+---------+--------------------------------------------------------------------------------+-----------------------------+----------+
26 rows in set (0.01 sec)

Xtrabackup全量备份/增量备份脚本

未分类

一、全量备份脚本

1、全量备份脚本

#!/bin/bash
#Description:xtrabackup complete
#Author:created by michael
#2017-08-07 v0.1
#
USER=root
PASSWD=123456
BACKUP_DIR=/backup/mysql/complete
DATE=$(date +"%F_%T")
[[ -d $BACKUP_DIR ]] || mkdir $DATE_DIR
innobackupex --user=$USER --password=$PASSWD $BACKUP_DIR &> /tmp/mysql/"$DATE".txt
egrep ".* Backup created in directory.*" /tmp/mysql/"$DATE".txt >> $BACKUP_DIR/complete.info
rm -rf /tmp/mysql/"$DATE".txt

2、启动crond以及开机自启动crond

systemctl start crond
systemctl enable crond

3、授予执行权限

chmod 755 /root/script/backup_complete.sh

4、每周六的凌晨4点整定时执行全量备份

[root@michaelos complete]# crontab -e
crontab: installing new crontab
[root@michaelos complete]# crontab -l
0 4 * * 6 /root/script/backup_complete.sh

二、增量备份脚本

1、增量备份脚本

[root@michaelos script]# cat backup_increment.sh 
#!/bin/bash 
#Description: mysql backup incremention
#Author:michael
#2017-08-07 v0.1
#
USER=root
PASSWORD=123456
BACKUP_DIR=/backup/mysql/increment
DATE=$(date +"%F_$T")
BASE_DIR=$(tail -1 /backup/mysql/complete/complete.info | cut -d' -f2)
[[ -d $BACKUP_DIR ]] || mkdir $BACKUP_DIR
innobackupex --user=$USER --password=$PASSWORD --incremental $BACKUP_DIR --incremental-basedir=$BASE_DIR &> /tmp/mysql/"$DATE".txt
egrep ".*Backup created in directory.*" /tmp/mysql/"$DATE".txt >> $BACKUP_DIR/backup.info
rm -rf /tmp/mysql/"$DATE".txt

2、授予执行权限

chmod 755 backup_increment.sh

3、每周二、四、日的凌晨2点执行增量备份

[root@michaelos script]# crontab -l
0 4 * * 6 /root/script/backup_complete.sh
0 2 * * 2,4,7 /root/script/backup_increment.sh

Xtrabackup定时备份mysql数据库脚本

定时备份MySQL数据库

脚本内容:

#!/bin/bash

## 备份计划任务
## 
## 每天凌晨1:30一次全量备份
## 每天间隔1小时一次增量备份
## 30 1 * * * backup.sh full
## 00 * * * * backup.sh inc
##
##  恢复数据步骤:
##  (1)、查看备份日志,找到全量备份和增量备份的关系(注意增量备份的顺序)
##
##  cat ${BACKUP_BASE_DIR}/${INC_BASE_LIST}
##  (2)、全量备份
##  innobackupex --defaults-file=/etc/my.cnf --apply-log ${BACKUP_BASE_DIR}/full_dir
##
##  (3)、第一个增量
##  innobackupex --defaults-file=/etc/my.cnf --apply-log ${BACKUP_BASE_DIR}/full_dir 
##  --incremental-dir=${BACKUP_BASE_DIR}/one_inc_dir
##
##  (4)、第二个增量
##  innobackupex --defaults-file=/etc/my.cnf --apply-log ${BACKUP_BASE_DIR}/full_dir 
##  --incremental-dir=${BACKUP_BASE_DIR}/two_inc_dir
##
##  (5)、恢复数据
##  innobackupex --defaults-file=/etc/my.cnf --copy-back ${BACKUP_BASE_DIR}/full_dir

PATH=/bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin:/usr/local/sbin

BACKUP_BASE_DIR="/backup/xtrabackup"
INC_BASE_LIST="${BACKUP_BASE_DIR}/inc_list.txt"
XTRABACKUP_PATH="/usr/local/xtrabackup/bin/innobackupex"

MYSQL_CNF="/etc/my.cnf"
MYSQL_HOSTNAME=127.0.0.1
MYSQL_USERNAME=root
MYSQL_PASSWORD=w7tQ5NNWWRk

LOCK_FILE=/tmp/innobackupex.lock
THREAD=3

mkdir -p ${BACKUP_BASE_DIR}
CURRENT_BACKUP_PATH="${BACKUP_BASE_DIR}/$(date +%F_%H-%M)"
[[ -d ${CURRENT_BACKUP_PATH} ]] && CURRENT_BACKUP_PATH="${BACKUP_BASE_DIR}/$(date +%F_%H-%M-%S)"

print_help(){
    echo "--------------------------------------------------------------"
    echo "Usage: $0 full | inc | help               "
    echo "--------------------------------------------------------------"
    exit 1
}

[[ $# -lt 1 || "$1" == "help" ]] && print_help

[[ -f "$LOCK_FILE" ]] && echo -e "Usage: rm -f $LOCK_FILEnUsage: chattr -i $LOCK_FILE && rm -f $LOCK_FILE" && exit 1

FullBackup(){
    touch $LOCK_FILE
    chattr +i $LOCK_FILE
    local rc=0
    ${XTRABACKUP_PATH} 
    --defaults-file=${MYSQL_CNF} 
    --user=${MYSQL_USERNAME} 
    --password=${MYSQL_PASSWORD} 
    --host=${MYSQL_HOSTNAME} 
    --parallel=${THREAD} 
    --no-timestamp ${CURRENT_BACKUP_PATH} > ${CURRENT_BACKUP_PATH}_full.log 2>&1
    grep ".* completed OK!" ${CURRENT_BACKUP_PATH}_full.log > /dev/null 2>&1
    if [ $? -ne 0 ];then
        rc=1
        [[ -d ${CURRENT_BACKUP_PATH} && $(pwd) != "/" ]] && rm -rf ${CURRENT_BACKUP_PATH}
    else
        echo "NULL|${CURRENT_BACKUP_PATH}|full" >> ${INC_BASE_LIST}
        [[ -d ${CURRENT_BACKUP_PATH} && $(pwd) != "/" ]] && chattr +i ${CURRENT_BACKUP_PATH} || rc=1
    fi
    chattr -i ${LOCK_FILE}
    rm -f $LOCK_FILE
    chattr +a ${INC_BASE_LIST}
    return $rc
}

IncBackup(){
    touch $LOCK_FILE
    chattr +i $LOCK_FILE
    local rc=0
    PREV_BACKUP_DIR=$(sed '/^$/d' ${INC_BASE_LIST} | tail -1 | awk -F '|' '{print $2}')
    ${XTRABACKUP_PATH} 
    --defaults-file=${MYSQL_CNF} 
    --user=${MYSQL_USERNAME} 
    --password=${MYSQL_PASSWORD} 
    --host=${MYSQL_HOSTNAME} 
    --no-timestamp --incremental ${CURRENT_BACKUP_PATH} 
    --incremental-basedir=${PREV_BACKUP_DIR} > ${CURRENT_BACKUP_PATH}_inc.log 2>&1
    grep ".* completed OK!" ${CURRENT_BACKUP_PATH}_inc.log > /dev/null 2>&1
    if [ $? -ne 0 ];then
        rc=1
        [[ -d ${CURRENT_BACKUP_PATH} && $(pwd) != "/" ]] && rm -rf ${CURRENT_BACKUP_PATH}
    else
        echo "${PREV_BACKUP_DIR}|${CURRENT_BACKUP_PATH}|inc" >> ${INC_BASE_LIST}
        [[ -d ${CURRENT_BACKUP_PATH} && $(pwd) != "/" ]] && chattr +i ${CURRENT_BACKUP_PATH} || rc=1
    fi
    chattr -i ${LOCK_FILE}
    rm -f $LOCK_FILE
    chattr +a ${INC_BASE_LIST}
    return $rc
}

## 全量备份
if [ "$1" == "full" ];then
    FullBackup
fi

## 增量备份
if [ "$1" == "inc" ];then
    ## 判断上一次备份是否存在,无则进行全量备份
    if [[ ! -f ${INC_BASE_LIST} || $(sed '/^$/d' ${INC_BASE_LIST} | wc -l) -eq 0 ]];then
        FullBackup
    else
        IncBackup
    fi
fi

## 删除14天前的备份
if [[ -d ${BACKUP_BASE_DIR} && $(pwd) != "/" ]];then
    find ${BACKUP_BASE_DIR} -name "$(date -d '14 days ago' +'%F')_*" | xargs chattr -i
    find ${BACKUP_BASE_DIR} -name "$(date -d '14 days ago' +'%F')_*" | xargs rm -rf
fi

加入计划任务

crontab -e
30 1 * * * /home/sh/backup.sh full
00 */6 * * * /home/sh/backup.sh inc
# mysql