Percona XtraBackup不锁库搭建slave数据库-基于GTID

Percona XtraBackup不锁库搭建slave数据库-基于GTID

1、下载安装epel源并安装

wget http://ftp.cuhk.edu.hk/pub/linux/fedora-epel//6/x86_64/epel-release-6-8.noarch.rpm

rpm -ivh epel-release-6-8.noarch.rpm

yum clean all

2、下载并安装XtraBackup

wget http://www.percona.com/downloads/XtraBackup/XtraBackup-2.2.7/binary/redhat/6/x86_64/Percona-XtraBackup-2.2.7-r5050-el6-x86_64-bundle.tar

tar xf  Percona-XtraBackup-2.2.7-r5050-el6-x86_64-bundle.tar

yum install percona-xtrabackup-* -y

[root@ip ~]# which xtrabackup 
/usr/bin/xtrabackup

现在xtrabackup已经安装完成，

3、在主库上创建复制账号

mysql>grant replication slave on *.* to 'name'@'IP' identified by 'password';

4、接下来就使用xtrabackup做数据库全备

mkdir /data/backup -p

innobackupex --user=root --password='password' --defaults-file=/etc/my.cnf /data/backup/ > /root/back.log 2>&1

注：将执行过程重定向到back.log文件中，待执行完成后可查看是否有报错，如果没有报错并在文件最后结尾处有如下提示测表示备份成功。

141225 08:18:41 innobackupex: Connection to database server closed
141225 08:18:41 innobackupex: completed OK!

备份好的文件保存在 /data/backup目录中，比如：

[root@ip ~]# ls /data/backup/
2014-12-25_08-17-23
[root@ip ~]# ls /data/backup/2014-12-25_08-17-23/
backup-my.cnf ibdata2 ib_logfile1 mysql performance_schema xtrabackup_binlog_pos_innodb xtrabackup_info
ibdata1 ib_logfile0 lost+found oneplus_account xtrabackup_binlog_info xtrabackup_checkpoints xtrabackup_logfile
[root@ip ~]#

备份日志：

刚刚备份好的数据文件，并不是直接可用的。现在要将其恢复：

innobackupex --apply-log /data/backup/2014-12-25_08-17-23/  > /root/bb.log 2>&1

这个过程与数据库挂掉之后重启mysqld时的自动修复过程差不多。

scp -r  /data/backup/2014-12-25_08-17-23 root@xxxxxx:/data/backup/

关闭从服务器并切换数据：

/etc/init.d/mysql stop

将原来的数据做一下备份

mkdir -p /data/backup/mysql_old

mv /var/lib/mysql/* /data/backup/mysql_old

mv  /data/backup/2014-12-25_08-17-23/* /var/lib/mysql/

chown -R mysql.mysql  /var/lib/mysql

修改my.cnf， 给它一个独一无二的server_id。

再将从库原来的my.cnf备份

cp /etc/my.cnf /etc/my.cnf.bak

cd /var/lib/mysql/

/bin/cp backup-my.cnf /etc/my.cnf

再将原来my.cnf.bak中的一些参数添加到my.cnf中并启动mysql

/etc/init.d/mysql start

最后change master。

与mysqldump备份的步骤比起来，这次我们没有flush tables with read lock，

也没有show master status来获取日志文件名和座标。

因为xtrabackup完成备份之后，自动保存了这些信息。

采用GTID建立主从关系

可查看在主库上备份时执行过程25.log.查看到UUID和tran_id

[root@ip ~]# cat /var/lib/mysql/xtrabackup_binlog_info 
50937877-8987-11e4-88fe-005056a30e51:1-7605

这个时候,登录到服务器,执行如下操作:

reset master;

清楚binlog和tran_id信息.

之所以这样做,是因为原来的mysql实例有自己相应的"uuid+tran_id",如果不清除,就不能完成下面这一步.

同时这里运行reset master.并不会清除其他mysql实例的信息,他只会清除他自身的GTID信息!

SET GLOBAL gtid_purged="50937877-8987-11e4-88fe-005056a30e51:1-7605";

GTID从7606开始传输

最后,开始同步

CHANGE MASTER TO

MASTER_HOST='<master_host>',

MASTER_USER='<slave_username>',

MASTER_PASSWORD='<slave_password>',

MASTER_AUTO_POSITION = 1;

start slave;

通过show slave status\G;可以查看到 Slave_IO_Running和 Slave_SQL_Running状态都为YES,并且Exec_Master_Log_Pos和 Relay_Log_Space数据不断在变化。

至此通过XtraBackup不锁库搭建slave数据库已经完成。

注意:

1.采取这种方式进行mysql数据库主从建立,在传输同步文件的时间上有要求,尽量快速完成,防止gtid 事务号过期