昨天的一篇文章MySQL自增列主從不一致的測試(r12筆記第37天)，今天有不少網友向我確認一些細節，我想最近正好在看GTID的東西，可以揉在一起來說說。

GTID這個概念看似簡單，實際上還是有不少的門道。

我們來從架構的設計角度來看看存在哪些場景需要考慮GTID的變化。

一主兩從的架構模式下GTID的變化

我們就以一主兩從的架構為基準進行闡述。在這個架構模式下我們會用到MHA的方案。

如果這個時候Master節點宕機了，MHA就會開啟檢查機制。

這個時候Slave 1節點就會變為新的Master,Slave 2會從Slave 1上重新應用資料變更，這個時候GTID是怎麼變化的，從庫的Executed GTID Set到底是一個還是兩個。

這個場景繼續往下延伸。如果宕機的主庫啟動之後，假設是硬體問題，比如電源故障燈原因，Master節點啟動了，那麼Master節點的重新加入主從環境中GTID是如何變化的。這樣就是下面的架構圖了。

而我們把這個問題繼續細化，那就是和自增列值的問題結合起來。看看在這種場景下，MySQL的實現方式是否會出現資料不一致，無法複製的情況。兩者結合起來算是一個相對完整的測試場景了。當然我要標記為第一篇，因為還會有第二篇出來。

我們看看如何操作。

一主兩從的架構模式下GTID的實踐

一主兩從我們標識為主（Master節點），從庫1（Slave 1）,從庫2 （Slave 2）,大體的測試步驟如下：

1. 初始化一主兩從
2. Master節點初始化資料，測試自增列值
3. 配置MHA,Master節點宕機
4. MHA切換，Slave 1節點升為主庫，Slave 2節點為從庫
5. Master節點啟動
6. Master節點加入主從複製環境

步驟1：初始化，得到一主兩從的GTID情況

步驟1相對簡單，可以使用sandbox或者是快速指令碼的方式搭建。

搭建完成後，先來看看Gtid的情況。

mysql> show master statusG *************************** 1. row *************************** File: binlog.000001 Position: 1475

mysql> show global variables like 'server_uuid%'; +----------------+--------------------------------------+ | Variable_name | Value | +----------------+--------------------------------------+ | server_uuid | 4f7b0b93-2400-11e7-99cb-782bcb377193 +----------------+--------------------------------------+ 3 rows in set (0.01 sec)

我們後續的測試都會參考這個值。 Slave 1節點的情況如下,和Master節點的server_uuid明顯不同。這個資訊可以在初始化的目錄auto.cnf可以得到。

mysql> show global variables like 'server%'; +----------------+--------------------------------------+ | Variable_name | Value | +----------------+--------------------------------------+ | server_id | 24802 | | server_id_bits | 32 | | server_uuid | 5433468e-2400-11e7-a834-782bcb377193 +----------------+--------------------------------------+

檢視master status的資訊如下，這一點可以看出是和Master節點的Gtid Set值相同，證明這個Gtid的值是一個唯一性標識，當然從GTID的全稱就是全域性事務標識。

mysql> show master statusG *************************** 1. row *************************** File: binlog.000001 Position: 438 Binlog_Do_DB: Binlog_Ignore_DB: Executed_Gtid_Set: 4f7b0b93-2400-11e7-99cb-782bcb377193:1-7 1 row in set (0.00 sec)

我們來看看show slave status的結果。 mysql> show slave statusG *************************** 1. row *************************** Slave_IO_State: Waiting for master to send event Master_Host: 10.127.128.78 Master_User: rpl_user 。。。 Retrieved_Gtid_Set: 4f7b0b93-2400-11e7-99cb-782bcb377193:6-7 Executed_Gtid_Set: 4f7b0b93-2400-11e7-99cb-782bcb377193:1-7 。。。 1 row in set (0.00 sec)

步驟2:初始化Master節點，測試自增列問題

步驟2我們來初始化一下Master節點。就建立一個數據庫test create database test;Slave 1節點的情況如下,可以看到末尾的事務ID序號開始增加。 mysql> show master statusG *************************** 1. row *************************** File: binlog.000001 Position: 589 Binlog_Do_DB: Binlog_Ignore_DB: Executed_Gtid_Set: 4f7b0b93-2400-11e7-99cb-782bcb377193:1-8

下面的初始化就是關鍵了，我們會測試自增列的情況，來複現一個經典問題。建立一個表t1，然後插入3條記錄。 mysql> drop table if exists t1; mysql> create table t1(id int auto_increment, a int, primary key (id)) engine=innodb; mysql> insert into t1 values (1,2); mysql> insert into t1 values (null,2); mysql> insert into t1 values (null,2); mysql> select *from t1; +----+------+ | id | a | +----+------+ | 1 | 2 | | 2 | 2 | | 3 | 2 | +----+------+

毫無疑問，這個時候自增列的值是4.

mysql> show create table t1G *************************** 1. row *************************** Table: t1 Create Table: CREATE TABLE `t1` ( `id` int(11) NOT NULL AUTO_INCREMENT, `a` int(11) DEFAULT NULL, PRIMARY KEY (`id`) ) ENGINE=InnoDB AUTO_INCREMENT=4 DEFAULT CHARSET=latin1

在Slave 1節點和Slave 2節點得到的資料情況是一致的，都是4 然後我們做下面的變更，刪除表中id=3的值。這個情況也很容易理解，那就是自增列不會變化。

mysql> delete from t1 where id=3; mysql> show create table t1G *************************** 1. row *************************** Table: t1 Create Table: CREATE TABLE `t1` ( `id` int(11) NOT NULL AUTO_INCREMENT, `a` int(11) DEFAULT NULL, PRIMARY KEY (`id`) ) ENGINE=InnoDB AUTO_INCREMENT=4 DEFAULT CHARSET=latin1 Slave 1節點和Slave 2節點也是如此，自增列值都是4

步驟3：配置MHA,Master節點宕機

這個步驟可以參考 sandbox和MHA快速測試(r12筆記第32天)，對MHA的配置有一個基本的介紹，可以使用如下的兩個指令碼來做基本的檢驗，app1.cnf就是基礎的配置檔案。內容大體如下：

[server default] manager_workdir=/home/mha/manager manager_log=/home/mha/manager/app1/manager.log port=24801 -指定的埠 user=mha_test password=mha_test --需要提前建立 repl_user=rpl_user repl_password=rpl_pass master_ip_failover_script= /home/mha/conf/master_ip_failover2 # shutdown_script= /script/masterha/power_manager # report_script= /script/masterha/send_report # master_ip_online_change_script= /script/masterha/master_ip_online_change [server1] hostname=10.127.128.78 port=24801 candidate_master=1 [server2] hostname=10.127.128.78 candidate_master=1 port=24802 [server3] hostname=10.127.128.78 candidate_master=1 port=24803ssh的互信檢查。

# masterha_check_ssh --conf=app1.cnf主從複製的檢查。

# masterha_check_repl --conf=app1.cnf 檢查無誤後，我們啟動MHA manager服務。

nohup masterha_manager --conf=/home/mha/conf/app1.cnf > /tmp/mha_manager.log 2>&1 & 然後我們查到對應的程序號，直接Kill即可。

[root@grtest app1]# ps -ef|grep 24801 mysql 2168 1918 0 14:29 pts/7 00:00:00 /usr/local/mysql/bin/mysqld --defaults-file=/home/data/s1/s1.cnf --basedir=/usr/local/mysql_5.7.17 --datadir=/home/data/s1 --plugin-dir=/usr/local/mysql_5.7.17/lib/plugin --user=mysql --log-error=/home/data/s1/grtest.err --pid-file=/home/data/s1/grtest.pid --socket=/home/data/s1/s1.sock --port=24801 root 3623 12108 0 14:40 pts/7 00:00:00 grep 24801 [root@grtest app1]# kill -9 1918 2168我們簡單描述一下，Master節點殺掉後，主庫的表t1的自增列值如果啟動之後就會是3，即上一次的max(id)+1開始計算。而從庫的自增列值為4，這個該怎麼平衡呢？

步驟4：MHA切換，Slave1節點為主庫

整個切換的過程是自動完成的，MHA會檢測心跳，然後自動開始切換主從複製關係。整個過程GTID就是一個需要注意的地方。 Started automated(non-interactive) failover. Invalidated master IP address on 10.127.128.78(10.127.128.78:24801) Selected 10.127.128.78(10.127.128.78:24802) as a new master. 10.127.128.78(10.127.128.78:24802): OK: Applying all logs succeeded. 10.127.128.78(10.127.128.78:24802): OK: Activated master IP address. 10.127.128.78(10.127.128.78:24803): OK: Slave started, replicating from 10.127.128.78(10.127.128.78:24802) 10.127.128.78(10.127.128.78:24802): Resetting slave info succeeded. Master failover to 10.127.128.78(10.127.128.78:24802) completed successfully.

於是Slave 1節點就正式接管環境。

檢視新主庫Slave 1節點的資訊如下,這個GTID還是原來Master節點的。

mysql> show master statusG *************************** 1. row *************************** File: binlog.000001 Position: 1895 Binlog_Do_DB: Binlog_Ignore_DB: Executed_Gtid_Set: 4f7b0b93-2400-11e7-99cb-782bcb377193:1-14

server_uuid的部分還是原來的設定。

mysql> show global variables like 'server%'; +----------------+--------------------------------------+ | Variable_name | Value | +----------------+--------------------------------------+ | server_id | 24802 | | server_id_bits | 32 | | server_uuid | 5433468e-2400-11e7-a834-782bcb377193 | +----------------+--------------------------------------+

這個地方需要關注，那就是檢視自增列的情況，因為原來是從庫，所以得到的最新值為4.

mysql> show create table t1G *************************** 1. row *************************** Table: t1 Create Table: CREATE TABLE `t1` ( `id` int(11) NOT NULL AUTO_INCREMENT, `a` int(11) DEFAULT NULL, PRIMARY KEY (`id`) ) ENGINE=InnoDB AUTO_INCREMENT=4 DEFAULT CHARSET=latin1

在這種情況下Slave 2節點就會重新調整複製關係， mysql> show slave statusG *************************** 1. row *************************** Slave_IO_State: Waiting for master to send event Master_Host: 10.127.128.78 Master_User: rpl_user Master_Port: 24802 。。。 Retrieved_Gtid_Set: Executed_Gtid_Set: 4f7b0b93-2400-11e7-99cb-782bcb377193:1-14 Auto_Position: 1 。。。 檢視自增列的情況如下： mysql> show create table t1G *************************** 1. row *************************** Table: t1 Create Table: CREATE TABLE `t1` ( `id` int(11) NOT NULL AUTO_INCREMENT, `a` int(11) DEFAULT NULL, PRIMARY KEY (`id`) ) ENGINE=InnoDB AUTO_INCREMENT=4 DEFAULT CHARSET=latin1

這裡可能會有些疑惑，而且對於GTID的理解會有一些誤差，我們在Slave 1節點上插入一行資料。 mysql> insert into t1 values(null,2);這個時候檢視自增列的情況如下，會逐步遞增。

mysql> show create table t1G *************************** 1. row *************************** Table: t1 Create Table: CREATE TABLE `t1` ( `id` int(11) NOT NULL AUTO_INCREMENT, `a` int(11) DEFAULT NULL, PRIMARY KEY (`id`) ) ENGINE=InnoDB AUTO_INCREMENT=5 DEFAULT CHARSET=latin1

這個時候就需要重新檢視下Gtid的情況了。可以看到這裡有原來Master節點的server_uuid,也有當前新主庫的server_uuid值。

mysql> show master statusG *************************** 1. row *************************** File: binlog.000001 Position: 2133 Binlog_Do_DB: Binlog_Ignore_DB: Executed_Gtid_Set: 4f7b0b93-2400-11e7-99cb-782bcb377193:1-14, 5433468e-2400-11e7-a834-782bcb377193:1

新的從庫Slave 2節點的資訊如下：

節點3： mysql> mysql> show slave statusG *************************** 1. row *************************** Slave_IO_State: Waiting for master to send event Master_Host: 10.127.128.78 Master_User: rpl_user Master_Port: 24802 。。。 Retrieved_Gtid_Set: 5433468e-2400-11e7-a834-782bcb377193:1 Executed_Gtid_Set: 4f7b0b93-2400-11e7-99cb-782bcb377193:1-14, 5433468e-2400-11e7-a834-782bcb377193:1 Auto_Position: 1 。。。 所以可以發現failover以後的自增列值不會受到影響，而且GTID set會包含當前主庫和原來的主庫資訊。

步驟5：Master節點啟動

啟動Master節點步驟相對簡單。

# /usr/local/mysql_5.7.17/bin/mysqld_safe --defaults-file=/home/data/s1/s1.cnf &

啟動之後有很多細節需要確認，一個是關於master status的資訊。

mysql> show slave statusG Empty set (0.00 sec) mysql> show master statusG *************************** 1. row *************************** File: binlog.000002 Position: 190 Binlog_Do_DB: Binlog_Ignore_DB: Executed_Gtid_Set: 4f7b0b93-2400-11e7-99cb-782bcb377193:1-14

這個地方明顯不對，那是因為主從複製關係還沒有調整。 我們看看這個時候的自增列值情況。糾結的問題就是自增列之為3，而Slave 1節點和Slave 2節點的自增列值為5. mysql> show create table t1G *************************** 1. row *************************** Table: t1 Create Table: CREATE TABLE `t1` ( `id` int(11) NOT NULL AUTO_INCREMENT, `a` int(11) DEFAULT NULL, PRIMARY KEY (`id`) ) ENGINE=InnoDB AUTO_INCREMENT=3 DEFAULT CHARSET=latin1

步驟:6：Master節點加入主從複製環境

重新配置主從複製關係：

CHANGE MASTER TO MASTER_HOST='10.127.128.78', MASTER_PORT=24802, MASTER_AUTO_POSITION=1, MASTER_USER='rpl_user', MASTER_PASSWORD='rpl_pass';啟動新的從庫,啟動後會發現GTID會是兩個。

mysql> start slave; mysql> show slave statusG *************************** 1. row *************************** Slave_IO_State: Waiting for master to send event Master_Host: 10.127.128.78 Master_User: rpl_user Master_Port: 24802 。。。 Retrieved_Gtid_Set: 5433468e-2400-11e7-a834-782bcb377193:1 Executed_Gtid_Set: 4f7b0b93-2400-11e7-99cb-782bcb377193:1-14, 5433468e-2400-11e7-a834-782bcb377193:1 Auto_Position: 1 。。。

這個時候再次檢視自增列的情況。這個步驟看起來複雜一些，其實就是新的從庫會去接收應用在Slave 1節點上的資料變化，相當於在Master節點插入了一條記錄，導致這個自增列之繼續增加。

mysql> show create table t1G *************************** 1. row *************************** Table: t1 Create Table: CREATE TABLE `t1` ( `id` int(11) NOT NULL AUTO_INCREMENT, `a` int(11) DEFAULT NULL, PRIMARY KEY (`id`) ) ENGINE=InnoDB AUTO_INCREMENT=5 DEFAULT CHARSET=latin1 --id值 恢復了 1 row in set (0.00 sec)

我們可以檢視binlog的資訊來進行基本的驗證。 [root@grtest app1]# /usr/local/mysql_5.7.17/bin/mysqlbinlog -vv /home/data/s1/binlog.000002 ... BEGIN /*!*/; # at 310 #170418 14:44:01 server id 24802 end_log_pos 352 Table_map: `test`.`t1` mapped to number 219 # at 352 #170418 14:44:01 server id 24802 end_log_pos 392 Write_rows: table id 219 flags: STMT_END_F BINLOG ' sbX1WBPiYAAAKgAAAGABAAAAANsAAAAAAAEABHRlc3QAAnQxAAIDAwAC sbX1WB7iYAAAKAAAAIgBAAAAANsAAAAAAAEAAgAC//wEAAAAAgAAAA== '/*!*/; ### INSERT INTO `test`.`t1` ### SET ### @1=4 /* INT meta=0 nullable=0 is_null=0 */ ### @2=2 /* INT meta=0 nullable=1 is_null=0 */ # at 392 #170418 14:44:01 server id 24802 end_log_pos 419 Xid = 19 COMMIT/*!*/; SET @@SESSION.GTID_NEXT= 'AUTOMATIC' /* added by mysqlbinlog */ /*!*/; DELIMITER ; # End of log file /*!50003 SET COMPLETION_TYPE=@OLD_COMPLETION_TYPE*/; /*!50530 SET @@SESSION.PSEUDO_SLAVE_MODE=0*/;

這樣一來對於GTID的理解就會更加清晰一些。對於自增列的問題也會更加明確，確確實實目前能夠解決資料不一致的情況。