共計(jì) 5758 個(gè)字符，預(yù)計(jì)需要花費(fèi) 15 分鐘才能閱讀完成。

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

一、GTID 的概述：

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

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

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

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

5、MySQL-5.6.5 開(kāi)始支持的，MySQL-5.6.10 后開(kāi)始完善。

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

二、GTID 的組成部分：

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

例如：server_uuid：sequence number

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

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

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

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

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

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

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

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

四、GTID 的工作原理：

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

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

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

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

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

6、在解析過(guò)程中會(huì)判斷是否有主鍵，如果沒(méi)有就用二級(jí)索引，如果沒(méi)有就用全部掃描。

要點(diǎn)：

1、slave 在接受 master 的 binlog 時(shí)，會(huì)校驗(yàn) master 的 GTID 是否已經(jīng)執(zhí)行過(guò)（一個(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 的寫(xiě)入，保證所有 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 還在。可以選擇類(lèi)似于上面的方法，安裝 slave，直接 change master to 到 master 端。

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

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

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

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

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

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

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

4、缺點(diǎn)：相對(duì)來(lái)說(shuō)有點(diǎn)復(fù)雜。

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

兩種方法：

方法一、mysqldump 的方式：

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

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ù)備份，開(kāi)啟 change master to 命令。

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

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

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

2、由于在這個(gè) GTID 必須是連續(xù)的，正常情況同一個(gè)服務(wù)器產(chǎn)生的 GTID 是不會(huì)存在空缺的。所以不能簡(jiǎn)單的 skip 掉一個(gè)事務(wù)，只能通過(guò)注入空事物的方法替換掉一個(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，或者說(shuō)是你想要跳過(guò)的 GTID。

九、GTID 的參數(shù)注釋?zhuān)?/p>

[master] show global variables like %gtid%

1、enforce_gtid_consistency：開(kāi)啟 gtid 的一些安全限制（介意開(kāi)啟）。

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

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

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

4、gtid_mode：是否開(kāi)啟 GTID 功能。

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

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

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

[master] show session variables like %gtid_next%

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

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

1、Case 重現(xiàn)：

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

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

2、錯(cuò)誤編號(hào)：

last_Errno:1756

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

（1）、簡(jiǎn)單的 stop slave; start slave; 就能夠忽略錯(cuò)誤。但是這個(gè)時(shí)候主從的一致性已經(jīng)出現(xiàn)問(wè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 語(yǔ)句會(huì)生成兩個(gè) sql，一個(gè)是 DDL 創(chuàng)建表 SQL，一個(gè)是 insert into 插入數(shù)據(jù)的 sql。由于 DDL 會(huì)導(dǎo)致自動(dòng)提交，所以這個(gè) sql 至少需要兩個(gè) GTID，但是 GTID 模式下，只能給這個(gè) sql 生成一個(gè) GTID，如果強(qiáng)制執(zhí)行會(huì)導(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)一開(kāi)啟或者關(guān)閉 GTID 功能。

1、case 重現(xiàn)：

將一個(gè)未開(kāi)啟 gtid 的 slave 通過(guò)原始的 binlog 和 pos 方式連接到開(kāi)啟 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 中，如果開(kāi)啟 GTID 以后，就不再允許使用 classic 的復(fù)制方式：

1、case 重現(xiàn)：

將一個(gè)開(kāi)啟 gtid 的 slave 通過(guò)原始的 binlog 和 pos 方式連接到開(kāi)啟 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 開(kāi)啟需要重啟系統(tǒng)，一個(gè)復(fù)制組中所有的實(shí)例必須統(tǒng)一開(kāi)啟或者關(guān)閉 GTID, 開(kāi)啟 GTID 以后不能在使用 classic 復(fù)制。

問(wèn)題：

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

解決方案：

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

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

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

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

（七）、Temporary tables。

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

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

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

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

2、由于 GTID 協(xié)議的原因，最開(kāi)始已經(jīng)提過(guò)（參見(jiàn) GTID architecture）。

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

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

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

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

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