原標(biāo)題：記一次 PXC 集群拆分引發(fā)的思考

作者簡(jiǎn)介

冷正磊

2018年2月加入去哪兒網(wǎng) DBA 團(tuán)隊(duì)，主要負(fù)責(zé)機(jī)票業(yè)務(wù)的 MySQL 和 Redis 數(shù)據(jù)庫(kù)的運(yùn)維管理工作，以及數(shù)據(jù)庫(kù)自動(dòng)化運(yùn)維平臺(tái)部分功能的開(kāi)發(fā)工作，對(duì)數(shù)據(jù)庫(kù)技術(shù)具有濃厚興趣，具有多年 MySQL 和 Redis 運(yùn)維管理和性能優(yōu)化經(jīng)驗(yàn)。

1. 內(nèi)容摘要

眾所周知，MySQL 基于 GTID 復(fù)制功能的出現(xiàn)，極大地簡(jiǎn)化了 MySQL 復(fù)制拓?fù)涑跏蓟渲煤妥兏约案呖捎玫那袚Q。在去哪兒網(wǎng)，我們大量使用 PXC(Percona XtraDB Cluster)集群，然而 PXC 中用于記錄事務(wù)的 Galera GTID 與普通的 MySQL GTID 還是有一點(diǎn)差異，運(yùn)維過(guò)程中如果不加注意，可能會(huì)引發(fā)一些問(wèn)題。本文通過(guò)記錄一次 PXC 集群拆分的過(guò)程中由于未深刻理解這兩者的差別而導(dǎo)致的問(wèn)題與原因分析，總結(jié)了 Galera GTID 與 MySQL GTID 的異同點(diǎn)以及運(yùn)維過(guò)程中應(yīng)該注意的事項(xiàng)。

2. 背景

Qunar 機(jī)票核心業(yè)務(wù)某個(gè) PXC 集群 C1 由于運(yùn)行時(shí)間比較久，隨著業(yè)務(wù)的持續(xù)發(fā)展，集群?jiǎn)蝹€(gè)節(jié)點(diǎn)的實(shí)例數(shù)據(jù)大小已達(dá)到 5T 以上，對(duì)數(shù)據(jù)量如此大的 MySQL 集群進(jìn)行日常維護(hù)(備份、集群節(jié)點(diǎn)水平擴(kuò)容、實(shí)例遷移等)以及實(shí)例故障恢復(fù)都是一項(xiàng)比較耗時(shí)費(fèi)力的工作。經(jīng)過(guò)與研發(fā)討論后決定將集群 C1 中比較大的兩個(gè)庫(kù) DB1 和 DB2 拆分出來(lái)，組成一個(gè)新的 PXC 集群 C2。

集群拆分前后示意圖如下(正常每個(gè)集群有三個(gè)節(jié)點(diǎn)，為簡(jiǎn)單起見(jiàn)，每個(gè)集群只畫(huà)了一個(gè)節(jié)點(diǎn))：

3. 方案簡(jiǎn)要說(shuō)明

PXC 集群進(jìn)行庫(kù)的拆分，大致流程是使用當(dāng)前集群 C1 的任意一個(gè)節(jié)點(diǎn)做一個(gè)全量副本，利用這個(gè)副本再做2個(gè)節(jié)點(diǎn)的數(shù)據(jù)，組建一個(gè)三節(jié)點(diǎn)的新集群 C2。同時(shí)為了保持?jǐn)?shù)據(jù)的一致性，新集群 C2 的寫(xiě)節(jié)點(diǎn)作為原有集群 C1 某個(gè)節(jié)點(diǎn)的從庫(kù)，不斷同步集群 C1 的數(shù)據(jù)更新。

原計(jì)劃是第一步先遷移 DB1，主要流程為：

業(yè)務(wù)方下線(xiàn)集群 C1 上與 DB1 相關(guān)的應(yīng)用服務(wù)，停止對(duì)該庫(kù)中所有表的寫(xiě)入。

為了防止遺漏的應(yīng)用服務(wù)對(duì) DB1 進(jìn)行寫(xiě)入，DBA 將該庫(kù)里面所有的表進(jìn)行改名，即加一個(gè)統(tǒng)一的后綴(需提前準(zhǔn)備好腳本)。

DBA 確認(rèn)兩個(gè)集群直接主從同步無(wú)延遲后，在新集群 C2 上恢復(fù) DB1 所有表的名稱(chēng)，即去掉第2步中添加的后綴(需提前準(zhǔn)備好腳本)。

業(yè)務(wù)方發(fā)布新的應(yīng)用服務(wù)(業(yè)務(wù)方已提前修改好代碼中的數(shù)據(jù)源配置)，開(kāi)始訪(fǎng)問(wèn)集群 C2 中的 DB1，各系統(tǒng)驗(yàn)證業(yè)務(wù)是否正常。

第二步是在完成第一步之后，仍然保持兩個(gè)集群之間主從同步關(guān)系，等使用 C2 中 DB1 相關(guān)的業(yè)務(wù)確認(rèn)無(wú)問(wèn)題后以同樣的方式遷移 DB2。

全部遷移完后觀(guān)察一段時(shí)間，確認(rèn)各業(yè)務(wù)流程正常，最后刪除兩個(gè)集群中不需要的 DB。

其中第一步操作過(guò)程如下：

不過(guò)在順利完成第一步后出現(xiàn)了意外，原本應(yīng)該正常同步數(shù)據(jù)的兩個(gè)集群出現(xiàn)了復(fù)制中斷，根據(jù)報(bào)錯(cuò)信息發(fā)現(xiàn)大量的數(shù)據(jù)(除 DB1 之外的庫(kù))在集群 C2 上找不到對(duì)應(yīng)的記錄，由于兩個(gè)集群中 DB2 的數(shù)據(jù)沒(méi)法保證一致性，導(dǎo)致不得不中止后續(xù)的遷移計(jì)劃，以至于集群 C2 上只完成了庫(kù) DB1 的遷移。

4. 問(wèn)題分析與復(fù)現(xiàn)4.1 問(wèn)題分析

正常來(lái)說(shuō)，集群 C1 已經(jīng)徹底停止(表名已改)了對(duì) DB1 中表的寫(xiě)入，而集群 C2 上只會(huì)對(duì) DB1 中表進(jìn)行寫(xiě)入，其他庫(kù)的寫(xiě)入不受影響，應(yīng)該正常復(fù)制才對(duì)。

既然復(fù)制出現(xiàn)了問(wèn)題，那么原有的“理所當(dāng)然”的想法肯定存在不合理的地方。經(jīng)過(guò)排查，我們發(fā)現(xiàn)了一個(gè)令人匪夷所思的問(wèn)題，兩個(gè)集群用作復(fù)制的兩個(gè)節(jié)點(diǎn)，從庫(kù)和主庫(kù)的 GTID 的 部分竟然是一樣的，導(dǎo)致從庫(kù)在對(duì) DB1 進(jìn)行寫(xiě)入后，生成的 GTID 的 值比主庫(kù)上大，當(dāng)接收主庫(kù)推送過(guò)來(lái)的 binlog 數(shù)據(jù)時(shí)，發(fā)現(xiàn)主庫(kù)事務(wù)的 GTID 的 值比自己的小，于是從庫(kù)直接選擇了跳過(guò)該事務(wù)，并沒(méi)有重放這部分 binlog，從而出現(xiàn)了主從數(shù)據(jù)不一樣的情況。

4.2 復(fù)現(xiàn)過(guò)程

為什么新建的從庫(kù)生成的 GTID 的 會(huì)和主庫(kù)一樣呢？為了找到問(wèn)題的原因，我們?cè)跍y(cè)試環(huán)境用同樣的流程對(duì)出現(xiàn)的問(wèn)題進(jìn)行復(fù)現(xiàn)。

首先我們復(fù)盤(pán)了下搭建主從復(fù)制的過(guò)程，大致如下：

1、使用 Xtrabackup 備份集群 C1 某個(gè)節(jié)點(diǎn)的全量數(shù)據(jù)，并將數(shù)據(jù)傳送到目的服務(wù)器，用于新建集群 C2 的第一個(gè)節(jié)點(diǎn)。

2、在目的服務(wù)器 apply 備份日志后，根據(jù)生成的文件 xtrabackup_ binlog_info 中的內(nèi)容找到復(fù)制信息。

# catxtrabackup_binlog_info

mysql-bin.000015997 401 cdbc9-e228-ee17-496f-5c53bc36ae5b:1-1123,

c05582e9-dc11-ee14-6b06-c041b8b7ff2d:1-4,

da5e0de8-dc13-ee14-76e6-f074e061cc69:1-2

3、新建文件 grastate.dat，并根據(jù) apply 后生成的文件 xtrabackup_galera_info中的內(nèi)容填寫(xiě) grastate.dat 文件信息。

# cat xtrabackup_galera_info

3faa7d16-23ee-11eb-94f9-3fbe474800d2:4

# vim grastate.dat# GALERA saved stateversion: 2.1uuid: 3faa7d16-23ee-11eb-94f9-3fbe474800d2seqno: 4safe_to_bootstrap: 1

4、 以 bootstrap-pxc 方式啟動(dòng)該實(shí)例，作為集群 C2 的第一個(gè)節(jié)點(diǎn)，并與老集群 C1 建立復(fù)制關(guān)系。

# 啟動(dòng)實(shí)例/etc/init.d/mysql.server -P 3311 bootstrap-pxcmysql> reset slave all;Query OK, 0 rows affected (0.00 sec)

# 建立新的復(fù)制mysql> set wsrep_on = 0;Query OK, 0 rows affected (0.00 sec)

mysql> reset master;Query OK, 0 rows affected (0.00 sec)

mysql> set wsrep_on = 1;Query OK, 0 rows affected (0.00 sec)

mysql> SET GLOBAL gtid_purged='401cdbc9-e228-ee17-496f-5c53bc36ae5b:1-1123,c05582e9-dc11-ee14-6b06-c041b8b7ff2d:1-4,da5e0de8-dc13-ee14-76e6-f074e061cc69:1-2';Query OK, 0 rows affected (0.01 sec)

mysql> change master to master_host='10.86.41.xxx',master_port=3306,master_user='replication',master_password='xxxxxxxxxx',master_auto_position=1;Query OK, 0 rows affected, 2 warnings (0.02 sec)

mysql> start slave;Query OK, 0 rows affected (0.00 sec)

# 集群C2此時(shí)的master信息mysql> show master statusG*************************** 1. row ***************************File: mysql-bin.000002Position: 271Binlog_Do_DB:Binlog_Ignore_DB:Executed_Gtid_Set: 401cdbc9-e228-ee17-496f-5c53bc36ae5b:1-1123,c05582e9-dc11-ee14-6b06-c041b8b7ff2d:1-4,da5e0de8-dc13-ee14-76e6-f074e061cc69:1-21 row in set (0.00 sec)

5、 向集群 C1 中未遷移的庫(kù) test2 中正常寫(xiě)入數(shù)據(jù)，觀(guān)察主從 master 信息。

# 寫(xiě)入前集群C1的master狀態(tài)mysql> show master statusG*************************** 1. row ***************************File: mysql-bin.000015Position: 997Binlog_Do_DB:Binlog_Ignore_DB:Executed_Gtid_Set: 401cdbc9-e228-ee17-496f-5c53bc36ae5b:1-1123,c05582e9-dc11-ee14-6b06-c041b8b7ff2d:1-4,da5e0de8-dc13-ee14-76e6-f074e061cc69:1-21 row in set (0.00 sec# 向集群C1的庫(kù)test2中寫(xiě)入兩個(gè)事務(wù)的數(shù)據(jù)后master狀態(tài)mysql> use test2;mysql> insert into t values(13);Query OK, 1 row affected (0.00 sec)

mysql> insert into t values(14);Query OK, 1 row affected (0.00 sec)

mysql> show master statusG*************************** 1. row ***************************File: mysql-bin.000015Position: 1481Binlog_Do_DB:Binlog_Ignore_DB:Executed_Gtid_Set: 401cdbc9-e228-ee17-496f-5c53bc36ae5b:1-1123,c05582e9-dc11-ee14-6b06-c041b8b7ff2d:1-6, # 發(fā)生變化的GTIDda5e0de8-dc13-ee14-76e6-f074e061cc69:1-21 row in set (0.00 sec)

# 此時(shí)集群C2的master信息mysql> show master statusG*************************** 1. row ***************************File: mysql-bin.000002Position: 735Binlog_Do_DB:Binlog_Ignore_DB:Executed_Gtid_Set: 401cdbc9-e228-ee17-496f-5c53bc36ae5b:1-1123,c05582e9-dc11-ee14-6b06-c041b8b7ff2d:1-6, # 發(fā)生變化的GTID，同步正常da5e0de8-dc13-ee14-76e6-f074e061cc69:1-21 row in set (0.00 sec)

此時(shí)復(fù)制沒(méi)有問(wèn)題，數(shù)據(jù)也是正常的。

6、向集群 C2 中已遷移的庫(kù) test1 中寫(xiě)入兩個(gè)事務(wù)的數(shù)據(jù)，觀(guān)察主從 master 信 息。

mysql> insert into t values(7);Query OK, 1 row affected (0.00 sec)mysql> insert into t values(8);Query OK, 1 row affected (0.00 sec)

mysql> show master statusG*************************** 1. row ***************************File: mysql-bin.000002Position: 1209Binlog_Do_DB:Binlog_Ignore_DB:Executed_Gtid_Set: 401cdbc9-e228-ee17-496f-5c53bc36ae5b:1-1123,c05582e9-dc11-ee14-6b06-c041b8b7ff2d:1-8, # 寫(xiě)入后，從節(jié)點(diǎn)發(fā)生變化的GTIDda5e0de8-dc13-ee14-76e6-f074e061cc69:1-21 row in set (0.00 sec)

7、 此后如果集群 C1 上繼續(xù)寫(xiě)入一個(gè)事務(wù)。

mysql> delete from t where id = 13; # 刪除test2庫(kù)t表中id=13的記錄Query OK, 1 row affected (0.00 sec)# 集群C1的master信息mysql> show master statusG*************************** 1. row ***************************File: mysql-bin.000015Position: 1723Binlog_Do_DB:Binlog_Ignore_DB:Executed_Gtid_Set: 401cdbc9-e228-ee17-496f-5c53bc36ae5b:1-1123,c05582e9-dc11-ee14-6b06-c041b8b7ff2d:1-7, # GTID的gno增加1da5e0de8-dc13-ee14-76e6-f074e061cc69:1-21 row in set (0.00 sec)

# 集群C2的master信息mysql> show master statusG*************************** 1. row ***************************File: mysql-bin.000002Position: 1209Binlog_Do_DB:Binlog_Ignore_DB:Executed_Gtid_Set: 401cdbc9-e228-ee17-496f-5c53bc36ae5b:1-1123,c05582e9-dc11-ee14-6b06-c041b8b7ff2d:1-8, # GTID的gno沒(méi)有發(fā)生變化，因?yàn)橥竭^(guò)來(lái)的事務(wù)的GTID的gno值比自己小，選擇跳過(guò)da5e0de8-dc13-ee14-76e6-f074e061cc69:1-21 row in set (0.00 sec)

# 此時(shí)C1集群已經(jīng)被刪掉的記錄，在C2集群仍然存在mysql> use test2;Database changedmysql> select * from t where id = 13;+----+| id |+----+| 13 |+----+1 row in set (0.00 sec)

從測(cè)試過(guò)程中發(fā)現(xiàn)，確實(shí)通過(guò)以上的方式搭建主從節(jié)點(diǎn)后，存在主從節(jié)點(diǎn)寫(xiě)入后 GTID 值的部分相同的情況，此時(shí)如果主從節(jié)點(diǎn)同時(shí)發(fā)生寫(xiě)入(針對(duì)不同的庫(kù))，就會(huì)導(dǎo)致主從節(jié)點(diǎn)數(shù)據(jù)不一致。

4.3 問(wèn)題原因

對(duì)問(wèn)題復(fù)現(xiàn)過(guò)程進(jìn)行分析后，發(fā)現(xiàn)整個(gè)過(guò)程有一步是多余的，即步驟3(新建 grastate.dat 文件)，因?yàn)槲覀兊哪康氖峭ㄟ^(guò)搭建從庫(kù)的方式組建一個(gè)新的集群，而不是對(duì)原有集群擴(kuò)增節(jié)點(diǎn)，所以在該 slave 節(jié)點(diǎn)(針對(duì)原集群而言)以 bootstrap 方式啟動(dòng)時(shí)，不需要指定原來(lái)的集群信息。

當(dāng)以 bootstrap 方式啟動(dòng) PXC 實(shí)例時(shí)，如果 grastate.dat 文件存在，那么該實(shí)例會(huì)從該文件中獲取 uuid 參數(shù)的值，賦值給參數(shù) wsrep_ cluster_state_uuid，同時(shí)該參數(shù)的值也決定了事務(wù)的 Galera GTID 中的 部分，所以導(dǎo)致這個(gè)實(shí)例的與原集群中節(jié)點(diǎn)的 相同，當(dāng)作為主從的兩個(gè)節(jié)點(diǎn)都有寫(xiě)入時(shí)，從庫(kù)在應(yīng)用 binlog 時(shí)就會(huì)出現(xiàn)沖突或者忽略的情況，導(dǎo)致主從數(shù)據(jù)不一致。

5. 如何改進(jìn)

通過(guò)此次集群拆分過(guò)程中出現(xiàn)的問(wèn)題，總結(jié)下原因以及改進(jìn)措施，避免后續(xù)工作中出現(xiàn)類(lèi)似情況：

5.1 原因

延用了前期類(lèi)似經(jīng)驗(yàn)的慣性思維。因?yàn)樵诖酥坝羞^(guò)兩次類(lèi)似的遷移操作，只不過(guò)當(dāng)時(shí)只需遷移一個(gè)庫(kù)，在原集群停止該庫(kù)的寫(xiě)入后，等從庫(kù)復(fù)制無(wú)延遲后就馬上斷開(kāi)了復(fù)制，所以沒(méi)有出現(xiàn)后續(xù)復(fù)制的問(wèn)題。

操作流程不夠精細(xì)。操作過(guò)程中沒(méi)有嚴(yán)格區(qū)分 PXC 集群新增節(jié)點(diǎn)和拆分集群的流程差異，細(xì)節(jié)之處欠缺考慮，也反映出個(gè)人在對(duì) PXC 的使用和原理方面研究不夠深入。5.2 改進(jìn)措施

分別制定 PXC 集群新增節(jié)點(diǎn)和拆分集群的操作規(guī)范，在運(yùn)維操作時(shí)嚴(yán)格按照規(guī)范執(zhí)行。

優(yōu)化集群拆分方案。比如可建立一個(gè)中間節(jié)點(diǎn)，對(duì)要遷移的數(shù)據(jù)庫(kù)進(jìn)行過(guò)濾復(fù)制，然后再同步到新集群中，可節(jié)省組建新集群的時(shí)間，同時(shí)可避免后續(xù)在新集群上刪除多余的庫(kù)。

3. 在標(biāo)準(zhǔn)規(guī)范的基礎(chǔ)上，實(shí)現(xiàn)運(yùn)維操作自動(dòng)化，避免人為主觀(guān)因素造成影響。

6. 關(guān)于 Galera GTID 與 MySQL GTID 的比較6.1 GTID 的概念

GTID 特性是 MySQL5.6加入的一個(gè)強(qiáng)大的特性，全稱(chēng)是 Global Transaction Identifier。MySQL 會(huì)為每一個(gè) DML/DDL 操作增加一個(gè)唯一標(biāo)記叫做 GTID，這個(gè)標(biāo)記在整個(gè)復(fù)制環(huán)境中都是唯一的，格式為 。

GTID 相關(guān)的幾個(gè)常見(jiàn)術(shù)語(yǔ)：

server_ uuid：單個(gè) GTID 的前半部分，即 部分，是一個(gè)32字節(jié)+1字節(jié)(/0)的字符串。

gno：單個(gè) GTID 的后半部分，即 部分，表示事務(wù)的序號(hào)，gno 的值從全局計(jì)數(shù)器 next_ free_ gno 中獲取的。

GTID SET：表示一個(gè) GTID 的集合，可以包含多個(gè) server_ uuid，如 executed_ gtid、gtid_ purged。

GTID SET Interval：GTID SET 中某個(gè) server_uuid 可能包含多個(gè)區(qū)間，比如 GTID 為“23d45aa2-3d1f-11e6-a16b-c81f66e1165d:1-99:110-200”的字符串中，GTID SET Interval 分別是“1-99”和“110-200”。6.2 GTID 的生成

GTID 是在 SQL 的 commit 命令發(fā)起后，order commit 執(zhí)行到 flush 階段需要生成 GTID Event 的時(shí)候才會(huì)獲取。MySQL 內(nèi)部維護(hù)了一個(gè)全局的 GTID 的計(jì)數(shù)器 next_ free_gno 用于生成 gno。

可參考函數(shù) Gtid_ state∶getautomatic_gno，部分代碼如下∶

// 定義∶Gtid next_candidate={ sidno,sidno == get_server_sidno? next_free_gno: 1};// 賦值∶while( true){constGtid_set::Interval *iv= ivit.getO;// 定義IntervaL指針指向這個(gè)鏈表指針開(kāi)頭，如果在進(jìn)行下次循環(huán)會(huì)獲得NULLrpl_gno next_interval_start=iv != NULL? iv->start: MAX_GNO;// 正常情況下不會(huì)為NULL，因此 next_interval_start 等于第一個(gè)interval的start，當(dāng)然如果初始化會(huì)為NULL，如果Interval->next =NULL 則標(biāo)示設(shè)有區(qū)間了。while(next_candidate.gno < next_interval_start &&DBUG_EVALUATE_IF( "simulate_gno_exhausted", false, true))// 如果next_candidate.gno正常不會(huì)小于next_intervalL_start// 如果Interval->next =NULL或者初始化next_interval_start會(huì)被置為MAX_GNO，那么條件成立DBUG_RETURN(next_candidate.gno);// 返回了這個(gè)gno 則GTID生成{// 返回gno，GTID生成if(owned_gtids.get_ownernext_candidate)==O)DBUG_RETURN(next_candidate.gno)// 如果本GTID已經(jīng)被其他線(xiàn)程占用，則next_candidate.gno++ 繼續(xù)判斷next_candidate.gno++;}......}

6.3 server_uuid 的生成

MySQL 在啟動(dòng)的時(shí)候會(huì)調(diào)用 init_ server_auto_ options 來(lái)讀取 auto.cnf 文件。如果 auto.cnf 文件不存在，則會(huì)調(diào)用函數(shù) generate_server_ uuid 來(lái)生成一個(gè)新的 server_uuid，這時(shí) GTID 會(huì)發(fā)生改變。

當(dāng) auto.cnf 文件不存在時(shí)，調(diào)用函數(shù) generate_ serve_ruid 生成 server_ uuid 的過(guò)程中可以看出，server_uuid 的生成至少和下面部分有關(guān)∶

數(shù)據(jù)庫(kù)的啟動(dòng)時(shí)間。

線(xiàn)程的 LWP ID。LWP 是輕量級(jí)進(jìn)程(light-weight process)的簡(jiǎn)稱(chēng)。

一個(gè)隨機(jī)的內(nèi)存地址。

下面是部分代碼供參考∶

// 獲取MySqL啟動(dòng)時(shí)間consttime_t save_server_start_time=server_start_time;// 加入LWP號(hào)運(yùn)算server_start_time+=((ulonglong)current_pid << 48)+current_pid;// 一個(gè)內(nèi)存指針，即線(xiàn)程結(jié)構(gòu)體的內(nèi)存地址thd->status_var.bytes_sent=(ulonglong)thd;// 具體的運(yùn)算過(guò)程lex_start(thd);func_uuid= new(thd->mem_root)Item_func_uuid;func_uuid->fixed= 1;func_uid->vaL_str(&uuid);

6.4 Galera GTID

PXC 集群記錄事務(wù)的 Galera GTID 中 的生成邏輯與 MySQL GTID 的不太一樣，而且也不是 PXC 集群的 wsrep_ cluster_state_uuid，還是以上面的 PXC 集群 C2 為例，看下這個(gè)幾個(gè)參數(shù)的值：

mysql> select @@server_uuid;+--------------------------------------+| @@server_uuid |+--------------------------------------+| 4fd32e4d-249f-11eb-8fd9-fa163e05f092 |+--------------------------------------+1row inset ( 0. 00sec)mysql> select @@global.gtid_executed;+---------------------------------------------------------------------------------------------------------------------------------+| @@global.gtid_executed |+---------------------------------------------------------------------------------------------------------------------------------+| 401cdbc9-e228-ee17-496f-5c53bc36ae5b:1-1123,c05582e9-dc11-ee14-6b06-c041b8b7ff2d:1-8,da5e0de8-dc13-ee14-76e6-f074e061cc69:1-2 |+---------------------------------------------------------------------------------------------------------------------------------+1row inset ( 0. 00sec)

mysql> show status like 'wsrep_%_uuid';+--------------------------+--------------------------------------+| Variable_name |Value |+--------------------------+--------------------------------------+|wsrep_local_state_uuid | 3faa7d16-23ee-11eb-94f9-3fbe474800d2 || wsrep_gcomm_uuid |4f807d05- 249f- 11eb-a679-ea70d2c3575a ||wsrep_cluster_state_uuid | 3faa7d16-23ee-11eb-94f9-3fbe474800d2 |+--------------------------+--------------------------------------+3rows inset ( 0. 00sec)

可以看到，PXC 集群中實(shí)例的 server_ uuid 并不在它的 GTID SET 中，當(dāng) PXC 集群寫(xiě)入數(shù)據(jù)時(shí)，生成的 MySQL GTID 的，也不是服務(wù)器的 server_uuid。

實(shí)際上在 PXC 集群中這么設(shè)計(jì)合理的，因?yàn)?PXC 是一個(gè)分布式可多寫(xiě)的集群架構(gòu)，所有節(jié)點(diǎn)共享相同的 ，當(dāng)在不同的節(jié)點(diǎn)寫(xiě)入數(shù)據(jù)時(shí)，將產(chǎn)生同樣的 GTID SET，看起來(lái)不同的事務(wù)像是在同一個(gè)服務(wù)器上執(zhí)行的。

6.5 Galera GTID vs MySQL GTID

兩種 GTID 使用的格式相同，即 。

對(duì)于 Galera 來(lái)說(shuō)，在集群以 bootstrap 啟動(dòng)時(shí)會(huì)生成 ，且集群中的所有節(jié)點(diǎn)共享此 。

所以說(shuō) PXC 集群中各節(jié)點(diǎn)之間用作同步的 Galera GTID 和 MySQL GTID 之間并沒(méi)有直接關(guān)系，在運(yùn)維過(guò)程中切記不要搞混淆。

參考資料：

1、簡(jiǎn)書(shū)專(zhuān)欄《深入理解主從原理32講》 作者：重慶八怪2、《MySQL 運(yùn)維內(nèi)參》 作者：周彥偉、王竹峰、強(qiáng)昌金

責(zé)任編輯：

創(chuàng)作挑戰(zhàn)賽新人創(chuàng)作獎(jiǎng)勵(lì)來(lái)咯，堅(jiān)持創(chuàng)作打卡瓜分現(xiàn)金大獎(jiǎng)

總結(jié)

以上是生活随笔為你收集整理的mysql gtid 还是pxc_记一次 PXC 集群拆分引发的思考的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

如果覺(jué)得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。