在MySQL中使用GTIDs復(fù)制協(xié)議和中斷協(xié)議的教程安鋼協(xié)議中斷

在MySQL中使用GTIDs復(fù)制協(xié)議和中斷協(xié)議的教程安鋼協(xié)議中斷

MySQL5.6有許多新的特性，其中許多人都感興趣的一條就是全局事務(wù)序號(hào)功能(GTIDs)。而大家都對(duì)這一特性很感興趣的緣由也很好理解，即：原來(lái)重新連接從效勞器和一個(gè)新的主效勞器始終是件很麻煩的事，然而在啟用GTIDs功能之后就變得簡(jiǎn)潔易行。可是，GTIDs的使用不單單是用單獨(dú)的標(biāo)識(shí)符替換舊的二進(jìn)制日志文件/位置，它也采納了新的復(fù)制協(xié)議。假設(shè)你還不太明白這些，那你可以在這篇文章里學(xué)點(diǎn)什么。

復(fù)制協(xié)議：新的VS舊的

舊的協(xié)議往往簡(jiǎn)潔直接即：首先從效勞器上在一個(gè)特定的偏移量那里連接到一個(gè)給定的二進(jìn)制日志文件，然后主效勞器在從那里發(fā)送全部的事務(wù)。

新協(xié)議稍有不同：slave首先會(huì)發(fā)送它已經(jīng)執(zhí)行過的GTID的范圍，然后master發(fā)送每一個(gè)喪失的事務(wù).它也確保了一個(gè)給定的GTID只可以在一個(gè)特定的slave中執(zhí)行一次.

實(shí)踐中，這會(huì)轉(zhuǎn)變?nèi)魏螙|西嗎?使得，它會(huì)轉(zhuǎn)變?cè)S多東西.想象一下下面的場(chǎng)景:你想要從trx4開頭復(fù)制，但是trx2在slave上由于某種原因喪失了.

使用老協(xié)議的話，trx2再也不會(huì)被執(zhí)行一次，而使用新協(xié)議，它就會(huì)被自動(dòng)的再執(zhí)行一次.

下面是兩個(gè)你可以在實(shí)踐中看到新協(xié)議的通用場(chǎng)景.

跳過事務(wù)

眾所周知老的SETGLOBALsql_slave_skip_counter=N在你想要跳過一個(gè)事務(wù)時(shí)不再供應(yīng)支持，而GTID就可以被啟用了.換用GTIDXXX:N來(lái)跳過事務(wù),你須得注入一個(gè)空的事務(wù):

mysqlSETgtid_next=“XXX:N“;

mysqlBEGIN;COMMIT;

mysqlSETgtid_next=“AUTOMATIC“;

為什么我們不能使用sql_slave_skip_counter?就是由于新的復(fù)制協(xié)議!

想象一下我們擁有如下列圖所示的三臺(tái)效勞器:

讓我們假設(shè)sql_slave_skip_counter可以用并且已經(jīng)被用在S2上用于跳過trx2.假如你吧S2設(shè)置成S1的一個(gè)slave將會(huì)發(fā)生什么呢?

兩個(gè)效勞器會(huì)相互交換被執(zhí)行了GTID的范圍，并且S1將會(huì)意識(shí)到其必需將trx2發(fā)送給S2.然后會(huì)發(fā)生的事情有兩種可能:

假如trx2仍舊在S1的二進(jìn)制日志中，它將會(huì)被發(fā)送給S2，而事務(wù)在也不會(huì)被跳過了.

假如trx2不再存在于S1的二進(jìn)制日志中，你將會(huì)得到一個(gè)復(fù)制錯(cuò)誤.

很明顯這擔(dān)心全，這就是為什么sql_slave_skip_counter在使用GTID時(shí)是不能用的.要想跳過一個(gè)事務(wù)，唯一安全的選擇就是去執(zhí)行一個(gè)虛擬的事務(wù)，而不是一個(gè)真實(shí)的事務(wù).

錯(cuò)誤的事務(wù)

假如你在一個(gè)slave上本地執(zhí)行了一個(gè)事務(wù)(在MySQL文檔中被稱為錯(cuò)誤事務(wù)),假如你被這個(gè)事務(wù)推送到新的master上時(shí)會(huì)發(fā)生什么呢?

使用老協(xié)議，根本上沒啥事(精確點(diǎn)說，新的master和其slave之間的數(shù)據(jù)將會(huì)消失不全都，但那在稍后就可能會(huì)被修復(fù)).

使用新協(xié)議，錯(cuò)誤的事務(wù)將會(huì)被識(shí)別成為在每個(gè)地方都喪失了，并且將會(huì)自動(dòng)在容錯(cuò)備份上被執(zhí)行，這樣就將會(huì)導(dǎo)致打斷復(fù)制的隱患.

比方說，你擁有一個(gè)master(M)和兩個(gè)slave(S1和S2).這里有兩種將slave重連到新的master將會(huì)發(fā)生(帶有不同復(fù)制錯(cuò)誤的)失敗的場(chǎng)景:

#場(chǎng)景1

#S1

mysqlCREATEDATABASEmydb;

#M

mysqlCREATEDATABASEIFNOTEXISTSmydb;

#Thanksto“IFNOTEXITS“,replicationdoesn“tbreakonS1.NowmoveS2toS1:

#S2

mysqlSTOPSLAVE;CHANGEMASTERTOMASTER_HOST=“S1“;STARTSLAVE;

#Thiscreatesaconflictwithexistingdata!

mysqlSHOWSLAVESTATUSG

[...]

Last_SQL_Errno:1007

Last_SQL_Error:Error“Can“tcreatedatabase“mydb“;databaseexists“onquery.Defaultdatabase:“mydb“.Query:“CREATEDATABASEmydb“

[...]

#場(chǎng)景2

#S1

mysqlCREATEDATABASEmydb;

#Now,we“l(fā)lremovethistransactionfromthebinarylogs

#S1

mysqlFLUSHLOGS;

mysqlPURGEBINARYLOGSTO“mysql-bin.000008“;

#M

mysqlCREATEDATABASEIFNOTEXISTSmydb;

#S2

mysqlSTOPSLAVE;CHANGEMASTERTOMASTER_HOST=“S1“;STARTSLAVE;

#Themissingtransactionisnolongeravailableinthemaster“sbinarylogs!

mysqlSHOWSLAVESTATUSG

[...]

Last_IO_Errno:1236

Last_IO_Error:Gotfatalerror1236frommasterwhenreadingdatafrombinarylog:“TheslaveisconnectingusingCHANGEMASTERTOMASTER_AUTO_POSITION=1,butthemasterhaspurgedbinarylogscontainingGTIDsthattheslaverequires.“

[...]

你可以這樣理解，錯(cuò)誤的事務(wù)應(yīng)當(dāng)借助基于GTID的效勞得以避開.假如你需要運(yùn)行一個(gè)本地事務(wù)，最好的選擇是針對(duì)那條特定的語(yǔ)句禁用二進(jìn)制日志:

mysqlSETSQL_LOG_BIN=0;

my