Percona XtraBackup不锁库搭建slave数据库-基于GTIDmysql
一、下载安装epel源并安装linux
wget http://ftp.cuhk.edu.hk/pub/linux/fedora-epel//6/x86_64/epel-release-6-8.noarch.rpmsql
rpm -ivh epel-release-6-8.noarch.rpm数据库
yum clean all 服务器
二、下载并安装XtraBackupapp
tar xf Percona-XtraBackup-2.2.7-r5050-el6-x86_64-bundle.tarui
yum install percona-xtrabackup-* -y日志
[root@ip ~]# which xtrabackup
/usr/bin/xtrabackuporm
如今xtrabackup已经安装完成,
三、在主库上建立复制帐号
mysql>grant replication slave on *.* to 'name'@'IP' identified by 'password';
四、接下来就使用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 事务号过时