MySQL在5.6的版本推出了GTID復制，相比傳統的復制，GTID復制對於運維更加友好，這個事務是誰產⽣，產⽣多少事務，⾮常直接的標識出來，當然GTID也有限制，對於什么是GTID可以參考我之前的文章：MySQL 5.6 GTID Replication，那么今天主要是想和同學們分享一下關於從庫show slave status中的Retrieved_Gtid_Set和Executed_Gtid_Set。
[root@localhost][db1]> show variables like '%uuid%'; +---------------+--------------------------------------+ | Variable_name | Value | +---------------+--------------------------------------+ | server_uuid | 2a09ee6e-645d-11e7-a96c-000c2953a1cb | +---------------+--------------------------------------+ 1 row in set (0.00 sec) [root@localhost][db1]>
slave：
[root@localhost][(none)]> show variables like '%uuid%'; +---------------+--------------------------------------+ | Variable_name | Value | +---------------+--------------------------------------+ | server_uuid | 8ce853fc-6f8a-11e7-8940-000c29e3f5ab | +---------------+--------------------------------------+ 1 row in set (0.01 sec) [root@localhost][(none)]>
其中主庫的server-id是10，從庫的server-id是20
搭建好主從以后如果沒有數據寫入，那么show slave status是下面這樣的：
Replicate_Ignore_Server_Ids: Master_Server_Id: 10 Master_UUID: 2a09ee6e-645d-11e7-a96c-000c2953a1cb Master_Info_File: mysql.slave_master_info SQL_Delay: 0 SQL_Remaining_Delay: NULL Slave_SQL_Running_State: Slave has read all relay log; waiting for more updates Master_Retry_Count: 86400 Master_Bind: Last_IO_Error_Timestamp: Last_SQL_Error_Timestamp: Master_SSL_Crl: Master_SSL_Crlpath: Retrieved_Gtid_Set: Executed_Gtid_Set: Auto_Position: 1 Replicate_Rewrite_DB: Channel_Name: Master_TLS_Version:
如果在主庫創建表，並且寫入2條數據，那么是下面這樣的：
[root@localhost][db1]> create table t2 ( id int); Query OK, 0 rows affected (0.07 sec) [root@localhost][db1]> insert into t2 select 1; Query OK, 1 row affected (0.07 sec) Records: 1 Duplicates: 0 Warnings: 0 [root@localhost][db1]> insert into t2 select 2; Query OK, 1 row affected (0.02 sec) Records: 1 Duplicates: 0 Warnings: 0 [root@localhost][db1]>
從庫：
Replicate_Ignore_Server_Ids: Master_Server_Id: 10 Master_UUID: 2a09ee6e-645d-11e7-a96c-000c2953a1cb Master_Info_File: mysql.slave_master_info SQL_Delay: 0 SQL_Remaining_Delay: NULL Slave_SQL_Running_State: Slave has read all relay log; waiting for more updates Master_Retry_Count: 86400 Master_Bind: Last_IO_Error_Timestamp: Last_SQL_Error_Timestamp: Master_SSL_Crl: Master_SSL_Crlpath: Retrieved_Gtid_Set: 2a09ee6e-645d-11e7-a96c-000c2953a1cb:1-3 Executed_Gtid_Set: 2a09ee6e-645d-11e7-a96c-000c2953a1cb:1-3 Auto_Position: 1
主庫：
[root@localhost][db1]> show master status; +------------------+----------+--------------+------------------+------------------------------------------+ | File | Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set | +------------------+----------+--------------+------------------+------------------------------------------+ | mysql-bin.000001 | 912 | | | 2a09ee6e-645d-11e7-a96c-000c2953a1cb:1-3 | +------------------+----------+--------------+------------------+------------------------------------------+ 1 row in set (0.00 sec)
其中主庫的Executed_Gtid_Set為2a09ee6e-645d-11e7-a96c-000c2953a1cb:1-3
可以看見Retrieved_Gtid_Set: 2a09ee6e-645d-11e7-a96c-000c2953a1cb:1-3，Executed_Gtid_Set: 2a09ee6e-645d-11e7-a96c-000c2953a1cb:1-3，也就是說主庫產生了3個事務，從庫接受到了來自主庫的3個事務，並且都已經執行。
其中2a09ee6e-645d-11e7-a96c-000c2953a1cb是主庫的server-uuid。那么我們可以解析從庫的binlog再看看
# at 154 #170823 0:38:38 server id 10 end_log_pos 219 CRC32 0x6268641f GTID last_committed=0 sequence_number=1 SET @@SESSION.GTID_NEXT= '2a09ee6e-645d-11e7-a96c-000c2953a1cb:1'/*!*/; # at 219 #170823 0:38:38 server id 10 end_log_pos 316 CRC32 0x6c837618 Query thread_id=103 exec_time=0 error_code=0 use `db1`/*!*/; SET TIMESTAMP=1503419918/*!*/; SET @@session.pseudo_thread_id=103/*!*/; SET @@session.foreign_key_checks=1, @@session.sql_auto_is_null=0, @@session.unique_checks=1, @@session.autocommit=1/*!*/; SET @@session.sql_mode=1436549152/*!*/; SET @@session.auto_increment_increment=1, @@session.auto_increment_offset=1/*!*/; /*!\C utf8 *//*!*/; SET @@session.character_set_client=33,@@session.collation_connection=33,@@session.collation_server=33/*!*/; SET @@session.lc_time_names=0/*!*/; SET @@session.collation_database=DEFAULT/*!*/; create table t2 ( id int) /*!*/;
可以看見server-id為10，gtid-next為2a09ee6e-645d-11e7-a96c-000c2953a1cb:1，執行了建表。剩下的2-3是執行的數據插入，我這里沒寫出來。
這也體現了文章開始提到的：這個事務是誰產⽣，產⽣多少事務，⾮常直接的標識出來
那么對於文章開頭那個詭異的gtid是怎么出來的呢？先說說已經執行的事務：
Executed_Gtid_Set: 2a09ee6e-645d-11e7-a96c-000c2953a1cb:1-33,
8ce853fc-6f8a-11e7-8940-000c29e3f5ab:1
這里的2a09ee6e-645d-11e7-a96c-000c2953a1cb:1-33肯定很好理解，就是已經執行主庫的1-33的事務，那么8ce853fc-6f8a-11e7-8940-000c29e3f5ab:1呢？這個其實也簡單，有兩種情況：
第一種情況：從庫有數據寫入( 從庫插入數據 )
[root@localhost][db1]> insert into t2 select 1; Query OK, 1 row affected (0.03 sec) Records: 1 Duplicates: 0 Warnings: 0
show slave status
Replicate_Ignore_Server_Ids: Master_Server_Id: 10 Master_UUID: 2a09ee6e-645d-11e7-a96c-000c2953a1cb Master_Info_File: mysql.slave_master_info SQL_Delay: 0 SQL_Remaining_Delay: NULL Slave_SQL_Running_State: Slave has read all relay log; waiting for more updates Master_Retry_Count: 86400 Master_Bind: Last_IO_Error_Timestamp: Last_SQL_Error_Timestamp: Master_SSL_Crl: Master_SSL_Crlpath: Retrieved_Gtid_Set: 2a09ee6e-645d-11e7-a96c-000c2953a1cb:1-3 Executed_Gtid_Set: 2a09ee6e-645d-11e7-a96c-000c2953a1cb:1-3, 8ce853fc-6f8a-11e7-8940-000c29e3f5ab:1 Auto_Position: 1 Replicate_Rewrite_DB:
可以看見已經執行的事務有來自主庫的2a09ee6e-645d-11e7-a96c-000c2953a1cb:1-3，也有從庫剛自己寫入的數據：8ce853fc-6f8a-11e7-8940-000c29e3f5ab:1。我們可以解析binlog看看。
mysqlbinlog -vv mysql-bin.000001 --include-gtids='8ce853fc-6f8a-11e7-8940-000c29e3f5ab:1'
# at 896 #170823 0:59:19 server id 20 end_log_pos 961 CRC32 0x0492528a GTID last_committed=3 sequence_number=4 SET @@SESSION.GTID_NEXT= '8ce853fc-6f8a-11e7-8940-000c29e3f5ab:1'/*!*/; # at 961 #170823 0:59:19 server id 20 end_log_pos 1032 CRC32 0xbf545cca Query thread_id=25 exec_time=0 error_code=0 SET TIMESTAMP=1503421159/*!*/; SET @@session.pseudo_thread_id=25/*!*/; SET @@session.foreign_key_checks=1, @@session.sql_auto_is_null=0, @@session.unique_checks=1, @@session.autocommit=1/*!*/; SET @@session.sql_mode=1436549152/*!*/; SET @@session.auto_increment_increment=1, @@session.auto_increment_offset=1/*!*/; /*!\C utf8 *//*!*/; SET @@session.character_set_client=33,@@session.collation_connection=33,@@session.collation_server=33/*!*/; SET @@session.lc_time_names=0/*!*/; SET @@session.collation_database=DEFAULT/*!*/; BEGIN /*!*/; # at 1032 #170823 0:59:19 server id 20 end_log_pos 1079 CRC32 0x2f2de3ec Rows_query # insert into t2 select 1 # at 1079 #170823 0:59:19 server id 20 end_log_pos 1123 CRC32 0x18fe1c5c Table_map: `db1`.`t2` mapped to number 109 # at 1123 #170823 0:59:19 server id 20 end_log_pos 1163 CRC32 0x163a708e Write_rows: table id 109 flags: STMT_END_F BINLOG ' 52KcWR0UAAAALwAAADcEAACAABdpbnNlcnQgaW50byB0MiBzZWxlY3QgMezjLS8= 52KcWRMUAAAALAAAAGMEAAAAAG0AAAAAAAEAA2RiMQACdDIAAQMAAVwc/hg= 52KcWR4UAAAAKAAAAIsEAAAAAG0AAAAAAAEAAgAB//4BAAAAjnA6Fg== '/*!*/; ### INSERT INTO `db1`.`t2` ### SET ### @1=1 /* INT meta=0 nullable=1 is_null=0 */ # at 1163 #170823 0:59:19 server id 20 end_log_pos 1194 CRC32 0xe3347ac1 Xid = 68 COMMIT/*!*/; SET @@SESSION.GTID_NEXT= 'AUTOMATIC' /* added by mysqlbinlog */ /*!*/;
從binlog中可以清楚的看到是從庫進行了寫入。下面說第二組情況
第二種情況：主從切換（我這里使用MHA切換主從）
Master_Server_Id: 20 Master_UUID: 8ce853fc-6f8a-11e7-8940-000c29e3f5ab Master_Info_File: mysql.slave_master_info SQL_Delay: 0 SQL_Remaining_Delay: NULL Slave_SQL_Running_State: Slave has read all relay log; waiting for more updates Master_Retry_Count: 86400 Master_Bind: Last_IO_Error_Timestamp: Last_SQL_Error_Timestamp: Master_SSL_Crl: Master_SSL_Crlpath: Retrieved_Gtid_Set: 8ce853fc-6f8a-11e7-8940-000c29e3f5ab:1 Executed_Gtid_Set: 2a09ee6e-645d-11e7-a96c-000c2953a1cb:1-3, 8ce853fc-6f8a-11e7-8940-000c29e3f5ab:1 Auto_Position: 1
可以看到在切換以后主庫的server-id是20。這里的意思是接收到主庫8ce853fc-6f8a-11e7-8940-000c29e3f5ab:1，並且已經執行這個事務，那么這個事務其實就是之前在從庫寫入的那條數據。對於2a09ee6e-645d-11e7-a96c-000c2953a1cb:1-3這個是之前作為主庫執行。如果此時在主庫再插入1條數據，那么又會變化如下：
Retrieved_Gtid_Set: 8ce853fc-6f8a-11e7-8940-000c29e3f5ab:1-2 Executed_Gtid_Set: 2a09ee6e-645d-11e7-a96c-000c2953a1cb:1-3, 8ce853fc-6f8a-11e7-8940-000c29e3f5ab:1-2
下面說說文章開頭提到的gtid不連續的問題，類似2a09ee6e-645d-11e7-a96c-000c2953a1cb:37-45，這個是由於binlog被清理以后導致的，我們可以測試一下。然后查看gtid_purged變量。
binlog不可能永遠駐留在服務上，需要定期進行清理(通過expire_logs_days可以控制定期清理間隔)，否則遲早它會把磁盤用盡。gtid_purged用於記錄已經被清除了的binlog事務集合，它是gtid_executed的子集。只有gtid_executed為空時才能手動設置該變量，此時會同時更新gtid_executed為和gtid_purged相同的值。gtid_executed為空意味着要么之前沒有啟動過基於GTID的復制，要么執行過RESET MASTER。執行RESET MASTER時同樣也會把gtid_purged置空，即始終保持gtid_purged是gtid_executed的子集。
從庫：
[root@localhost][db1]> show master logs; +------------------+-----------+ | Log_name | File_size | +------------------+-----------+ | mysql-bin.000001 | 3530 | +------------------+-----------+ 1 row in set (0.00 sec) [root@localhost][db1]> flush logs; Query OK, 0 rows affected (0.05 sec) [root@localhost][db1]> show master logs; +------------------+-----------+ | Log_name | File_size | +------------------+-----------+ | mysql-bin.000001 | 3577 | | mysql-bin.000002 | 234 | +------------------+-----------+ 2 rows in set (0.00 sec) [root@localhost][db1]> PURGE BINARY LOGS TO 'mysql-bin.000002'; Query OK, 0 rows affected (0.01 sec) [root@localhost][db1]> show master logs; +------------------+-----------+ | Log_name | File_size | +------------------+-----------+ | mysql-bin.000002 | 234 | +------------------+-----------+ 1 row in set (0.00 sec)
然后只要從庫有重新啟動，才會讀取。MySQL服務器啟動時，通過讀binlog文件，初始化gtid_executed和gtid_purged,使它們的值能和上次MySQL運行時一致。
gtid_executed被設置為最新的binlog文件中Previous_gtids_log_event和所有Gtid_log_event的並集。
gtid_purged為最老的binlog文件中Previous_gtids_log_event。
沒啟動前：
Retrieved_Gtid_Set: 8ce853fc-6f8a-11e7-8940-000c29e3f5ab:1-9 Executed_Gtid_Set: 2a09ee6e-645d-11e7-a96c-000c2953a1cb:1-3, 8ce853fc-6f8a-11e7-8940-000c29e3f5ab:1-9
重啟以后並且插入數據：
Master_Server_Id: 20 Master_UUID: 8ce853fc-6f8a-11e7-8940-000c29e3f5ab Master_Info_File: mysql.slave_master_info SQL_Delay: 0 SQL_Remaining_Delay: NULL Slave_SQL_Running_State: Slave has read all relay log; waiting for more updates Master_Retry_Count: 86400 Master_Bind: Last_IO_Error_Timestamp: Last_SQL_Error_Timestamp: Master_SSL_Crl: Master_SSL_Crlpath: Retrieved_Gtid_Set: 8ce853fc-6f8a-11e7-8940-000c29e3f5ab:10 Executed_Gtid_Set: 2a09ee6e-645d-11e7-a96c-000c2953a1cb:1-3, 8ce853fc-6f8a-11e7-8940-000c29e3f5ab:1-10 Auto_Position: 1
[root@localhost][(none)]> show variables like 'gtid_purged'; +---------------+------------------------------------------------------------------------------------+ | Variable_name | Value | +---------------+------------------------------------------------------------------------------------+ | gtid_purged | 2a09ee6e-645d-11e7-a96c-000c2953a1cb:1-3, 8ce853fc-6f8a-11e7-8940-000c29e3f5ab:1-9 | +---------------+------------------------------------------------------------------------------------+ 1 row in set (0.01 sec)
到這里相信聰明的你一定看懂了。最后順道說說gtid跳過復制錯誤的方法，對於跳過一個錯誤，找到無法執行事務的編號，比如是2a09ee6e-645d-11e7-a96c-000c2953a1cb:1-10，那么操作如下：
stop slave; set gtid_next='2a09ee6e-645d-11e7-a96c-000c2953a1cb:1-10'; begin; commit; set gtid_next='AUTOMATIC'; start slave;
上面方法只能跳過一個事務，那么對於一批如何跳過？在主庫執行show master status，看主庫執行到了哪里，比如：2a09ee6e-645d-11e7-a96c-000c2953a1cb:1-33，那么操作如下：
stop slave; reset master; set global gtid_purged='2a09ee6e-645d-11e7-a96c-000c2953a1cb:1-33'; start slave;