明輝手游網(wǎng)中心:是一個(gè)免費(fèi)提供流行視頻軟件教程、在線學(xué)習(xí)分享的學(xué)習(xí)平臺(tái)!

GTID復(fù)制與問(wèn)題處理

[摘要]首先看一下什么是GTID:GTID(Global Transaction ID)是對(duì)于一個(gè)已提交事務(wù)的編號(hào),并且是一個(gè)全局唯一的編號(hào)。GTID實(shí)際上是由UUID+TID組成的。其中UUID是一個(gè)MySQL實(shí)例的唯一標(biāo)識(shí)。TID代表了該實(shí)例上已經(jīng)提交的事務(wù)數(shù)量,并且隨著事務(wù)提交單調(diào)遞增。根據(jù)GTID...
首先看一下什么是GTID:

GTID(Global Transaction ID)是對(duì)于一個(gè)已提交事務(wù)的編號(hào),并且是一個(gè)全局唯一的編號(hào)。

GTID實(shí)際上是由UUID+TID組成的。其中UUID是一個(gè)MySQL實(shí)例的唯一標(biāo)識(shí)。TID代表了該實(shí)例上已經(jīng)提交的事務(wù)數(shù)量,并且隨著事務(wù)提交單調(diào)遞增。根據(jù)GTID可以知道事務(wù)最初是在哪個(gè)實(shí)例上提交的,而且方便故障切換。

接下來(lái)就看一下怎么在GTID模式下快速的添加一個(gè)slave:

我們知道在沒(méi)有GTID復(fù)制以前,MySQL的復(fù)制是基于binary log和position來(lái)做的,之前的復(fù)制我們要執(zhí)行下面的change語(yǔ)句:



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


而我們?cè)贕TID就可以執(zhí)行以下的change語(yǔ)句:



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


我們可以看到,基本上來(lái)說(shuō)指定復(fù)制的時(shí)候原來(lái)的binary log方式需要指定MASTER_LOG_FILE和MASTER_LOG_POS,而GTID復(fù)制卻不需要知道這些參數(shù)。

下面看一下怎么在GTID的模式下創(chuàng)建主從復(fù)制:

從上面可以看得到,在GTID的模式下我們不再需要知道MASTER_LOG_FILE和MASTER_LOG_POS兩個(gè)參數(shù),相比之下我們只需要指定master就可以了,這對(duì)于創(chuàng)建復(fù)制來(lái)說(shuō)簡(jiǎn)單的多了。在GTID的模式下我們需要知道以下兩個(gè)全局變量



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兩個(gè)參數(shù),

gtid_executed:這個(gè)是已經(jīng)執(zhí)行過(guò)的所有的事物的GTID的一個(gè)系列串,也就是binary log里面已經(jīng)落盤(pán)的事物的序列號(hào)。這個(gè)參數(shù)是只讀的,不能夠進(jìn)行設(shè)置。

gtid_purged:這個(gè)序列是指我們?cè)赽inary log刪除的事物的GTID的序列號(hào)。我們可以手動(dòng)進(jìn)行設(shè)置,方便我們做一些管理。

這兩個(gè)參數(shù)理解以后,接下來(lái)我們看一下怎樣去添加一個(gè)GTID復(fù)制的從庫(kù):

(1):從主庫(kù)做一個(gè)全備份,而且要記錄主庫(kù)備份時(shí)間點(diǎn)的gtid_executed

(2):從庫(kù)進(jìn)行恢復(fù),而且將從庫(kù)的gtid_purged設(shè)置為我們第一步獲取的master的gtid_executed

(3):執(zhí)行CHANGE MASTER 語(yǔ)句。

我們使用mysqldump就可以將主庫(kù)進(jìn)行備份,并且將備份還原到一臺(tái)新的機(jī)器作為從庫(kù)。在執(zhí)行之前先在主庫(kù)看一下參數(shù):



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)


然后在主庫(kù)進(jìn)行備份:



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


我們能夠看到有以下的參數(shù):



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';


也就是說(shuō)當(dāng)我們進(jìn)行恢復(fù)的時(shí)候,是會(huì)自動(dòng)設(shè)置GTID_PURGED的,而這個(gè)值剛好就是master的gtid_executed,所以我們從庫(kù)恢復(fù)以后基本上就不需要在做指定了。

進(jìn)入從庫(kù)恢復(fù)數(shù)據(jù):

source backup.sql;

我們知道已經(jīng)不需要在指定GTID_PURGE的值了,要是不確定還可以確認(rèn)一下:



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


后面直接指定復(fù)制就好了:



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


將*替換為你需要指定的主庫(kù)的相關(guān)信息就OK了。

GTID主從復(fù)制的模式下如果出現(xiàn)錯(cuò)誤,我們?cè)撛趺椿謴?fù)呢?

假如我們的主庫(kù)的日志已經(jīng)purged,執(zhí)行了reset等操作,我們從庫(kù)會(huì)有如下報(bào)錯(cuò):



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


提示我們找不到日志,主從復(fù)制就會(huì)停掉,下面我們看一下處理方式:

(1)主庫(kù)執(zhí)行以下操作:



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)從庫(kù)



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';


注意,在指定前首先要確認(rèn)這個(gè)值是空的,不然我們要做以下操作:



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


這樣修復(fù)就完成了,但是我們最好還是用checksum校驗(yàn)一下主從數(shù)據(jù)的一致性。

報(bào)錯(cuò)信息:

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

(貼個(gè)錯(cuò)誤信息為了增加瀏覽量)

當(dāng)然上面的方法并不能保證數(shù)據(jù)的完全一致性,我們還要去校驗(yàn)使用 pt-table-checksum and pt-table-sync,但是這樣效率不一定是最高的,最好的方式還是通過(guò)前面介紹的,做全備份,然后恢復(fù),再指定master,這才是最靠譜的。

以上就是GTID復(fù)制和問(wèn)題處理的詳細(xì)內(nèi)容,更多請(qǐng)關(guān)注php中文網(wǎng)其它相關(guān)文章!


學(xué)習(xí)教程快速掌握從入門(mén)到精通的SQL知識(shí)。