Percona XtraBackup不鎖庫搭建slave數據庫-基於GTID

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

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.taride

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 事務號過時

相關文章
相關標籤/搜索