在前面文章我提到了兩種關於如何修復 Mysql 5.6 GTID 主從數據庫。
我沒有提到大家說熟知的方法 - ` GLOBAL SQL_SLAVE_SKIP_COUNTER = n`。原因很簡單，如果你使用的是MysqlGTID，它是不工作的。
那麼問題來了：
有沒有簡單的方法跳過這單一事務 ?
是的！注入空事務。讓我們想象一下，從服務器上的複製不工作，因爲下面一個錯誤：
Last_SQL_Error: Error 'Duplicate entry '4' for key 'PRIMARY'' on query. Default database: 'test'. Query: 'insert into t VALUES(NULL,'salazar')' Retrieved_Gtid_Set: 7d72f9b4-8577-11e2-a3d7-080027635ef5:1-5 Executed_Gtid_Set: 7d72f9b4-8577-11e2-a3d7-080027635ef5:1-4
這裏有不同的方法可以找到失敗的事務。你可以檢查二進制日誌，或者你也可以檢查retrieved_gtid_set 和 executed_gtid_set 從顯示輸出的例子中我們可以看出。此從服務器檢索到1到5的交易，但只執行了1到4。這意味着交易5是導致問題的一個問題。
因爲在GTID中sql_slave_skip_counter不工作，我們需要找到一種辦法來忽視事務。我們可以在GTID中創建空事務以跳過它。
STOP SLAVE; SET GTID_NEXT="7d72f9b4-8577-11e2-a3d7-080027635ef5:5"; BEGIN; COMMIT; SET GTID_NEXT="AUTOMATIC"; START SLAVE; [...] Retrieved_Gtid_Set: 7d72f9b4-8577-11e2-a3d7-080027635ef5:1-5 Executed_Gtid_Set: 7d72f9b4-8577-11e2-a3d7-080027635ef5:1-5
START SLAVE 之後 檢查事務5已經在它自己的二進制文件中了，這就意味着它已經執行過了。
這是一個簡單的方法來跳過一些事務，但是，你應該想到主從服務器之間數據不一致。pt-table-checksum 在這裏可以幫助你，它可以在Percona Toolkit for mysql 中找到。
上週我談及了很多關於GTID的東西在多倫多 Percona Mysql 大學。 它包括MySQL 5.6 gtid 這個新功能的工作概述，可以幫助人們。這是來自該會議的幻燈片。我希望你覺得它有用：MySQL 5.6 GTID in a nutshell
原文： https://www.percona.com/blog/2013/03/26/repair-mysql-5-6-gtid-replication-by-injecting-empty-transactions/