**問題描述** 當單個 MySQL 實例的數據增長到很多的時候，就會考慮通過庫或者表級別的拆分，把當前實例的數據分散到多個實例上去，假設原實例為A，想把其中的5個庫（db1/db2/db3/db4/db5）拆分到5個實例（B1/B2/B3/B4/B5）上去。 拆分過程一般會這樣做，先把A的相應庫的數據導出，然后導入到對應的B實例上，但是在這個導出導入過程中，A庫的數據還是在持續更新的，所以還需在導入完后，在所有的B實例和A實例間建立復制關系，拉取缺失的數據，在業務不繁忙的時候將業務切換到各個B實例。 在復制搭建時，每個B實例只需要復制A實例上的一個庫，所以只需要重放對應庫的binlog即可，這個通過 replicate-do-db 來設置過濾條件。如果我們用備庫上執行 show slave status\G 會看到Executed_Gtid_Set是斷斷續續的，間斷非常多，導致這一列很長很長，看到的直接效果就是被刷屏了。 為啥會這樣呢，因為設了replicate-do-db，就只會執行對應db對應的event，其它db的都不執行。主庫的執行是不分db的，對各個db的操作互相間隔，記錄在binlog中，所以備庫做了過濾后，就出現這種斷斷的現象。 除了這個看著不舒服外，還會導致其它問題么？ 假設我們拿B1實例的備份做了一個新實例，然后接到A上，如果主庫A又定期purge了老的binlog，那么新實例的IO線程就會出錯，因為需要的binlog在主庫上找不到了；即使主庫沒有purge 老的binlog，新實例還要把主庫的binlog都從頭重新拉過來，然后執行的時候又都過濾掉，不如不拉取。 有沒有好的辦法解決這個問題呢？SQL線程在執行的時候，發現是該被過濾掉的event，在不執行的同時，記一個空事務就好了，把原事務對應的GTID位置占住，記入binlog，這樣備庫的Executed_Gtid_Set就是連續的了。 **bug 修復** 對這個問題，官方有一個相應的bugfix，參見 revno:?[5860](http://bazaar.launchpad.net/~mysql/mysql-server/5.6/revision/5860)?，有了這個patch后，備庫B1的 SQL 線程在遇到和 db2-db5 相關的SQL語句時，在binlog中把對應的GTID記下，同時對應記一個空事務。 這個 patch 只是針對Query_log_event，即 statement 格式的 binlog event，那么row格式的呢？ row格式原來就已經是這種行為，通過check_table_map 函數來過濾庫或者表，然后生成一個空事務。 另外這個patch還專門處理了下 CREATE/DROP TEMPORARY TABLE 這2種語句，我們知道row格式下，對臨時表的操作是不會記入binlog的。如果主庫的binlog格式是 statement，備庫用的是 row，CREATE/DROP TEMPORARY TABLE 對應的事務傳到備庫后，就會消失掉，Executed_Gtid_Set集合看起來是不連續的，但是主庫的binlog記的gtid是連續的，這個 patch 讓這種情況下的CREATE/DROP TEMPORARY TABLE在備庫同樣記為一個空事務。