創建GTID主從連接：
mysql> change master to master_host='master_id', master_port=3306, master_user='user', master_password='password', master_auto_position=1;
報錯顯示：
Slave_IO_Running: Yes Slave_SQL_Running: No Last_Error: Error 'Can't drop database 'test'; database doesn't exist' on query. Default database: 'test'. Query: 'drop database test'
Retrieved_Gtid_Set: 988b8684-3e21-22e6-a801-24505689c77d:1-9
Executed_Gtid_Set:
兩個新實例啟動后我預先做了一些安全處理，然后就直接在從庫執行change master，導致主庫上的日志在從庫里執行不了，需要把無法執行的日志都跳過！
機械的搬運老師上課講的內容如下：
mysql> stop slave; Query OK, 0 rows affected (0.00 sec) mysql> set gtid_next="988b8684-3e21-22e6-a801-24505689c77d:9"; Query OK, 0 rows affected (0.00 sec) mysql> begin;commit; Query OK, 0 rows affected (0.00 sec) Query OK, 0 rows affected (0.01 sec) mysql> set gtid_next="AUTOMATIC"; Query OK, 0 rows affected (0.00 sec) mysql> start slave; Query OK, 0 rows affected (0.00 sec)
結果
mysql> show slave status\G *************************** 1. row *************************** Slave_IO_Running: Yes Slave_SQL_Running: No Last_Error: Error 'Can't drop database 'test'; database doesn't exist' on query. Default database: 'test'. Query: 'drop database test'
Retrieved_Gtid_Set: 988b8684-3e21-22e6-a801-24505689c77d:1-9
Executed_Gtid_Set: 988b8684-3e21-22e6-a801-24505689c77d:9
沒起作用！這是什么問題？
再去查看主庫上的binlog日志，查找drop database test相關的日志：
# at 151 #160630 1:55:19 server id 623306 end_log_pos 199 CRC32 0x5954bb4c GTID [commit=yes] SET @@SESSION.GTID_NEXT= '988b8684-3e21-22e6-a801-24505689c77d:1'/*!*/; # at 199 #160630 1:55:19 server id 623306 end_log_pos 284 CRC32 0x6db10369 Query thread_id=1 exec_time=0 error_code=0 SET TIMESTAMP=1467222919/*!*/; SET @@session.pseudo_thread_id=1/*!*/; SET @@session.foreign_key_checks=1, @@session.sql_auto_is_null=0, @@session.unique_checks=1, @@session.autocommit=1/*!*/; SET @@session.sql_mode=1073741824/*!*/; SET @@session.auto_increment_increment=1, @@session.auto_increment_offset=1/*!*/; /*!\C utf8 *//*!*/; SET @@session.character_set_client=83,@@session.collation_connection=83,@@session.collation_server=83/*!*/; SET @@session.lc_time_names=0/*!*/; SET @@session.collation_database=DEFAULT/*!*/; drop database test /*!*/;
問題找到了，drop database test對應的事務號是1，而不是順序顯示的9，接下來就簡單了，重復上面的操作，但把事務號9改成1：
mysql> stop slave; Query OK, 0 rows affected (0.00 sec) mysql> set gtid_next="988b8684-3e21-22e6-a801-24505689c77d:1"; Query OK, 0 rows affected (0.00 sec) mysql> begin;commit; Query OK, 0 rows affected (0.00 sec) Query OK, 0 rows affected (0.01 sec) mysql> set gtid_next="AUTOMATIC"; Query OK, 0 rows affected (0.00 sec) mysql> start slave; Query OK, 0 rows affected (0.00 sec)
再有相似的報錯也同樣處理，最后終於沒問題了：
mysql> show slave status\G Slave_IO_Running: Yes Slave_SQL_Running: Yes Retrieved_Gtid_Set: 988b8684-3e21-22e6-a801-24505689c77d:1-9 Executed_Gtid_Set: 988b8684-3e21-22e6-a801-24505689c77d:1-9
over
收獲：知其然很重要，知其所以然更重要
要理解GTID代表的是什么，每個事務的提交都代表着一個GTID的生成，正如其全名：全局事務ID(global transaction identifier)，所以如果想跳過導致錯誤的事務不執行的話，需要找到對應事務的gtid號，設置(set gtid_next="....")並提交空事務后重新啟用自動模式后，再重啟slave就可以，並不是每個導致錯誤的事務都是binlog中最后一個事務
另外，還要理解相關的參數：
Retrieved_Gtid_Set The set of global transaction IDs corresponding to all transactions received by this slave. Empty if GTIDs are not in use. This is the set of all GTIDs that exist or have existed in the relay logs
即IO線程接收到的日志
Executed_Gtid_Set The set of global transaction IDs written in the binary log. This is the same as the value for the global gtid_executed system variable on this server, as well as the value for Executed_Gtid_Set in the output of SHOW MASTER STATUS on this server. Empty if GTIDs are not in use.
即SQL線程執行到的位置
理解了這個后就能明白，之前的處理還是太復雜，其實直接看show slave satus\G的結果，看這兩個參數的值：
Slave_IO_Running: Yes Slave_SQL_Running: No Last_Error: Error 'Can't drop database 'test'; database doesn't exist' on query. Default database: 'test'. Query: 'drop database test' Retrieved_Gtid_Set: 988b8684-3e21-22e6-a801-24505689c77d:1-9 Executed_Gtid_Set:
能夠看到，Executed_Gtid_Set是空的，而且GTID是肯定開啟了的，所以，說明日志傳過來后壓根還沒開始執行，所以，第一個事務就已經被卡住了，首先應該跳過的事務號就是1，也不必再去看日志了
查資料過程中看到一個很好的GTID介紹文章，鏈接在此：http://mysqllover.com/?p=594