mysql5.6GTID手动跳过复制错误

当备库复制出错时,传统的跳过错误的方法是设置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文件的最大值,以缩小扫描文件的时间。
四、存在的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中

你可能感兴趣的:(mysql-基础)