GTID複製與問題處理

首先來看看什麼是GTID：

GTID(Global Transaction ID)是對於一個已提交交易的編號，並且是一個全域唯一的編號。

GTID其實是由UUID+TID組成的。其中UUID是一個MySQL實例的唯一識別。 TID代表了該實例上已提交的交易數量，並且隨著事務提交單調遞增。根據GTID可以知道事務最初是在哪個實例上提交的，而且方便故障切換。

 

接下來就看一下怎麼在GTID模式下快速的新增一個slave：

我們知道在沒有GTID複製以前，MySQL的複製是基於binary log和position來做的，之前的複製我們要執行下面的change語句：

CHANGE MASTER TO MASTER_HOST='',MASTER_PORT=3306,MASTER_USER='repl',MASTER_PASSWORD='*****',MASTER_LOG_FILE='mysqlbinlog.000003',MASTER_LOG_POS=99721204;

 

而我們在GTID就可以執行以下的change語句：

CHANGE MASTER TO  MASTER_HOST='****', MASTER_USER='repl',  MASTER_PASSWORD='******',  MASTER_PORT=3306,  master_auto_position=1;

 

我們可以看到，基本上來說指定複製的時候原來的binary log方式需要指定MASTER_LOG_FILE和MASTER_LOG_POS，而GTID複製卻不需要知道這些參數。

下面看一下怎麼在GTID的模式下建立主從複製：

從上面可以看得到，在GTID的模式下我們不再需要知道MASTER_LOG_FILE和MASTER_LOG_POS兩個參數，相比之下我們只需要指定master就可以了，這對於創建複製來說簡單的多了。在GTID的模式下我們需要知道以下兩個全域變數：

root@perconatest09:23:44>show global variables like 'GTID_%'\G*************************** 1. row ***************************Variable_name: gtid_executed
Value: 5031589f-3551-11e7-89a0-00505693235d:1-12,
806ede0c-357e-11e7-9719-00505693235d:1-11,
a38c33ee-34b7-11e7-ae1d-005056931959:1-24*************************** 2. row ***************************Variable_name: gtid_executed_compression_period
Value: 1000*************************** 3. row ***************************Variable_name: gtid_mode
Value: ON*************************** 4. row ***************************Variable_name: gtid_owned
Value:*************************** 5. row ***************************Variable_name: gtid_purged
Value: 5031589f-3551-11e7-89a0-00505693235d:1-12,
806ede0c-357e-11e7-9719-00505693235d:1-11,
a38c33ee-34b7-11e7-ae1d-005056931959:1-12

 

我們主要需要看到的就是gtid_executed和gtid_purged兩個參數，

gtid_executed：這個是已經執行過的所有的事物的GTID的一個系列串，也就是binary log裡面已經落盤的事物的序號。這個參數是唯讀的，不能夠進行設定。

gtid_purged：這個序列是指我們在binary log刪除的事物的GTID的序號。我們可以手動進行設置，方便我們做一些管理。

這兩個參數理解以後，接下來我們來看看怎樣去新增一個GTID複製的從庫：

（1）：從主庫做一個全備份，而且要記錄主庫備份時間點的gtid_executed

（2）：從庫進行恢復，並且將從庫的gtid_purged設定為我們第一步取得的master的gtid_executed

#（3）：執行CHANGE MASTER 語句。

我們使用mysqldump就可以將主庫備份，並且將備份還原到一台新的機器作為從庫。在執行前先在主函式庫看一下參數：

#

root@perconatest09:23:58>show global variables like 'GTID_e%'\G*************************** 1. row ***************************Variable_name: gtid_executed
Value: 5031589f-3551-11e7-89a0-00505693235d:1-12,
806ede0c-357e-11e7-9719-00505693235d:1-11,
a38c33ee-34b7-11e7-ae1d-005056931959:1-242 rows in set (0.01 sec)
root@perconatest09:41:33>show global variables like 'GTID_p%'\G*************************** 1. row ***************************Variable_name: gtid_purged
Value: 5031589f-3551-11e7-89a0-00505693235d:1-12,
806ede0c-357e-11e7-9719-00505693235d:1-11,
a38c33ee-34b7-11e7-ae1d-005056931959:1-121 row in set (0.01 sec)

 

然後在主庫進行備份：

mysqldump --all-databases --single-transaction --triggers --routines --host=127.0.0.1 --port=18675 --user=root--p > /home/sa/backup.sql

 

我們可以看看備份檔：

[root@localhost sa]# head -30 backup.sql

 

#我們能夠看到有以下的參數：

SET @@GLOBAL.GTID_PURGED='5031589f-3551-11e7-89a0-00505693235d:1-12,
806ede0c-357e-11e7-9719-00505693235d:1-11,
a38c33ee-34b7-11e7-ae1d-005056931959:1-24';

 

也就是說當我們進行恢復的時候，是會自動設定GTID_PURGED的，而這個值剛好就是master的gtid_executed，所以我們從函式庫恢復以後基本上就不需要在做指定了。

進入從庫恢復資料：

source backup.sql;

我們知道已經不需要在指定GTID_PURGE的值了，如果不確定還可以確認：

show global variables like 'gtid_executed';
show global variables like 'gtid_purged';

# 

後面直接指定複製就好了：

CHANGE MASTER TO MASTER_HOST="***", MASTER_USER="root", MASTER_PASSWORD="*****", MASTER_PORT=3306, MASTER_AUTO_POSITION = 1;

# 

#將*替換為你需要指定的主庫的相關訊息就OK了。

 

GTID主從複製的模式下如果發生錯誤，我們該怎麼恢復呢？

假如我們的主函式庫的日誌已經purged，執行了reset等操作，我們從函式庫會有如下報錯：

Last_IO_Error: Got fatal error 1236 from master when reading data from binary log: 'The slave is connecting using CHANGE MASTER TO MASTER_AUTO_POSITION = 1, but the master has purged binary logs containing GTIDs that the slave requires.'

提示我們找不到日誌，主從複製就會停掉，下面我們看一下處理方式：

（1 ）主庫執行以下操作：

root@perconatest09:41:38>show global variables like 'GTID_EXECUTED';+---------------+---------------------------------------------------------------------------------------------------------------------------------+| Variable_name | Value |+---------------+---------------------------------------------------------------------------------------------------------------------------------+| gtid_executed | 5031589f-3551-11e7-89a0-00505693235d:1-12,
806ede0c-357e-11e7-9719-00505693235d:1-11,
a38c33ee-34b7-11e7-ae1d-005056931959:1-24 |+---------------+---------------------------------------------------------------------------------------------------------------------------------+1 row in set (0.01 sec)

 

（2）從庫

root@(none)03:04:49>set global GTID_PURGED='5031589f-3551-11e7-89a0-00505693235d:1-12,806ede0c-357e-11e7-9719-00505693235d:1-11,a38c33ee-34b7-11e7-ae1d-005056931959:1-24';

# 

##請注意，在指定前先確認這個值是空的，不然我們要做以下操作：

#

root@(none)03:04:49>reset master;
root@(none)03:04:49>set global GTID_PURGED='5031589f-3551-11e7-89a0-00505693235d:1-12,806ede0c-357e-11e7-9719-00505693235d:1-11,a38c33ee-34b7-11e7-ae1d-005056931959:1-24';
root@(none)03:04:49>start slave;
root@(none)03:04:49>show slave status\G

 

這樣修復就完成了，但是我們最好還是用checksum校驗一下主從資料的一致性。

報錯訊息：

Got fatal error 1236 from master when reading data from binary log: 'The slave is connecting using CHANGE MASTER TO MASTER_AUTO_POSITION = 1, but the master has purged binary logs containing GTID that#個

錯誤訊息

為了增加瀏覽量）當然上面的方法並不能保證資料的完全一致性，我們還要去校驗使用pt-table-checksum and pt-table- sync，但是這樣效率不一定是最高的，最好的方式還是透過前面介紹的，做全備份，然後恢復，再指定master，這才是最可靠的。

以上是GTID複製與問題處理的詳細內容。更多資訊請關注PHP中文網其他相關文章！