使用innobackup實現 基于GTID的從庫搭建

對于較大的數據庫，我們一般都是使用innobackup進行備份，備份的及恢復的速度更快。

試驗環境：

  CentOS6.8 x86_64

  MySQL5.6.34 社區rpm版

  xtrabackup版本：percona-xtrabackup-24-2.4.5-1.el6.x86_64.rpm

  主庫：node0 192.168.2.10 （需要安裝xtrabackup和lz4）

  從庫：node1 192.168.2.11（需要安裝xtrabackup和lz4）

5.6下GTID復制必須配的參數（主庫和從庫都要加上這3行參數）：

  gtid-mode=ON

  enforce_gtid_consistency = ON

  log_slave_updates=ON

step1、在從庫創建備份文件的存放目錄：

mkdir /tmp/db_restore

step2、在主庫執行備份（最好開個screen操作，防止網絡中斷的問題），直接導出到從庫機器上：

## 注意這里我們還需要提前在2臺機器上安裝lz4壓縮工具，因為我們的腳本會調用lz4壓縮和解壓備份文件

innobackupex --user=root \

--password=123456  \

--parallel=4 \

--socket=/tmp/mysql.sock \

--no-timestamp \

--stream=xbstream . |\

lz4 -B4 |\

ssh node1 \

"cat - | lz4 -d -B7 | xbstream -x -C /tmp/db_restore"

step3、在從庫node1上看下 主庫的gtid位置

cd /tmp/db_restore

cat  xtrabackup_binlog_info 內容如下：

mysql.000008       1949     013bfb27-2edd-11e7-89c7-000c296a2c0d:1-72

為了便于理解，我們去主庫查看下對應時間段的binlog，截圖如下：

補充：xtrabackup_binlog_info內容解讀：

mysql.000008 表示主庫的binlog文件名，1949是尚未執行的binlog position（就是說我們使用傳統change master模式的時候MASTER_LOG_FILE='master2-bin.001',MASTER_LOG_POS=1949）。

013bfb27-2edd-11e7-89c7-000c296a2c0d:1-72 指的是已經執行完的GTID編號（就是說我們change master的時候需要先執行set global gtid_purged='013bfb27-2edd-11e7-89c7-000c296a2c0d:1-72';   來purge掉這些GTID）。

step4、在從庫上將上一步獲取到的這些gtid purge掉，因為這些實際上已經執行過了。

set global gtid_purged='013bfb27-2edd-11e7-89c7-000c296a2c0d:1-72';    

如果提示 ERROR 1840 (HY000): @@GLOBAL.GTID_PURGED can only be set when @@GLOBAL.GTID_EXECUTED is empty. 則需要執行下reset master;

step5、配置并啟動復制：

CHANGE MASTER TO MASTER_HOST='192.168.2.10', 

 MASTER_USER='rpl', 

 MASTER_PASSWORD='rpl', 

 MASTER_PORT=3306, 

 MASTER_AUTO_POSITION=1;

start slave;

show slave status\G

然后可以在主庫的test庫下嘗試創建幾個表，驗證下復制是否正常。

待確認的問題：

對于某些版本的innobackup，備份出的xtrabackup_binlog_info 里面只有mysql.000008  1949 ，而不帶GTID編號。那么我們執行purge的時候就要根據binlog pos 1949這個位置到主庫的binlog去找到它上一個的gtid編號（例如上圖的就是013bfb27-2edd-11e7-89c7-000c296a2c0d:72）。或者使用傳統模式的復制，不用GTID復制即可。