收到故障告警,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