怎么理解mysql GTID主從復(fù)制

本篇內(nèi)容介紹了“怎么理解mysql GTID主從復(fù)制”的有關(guān)知識，在實(shí)際案例的操作過程中，不少人都會遇到這樣的困境，接下來就讓小編帶領(lǐng)大家學(xué)習(xí)一下如何處理這些情況吧！希望大家仔細(xì)閱讀，能夠?qū)W有所成！

一、GTID的概述：

1、全局事物標(biāo)識：global transaction identifieds。

2、GTID事物是全局唯一性的，且一個(gè)事務(wù)對應(yīng)一個(gè)GTID。

3、一個(gè)GTID在一個(gè)服務(wù)器上只執(zhí)行一次，避免重復(fù)執(zhí)行導(dǎo)致數(shù)據(jù)混亂或者主從不一致。

4、GTID用來代替classic的復(fù)制方法，不在使用binlog+pos開啟復(fù)制。而是使用master_auto_postion=1的方式自動(dòng)匹配GTID斷點(diǎn)進(jìn)行復(fù)制。

5、MySQL-5.6.5開始支持的，MySQL-5.6.10后開始完善。

6、在傳統(tǒng)的slave端，binlog是不用開啟的，但是在GTID中，slave端的binlog是必須開啟的，目的是記錄執(zhí)行過的GTID（強(qiáng)制）。

二、GTID的組成部分：

前面是server_uuid：后面是一個(gè)序列號

例如：server_uuid：sequence number

7800a22c-95ae-11e4-983d-080027de205a:10

UUID：每個(gè)mysql實(shí)例的唯一ID，由于會傳遞到slave，所以也可以理解為源ID。

Sequence number：在每臺MySQL服務(wù)器上都是從1開始自增長的序列，一個(gè)數(shù)值對應(yīng)一個(gè)事務(wù)。

三、GTID比傳統(tǒng)復(fù)制的優(yōu)勢：

1、更簡單的實(shí)現(xiàn)failover，不用以前那樣在需要找log_file和log_Pos。

2、更簡單的搭建主從復(fù)制。

3、比傳統(tǒng)復(fù)制更加安全。

4、GTID是連續(xù)沒有空洞的，因此主從庫出現(xiàn)數(shù)據(jù)沖突時(shí)，可以用添加空事物的方式進(jìn)行跳過。

四、GTID的工作原理：

1、master更新數(shù)據(jù)時(shí)，會在事務(wù)前產(chǎn)生GTID，一同記錄到binlog日志中。

2、slave端的i/o 線程將變更的binlog，寫入到本地的relay log中。

3、sql線程從relay log中獲取GTID，然后對比slave端的binlog是否有記錄。

4、如果有記錄，說明該GTID的事務(wù)已經(jīng)執(zhí)行，slave會忽略。

5、如果沒有記錄，slave就會從relay log中執(zhí)行該GTID的事務(wù)，并記錄到binlog。

6、在解析過程中會判斷是否有主鍵，如果沒有就用二級索引，如果沒有就用全部掃描。

要點(diǎn)：

1、slave在接受master的binlog時(shí)，會校驗(yàn)master的GTID是否已經(jīng)執(zhí)行過（一個(gè)服務(wù)器只能執(zhí)行一次）。

2、為了保證主從數(shù)據(jù)的一致性，多線程只能同時(shí)執(zhí)行一個(gè)GTID。

六、使用GTID搭建mysql的主從復(fù)制的主要參數(shù)：

[mysqld]

#GTID:

gtid_mode=on

enforce_gtid_consistency=on

server_id=2003306    #每天實(shí)例的server_id都要不一樣

#binlog

log-bin=mysqlbin

log-slave-updates=1   #允許下端接入slave

binlog_format=row      #強(qiáng)烈建議，其他格式可能造成數(shù)據(jù)不一致

#relay log

skip_slave_start=1

注意：建議使用mysql-5.6.5以上的最新版本。

（二）、啟動(dòng)GTID的兩種方法：

方法一、

1、如果是在已經(jīng)跑的服務(wù)器，你需要重啟一下mysql server。

2、啟動(dòng)之前，一定要先關(guān)閉master的寫入，保證所有slave端都已經(jīng)和master端數(shù)據(jù)保持同步。

3、所有slave需要加上skip_slave_start=1的配置參數(shù)，避免啟動(dòng)后還是使用老的復(fù)制協(xié)議。

方法二、

1、如果是新搭建的服務(wù)器，直接啟動(dòng)就行了。

七、master-slave搭建的注意事項(xiàng)：

（一）、使用GTID的方式，把salve端掛載master端：

1、啟動(dòng)以后最好不要立即執(zhí)行事務(wù)，而是先change master上。

2、然后在執(zhí)行事務(wù)，當(dāng)然知不是必須的。

3、使用下面的sql切換slave到新的master。

stop slave;

change master to

master_host = 192.168.100.200,

master_port = 3306,

master_user = abobo,

master_password=123,

master_auto_position = 1;

(二)、如果給已經(jīng)運(yùn)行的GTID的master端添加一個(gè)新的slave

有兩種方法：

方法一、適用于master也是新建不久的情況。

1、如果你的master所有的binlog還在?？梢赃x擇類似于上面的方法，安裝slave，直接change master to到master端。

2、原理是直接獲取master所有的GTID并執(zhí)行。

3、優(yōu)點(diǎn)：簡單方便。

4、缺點(diǎn)：如果binlog太多，數(shù)據(jù)完全同步需要時(shí)間較長，并且master一開始就啟用了GTUD。

方法二、適用于擁有較大數(shù)據(jù)的情況。（推薦）

1、通過master或者其他slave的備份搭建新的slave。（看第三部分）

2、原理：獲取master的數(shù)據(jù)和這些數(shù)據(jù)對應(yīng)的GTID范圍，然后通過slave設(shè)置@@global.gtid_purged跳過備份包含的gtid。

3、優(yōu)點(diǎn)：是可以避免第一種方法的不足。

4、缺點(diǎn)：相對來說有點(diǎn)復(fù)雜。

（三）、通過備份搭建新的slave：（方法二的擴(kuò)展）

兩種方法：

方法一、mysqldump的方式：

1、在備份的時(shí)候指定--master-data=2（來保存binlog的文件號和位置的命令）。

2、使用mysqldump的命令在dump文件里可以看到下面兩個(gè)信息：

SET @@SESSION.SQL_LOG_BIN=0;

SET @@GLOBAL.GTID_PURGED='7800a22c-95ae-11e4-983d-080027de205a:1-8';

3、將備份還原到slave后，使用change master to命令掛載master端。

注意：在mysql5.6.9以后的命令才支持這個(gè)功能。

方法二、percona Xtrabackup

1、Xtrabackup_binlog_info文件中，包含global.gtid_purged='XXXXXX:XXXX'的信息。

2、然后到slave去手工的 SET GLOBAL.GTID_PURGED='XXXXXX:XXXX'。

3、恢復(fù)備份，開啟change master to 命令。

注意：如果系統(tǒng)運(yùn)行了很久，無法找到GTID的編號了，可以通過上面的方式進(jìn)行查找。

八、GTID如何跳過事務(wù)沖突：

1、這個(gè)功能主要跳過事務(wù)，代替原來的set global sql_slave_skip_counter = 1。

2、由于在這個(gè)GTID必須是連續(xù)的，正常情況同一個(gè)服務(wù)器產(chǎn)生的GTID是不會存在空缺的。所以不能簡單的skip掉一個(gè)事務(wù)，只能通過注入空事物的方法替換掉一個(gè)實(shí)際操作事務(wù)。

3、注入空事物的方法：

stop slave;

set gtid_next='xxxxxxx:N';

begin;commit;

set gtid_next='AUTOMAIC';

start slave;

4、這里的xxxxx:N 也就是你的slave sql thread報(bào)錯(cuò)的GTID，或者說是你想要跳過的GTID。

九、GTID的參數(shù)注釋：

[master]>show global variables like '%gtid%';

1、enforce_gtid_consistency：開啟gtid的一些安全限制（介意開啟）。

2、gtid_executed：全局和seeeion級別都可以用。用來保存已經(jīng)執(zhí)行過的GTIDs。

貼士：show  master status\G;輸出結(jié)果中的Executed_Gtid_Set和gitd_executed一致。reset master時(shí)，此值會被清空。

3、gtid_owned：全局和session級別都可用，全局表示所有服務(wù)器擁有GTIDs，session級別表示當(dāng)前client擁有所有GTIDs。（此功能用的少）

4、gtid_mode：是否開啟GTID功能。

5、gtid_purged：全局參數(shù)，設(shè)置在binlog中，已經(jīng)purged的GTIDs，并且purged掉的GTIDs會包含到gtid_executed中。

貼士：從而導(dǎo)致slave不會再去master請求這些GTIDs，并且Executed_Gtid_Set為空時(shí)，才可以設(shè)置此值。

6、gtid_next：這個(gè)時(shí)session級別的參數(shù)：

[master]>show session variables like '%gtid_next%';

十、關(guān)于GTID的一些功能限制：

（一）、更新非事務(wù)引擎：

1、Case重現(xiàn)：

master：對一個(gè)innodb表做一個(gè)多sql更新的事物，效果是產(chǎn)生一個(gè)GTID。

slave：對應(yīng)的表是MYISAM引擎，執(zhí)行這個(gè)GTID的第一個(gè)語句后就會報(bào)錯(cuò)，因?yàn)榉鞘聞?wù)引擎一個(gè)sql就是一個(gè)事務(wù)。

2、錯(cuò)誤編號：

last_Errno:1756

3、異常恢復(fù)方案：

（1）、簡單的stop slave; start slave;就能夠忽略錯(cuò)誤。但是這個(gè)時(shí)候主從的一致性已經(jīng)出現(xiàn)問題。需要手工的把slave差的數(shù)據(jù)補(bǔ)上。

（2）、首先將引擎調(diào)整為一樣的，slave也改為事務(wù)引擎。

（二）、不支持 create table ....select statements

1、case重現(xiàn)：

master：直接執(zhí)行一個(gè)create table select * from table;的sql

2、報(bào)錯(cuò)：

error 1786

3、原理：

由于create table ...select語句會生成兩個(gè)sql，一個(gè)是DDL創(chuàng)建表SQL，一個(gè)是insert into 插入數(shù)據(jù)的sql。由于DDL會導(dǎo)致自動(dòng)提交，所以這個(gè)sql至少需要兩個(gè)GTID，但是GTID模式下，只能給這個(gè)sql生成一個(gè)GTID，如果強(qiáng)制執(zhí)行會導(dǎo)致和上面更新非事務(wù)引擎一樣的結(jié)果。

（三）、一個(gè)sql同事操作innodb引擎和myisam引擎：

case重現(xiàn)：t1表是innodb，t2表是myisam

1、update t1,t2 set t1.id=1000,t2.id=1000 where t1.id=t2.id;

2、報(bào)錯(cuò)：1785

3、原理和第二個(gè)相同。

（四）、在一個(gè)replication grouop 中，所有的mysql必須要統(tǒng)一開啟或者關(guān)閉GTID功能。

1、case重現(xiàn)：

將一個(gè)未開啟gtid的slave通過原始的binlog和pos方式連接到開啟GTID的master。

2、報(bào)錯(cuò)：

The slave IO thread stops because the master has @@GLOBAL.GTID_MODE ON and this server has @@GLOBAL.GTID_MODE OFF。

（五）、在一個(gè)replication group中，如果開啟GTID以后，就不再允許使用classic的復(fù)制方式：

1、case重現(xiàn)：

將一個(gè)開啟gtid的slave通過原始的binlog和pos方式連接到開啟GTID的master。

2、報(bào)錯(cuò)：

ERROR 1776(HY000)：Parameters MASTER_LOG_FILE，MASTER_LOG_POS，RELAY_LOG_FILE and RELAY_LOG_POS cannot be set when MASTER_AUTO_POSITION is active。

（六）、GTID_MODE是not online的：

需要重啟才能生效，官方暫時(shí)不支持平滑的從classic replication切換到GTID replication。

貼士：

由于GTID開啟需要重啟系統(tǒng)，一個(gè)復(fù)制組中所有的實(shí)例必須統(tǒng)一開啟或者關(guān)閉GTID,開啟GTID以后不能在使用classic復(fù)制。

問題：

也就是說在線業(yè)務(wù)必須統(tǒng)一關(guān)閉，然后再啟動(dòng)，會導(dǎo)致服務(wù)中斷。

解決方案：

1、針對這種情況，社區(qū)有兩種對應(yīng)的平滑升級的方案：

一種是booking.com出品，這兩個(gè)差別在淘寶9月份數(shù)據(jù)庫月報(bào)里有說明，加了一個(gè)橋接的服務(wù)器，既可以運(yùn)行GTID模式下，也可以運(yùn)行classic模式下。

另外一種是facebook.com出品。所有的slave可以在開啟GTID模式的情況下，可以連接到?jīng)]有開啟GTID模式的master。

2、可以關(guān)閉一個(gè)部分，停止寫操作，但是讀不用，將另一部分改成GTID模式。

（七）、Temporary tables。

1、create temporary table和drop temporary table語句一樣在GTID環(huán)境下不支持。

如果--enforce_gtid_consistency參數(shù)開啟，并且autocommit=1，那么可以使用。

（八）、關(guān)于Errant transaction

1、Errant transaction：所謂的errant transaction也就是沒有規(guī)范的從master執(zhí)行，而是直接從slave執(zhí)行的事務(wù)。

2、由于GTID協(xié)議的原因，最開始已經(jīng)提過（參見GTID architecture）。

3、如果slave有errant transaction產(chǎn)生，由于GTID協(xié)議中的規(guī)則，很容易導(dǎo)致failover失敗。主要有兩種情況：

a、在slave上做了無用的或者臨時(shí)的errant transaction操作，如果該slave升級成為master的話，連接到它的所有數(shù)據(jù)庫都會獲取到這個(gè)事務(wù)。如果一樣就會產(chǎn)生沖突。

b、由于做了這個(gè)errant transaction這個(gè)事務(wù)以后，其他的slave還沒有獲取這個(gè)errant transaction的GTID，需要從master上發(fā)同步給其他的slave，但是主的binlog又被刪掉了，這時(shí)將會報(bào)錯(cuò)。

4、總之：盡量避免產(chǎn)生errant transaction?？梢酝ㄟ^：set sql_log_bin=off的方式在slave執(zhí)行sql，但是也要考慮到數(shù)據(jù)一致性。

“怎么理解mysql GTID主從復(fù)制”的內(nèi)容就介紹到這里了，感謝大家的閱讀。如果想了解更多行業(yè)相關(guān)的知識可以關(guān)注億速云網(wǎng)站，小編將為大家輸出更多高質(zhì)量的實(shí)用文章！