GTID複製模式手動跳過複製錯誤

   當備庫複製出錯時，傳統的跳過錯誤的方法是設置sql_slave_skip_counter,而後再START SLAVE。

但若是打開了GTID，就會設置失敗：

mysql> set global sql_slave_skip_counter = 1;

ERROR 1858 (HY000): sql_slave_skip_counter can not be set when the server is running with @@GLOBAL.GTID_MODE = ON. Instead, for each transaction that you want to skip, generate an empty transaction with the same GTID as the transaction

 

提示的錯誤信息告訴咱們，能夠經過生成一個空事務來跳過錯誤的事務。

咱們手動產生一個備庫複製錯誤：

Last_SQL_Error: Error ‘Unknown table ‘test.t1」 on query. Default database: ‘test’. Query: ‘DROP TABLE `t1` /* generated by server */’

查看binlog中，該DDL對應的GTID爲7a07cd08-ac1b-11e2-9fcf-0010184e9e08:1131

在備庫上執行：

mysql> STOP SLAVE;

Query OK, 0 rows affected (0.00 sec)

mysql> SET SESSION GTID_NEXT = ’7a07cd08-ac1b-11e2-9fcf-0010184e9e08:1131′;

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.00 sec)

 

mysql> SET SESSION GTID_NEXT = AUTOMATIC;

Query OK, 0 rows affected (0.00 sec)

 

mysql> START SLAVE;

再查看show slave status，就會發現錯誤事務已經被跳過了。這種方法的原理很簡單，空事務產生的GTID加入到GTID_EXECUTED中，這至關於告訴備庫，這個GTID對應的事務已經執行了。

b.重指主庫

使用change master to …. , MASTER_AUTO_POSITION=1；

注意在整個複製拓撲中，都須要打開gtid_mode

c.新的until條件

5.6提供了新的util condition，能夠根據GTID來決定備庫複製執行到的位置

SQL_BEFORE_GTIDS：在指定的GTID以前中止複製

SQL_AFTER_GTIDS ：在指定的GTID以後中止複製

判斷函數爲Relay_log_info::is_until_satisfied

詳細文檔見： http://dev.mysql.com/doc/refman/5.6/en/start-slave.html  

d.適當減少binlog文件的大小

若是開啓GTID，理論上最好調小每一個binlog文件的最大值，以縮小掃描文件的時間。

4、存在的bug

bug#69097 ， 即便關閉了gtid_mode，也會在啓動時去掃描binlog文件。

當在重啓前沒有使用gtid_mode，重啓後可能會去掃描全部的binlog文件，若是Binlog文件不少的話，這顯然是不可接受的。

bug#69096 ，沒法經過GTID_NEXT_LIST來跳過複製錯誤，由於默認編譯下，GTID_NEXT_LIST未被編譯進去。

TODO:GTID_NEXT_LIST的邏輯上面均未提到，有空再看。

bug#69095 ，將備庫的複製模式設置爲STATEMENT/MIXED。 主庫設置爲ROW模式，執行DML 會致使備庫複製中斷

Last_SQL_Error: Error executing row event: ‘Cannot execute statement: impossible to write to binary log since statement is in row format and BINLOG_FORMAT = STATEMENT.’

判斷報錯的backtrace：

handle_slave_worker->slave_worker_exec_job->Rows_log_event::do_apply_event->open_and_lock_tables->open_and_lock_tables->lock_tables->THD::decide_logging_format

 

解決辦法：將備庫的複製模式設置爲’ROW’ ，保持主備一致

 

該bug和GTID無關

bug#69045 , 當主庫執行相似 FLUSH PRIVILEGES這樣的動做時，若是主庫和備庫都開啓了gtid_mode，會致使複製中斷

Last_SQL_Error: Error ‘Cannot execute statements with implicit commit inside a transaction when @@SESSION.GTID_NEXT != AUTOMATIC or @@SESSION.GTID_NEXT_LIST != NULL.’ on query. Default database: 」. Query: ‘flush privileges’

也是一個很低級的bug，在MySQL5.6.11版本中，若是有可能致使隱式提交的事務， 則gtid_next必須等於AUTOMATIC，對備庫複製線程而言，很容易就中斷了，判斷邏輯在函數gtid_pre_statement_checks中