跨库操作导致mysql主从复制中断

收到故障告警，mysql从库复制中断，show slave status\G 看到：

Last_Error: Error 'Table 'test.null_file_md5_d' doesn't exist' on query. Default database: 'xx'. Query: 'update tbl_FileInfo as a inner join test.null_file_md5_d as b on a.filemd5=b.filemd5 set a.filemd5='0''

Query语句显示，这是一次跨库操作引发的：update xx库引用了test库的表。

生产环境的主从只复制xx库，/etc/my.cnf配置为：binlog-do-db=xx

和开发同学确认了下，果然是只在master的test库建表和灌数据，忘了在slave执行。

恢复主从步骤：

1、stop slave

2、set global sql_slave_skip_counter=1

注意：

使用sql_slave_skip_counter跳过，每一次跳过为一个Binlog event group, 也就相当于一个事务。所以当一个事务中有两个SQL， 第一个SQL导致主从复制中断，然后我们直接使用SQL_SLAVE_SKIP_COUNTER=1跳过错了。其实第二个SQL也不会在slave中执行了，如果第二个SQL影响100行，那么主从就有100行数据不一致了。所以，我们在跳过之前，一定要看一下，当前binlog event group到底是什么？

根据slave status中的Relay_Log_File和Relay_Log_Pos两个值 ，先查看当前被中断的binlog event group操作是什么？

命令：show relaylog events in "Relay_Log_File" from Relay_Log_Pos limit n;

3、start slave

4、show slave status\G

所以，在使用binlog-do-db, binlog-ignore-db, replicate-do-db, replicate-ignore-db 等参数的主从环境下，跨库操作要谨慎。

扩展阅读：

《Why MySQL’s binlog-do-db option is dangerous》http://www.mysqlperformanceblog.com/2009/05/14/why-mysqls-binlog-do-db-option-is-dangerous/

翻译：http://www.eit.name/blog/read.php?433

《slave复制中断 ,别滥用SQL_SLAVE_SKIP_COUNTER》http://blog.chinaunix.net/uid-26364035-id-3588217.html