1、主库意外关闭
如果主库没有设置sync_binlog选项，就可能在崩溃前没有将最后的几个二进制日志事件刷新到磁盘中。备库I/O线程因此也可一直处于读不到尚未写入磁盘的事件的状态中。当主库重新启动，备库将重连到主库并再次尝试去读该事件，但主库会告诉备库没有这个二进制日志偏移量。二进制日志转储线程通常很快，因此这种情况并不经常发生。
解决办法：
指定备库从下一个二进制日志的开头读日志。但是一些日志事件将永久的丢失(使用pt-table-checksum检测复制一致性，便于修复)。可以通过在主库开启sync_binlog来避免事件丢失。
2、备库意外关闭
当备库在一次非计划中的关闭后重启时，会去读master.info文件以找到上次停止复制的位置。不幸的是，该违建并没有同步写到磁盘，文件中存储的信息可能是错误的。备库可能会尝试重启执行一些二进制日志事件，这可能会导致唯一索引错误。除非能确定备库在哪里停止(通常不可能)，唯一办法是忽略那些错误。(pt-slave-restart可以帮助完成)。
3、主库二进制日志损坏
如果主库二进制日志损坏，除了忽略损坏的位置外你别无选择。可以在主库上执行flush logs来开启一个新的日志文件，然后将备库指向该文件开始的位置。也可以试着去发现损坏区域的结束位置。某些情况下可以通过set global_slave_skip_counter=1来忽略一个错误的事件，如果有多个的话，就需要重复上述操作直到跳出错误事件循环。
4、备库中继日志损坏
如果主库的二进制日志完好，可以通过change master to命令丢弃并重新获取损坏的事件。只需要将备库指向它当前正在复制的位置(file/position)。这会导致备库丢弃所有在磁盘上的中继日志。就这一点而言。mysql5.5做了改进，它能够在崩溃后自动重新获取中继日志
阅读(1791) | 评论(0) | 转发(0) |
