生产环境有一个MySQL的Master-Slave的复制。
前一阵子机房网络升级,但是考虑到一般网络故障恢复之后,只需要start slave即可
所以没有做任何的处理。
但是第二天上班的时候,在Slave数据库上输入命令,start slave 不能重新启动复制。
模拟环境如下
![](//img.blog.itpub.net/blog/attachment/201406/12/29254281_14025868671qR1.png?x-oss-process=style/bb)
在Slave上启动复制,报错如下
![](//img.blog.itpub.net/blog/attachment/201406/12/29254281_1402586886L12o.png?x-oss-process=style/bb)
复制过程出现主键重复了
![](//img.blog.itpub.net/blog/attachment/201406/12/29254281_1402586897L1RM.png?x-oss-process=style/bb)
最后,使用status查看,发现MySQL被重启过。
估计在割接过程中,莫名其妙的被人按了服务器的重启键吧。
但是MySQL复制针对这种情况,异常的脆弱,因为复制的信息都写在一个文件里,
考虑到性能的原因,这个写入并不是同步的。
也就是说在断电重启的瞬间,复制的情况并没有写入到文件中。
而再次启动之后,读取这个文件中记录的复制位置,肯定落后于实际执行的位置。
所以会发生主键重复的问题,因为这个记录实际已经执行过了。
解决这个问题有三种方式
1.设置sql_slave_skip_counter跳过Master发来的事件,直到正常的位置
![](//img.blog.itpub.net/blog/attachment/201406/12/29254281_1402587494jlLK.png?x-oss-process=style/bb)
启动之后,发现报错信息已经变了
![](//img.blog.itpub.net/blog/attachment/201406/12/29254281_1402587519ZQ90.png?x-oss-process=style/bb)
他重复的主键已经从7940到了7946了,也就说通过一点一点的推进,是可以推进到正常的复制位置的。
但是工作量比较大,需要很有耐心和时间做这个事情。
2.设置slave_skip_errors
在my.cnf配置文件中设置slave_skip_errors=1062,跳过所有主键重复的错误。
但是这个参数设置之后,需要重启服务。对于生产系统来说,没有实际意义。
3.设置slave_exec_mode
MySQL默认的slave执行方式是严格的。
类似主键重复的问题,会直接停止复制,等待人工介入。
slave_exec_mode是一个动态参数,如果设置为IDEMPOTENT可以自动忽略主键重复和没有找到记录的错误。
但是貌似只是在MySQL集群环境有效
http://dev.mysql.com/doc/refman/5.6/en/replication-options-slave.html#sysvar_slave_exec_mode
异常断电和关机除了可能导致主键重复的错误之外,还可能导致中继日志损坏
针对这个问题,首先,找到master binlog执行的位置
![](//img.blog.itpub.net/blog/attachment/201406/13/29254281_1402589939TZ18.png?x-oss-process=style/bb)
位置
![](//img.blog.itpub.net/blog/attachment/201406/13/29254281_1402589953WnuP.png?x-oss-process=style/bb)
然后重新连接Master服务器,(需要先停止slave)
![](//img.blog.itpub.net/blog/attachment/201406/13/29254281_140259012780Fl.png?x-oss-process=style/bb)
最后查看复制情况,已经正常。
这次的经验是,如果预计可能发生状况,比如这次网络割接,
可以先停止slave的服务器。因为我们的slave只是作为备份的一种方式,而不是用于读写分离。
或者干脆设置slave_skip_errors参数。
前一阵子机房网络升级,但是考虑到一般网络故障恢复之后,只需要start slave即可
所以没有做任何的处理。
但是第二天上班的时候,在Slave数据库上输入命令,start slave 不能重新启动复制。
模拟环境如下
![](http://img.blog.itpub.net/blog/attachment/201406/12/29254281_14025868671qR1.png?x-oss-process=style/bb)
在Slave上启动复制,报错如下
![](http://img.blog.itpub.net/blog/attachment/201406/12/29254281_1402586886L12o.png?x-oss-process=style/bb)
复制过程出现主键重复了
![](http://img.blog.itpub.net/blog/attachment/201406/12/29254281_1402586897L1RM.png?x-oss-process=style/bb)
最后,使用status查看,发现MySQL被重启过。
估计在割接过程中,莫名其妙的被人按了服务器的重启键吧。
但是MySQL复制针对这种情况,异常的脆弱,因为复制的信息都写在一个文件里,
考虑到性能的原因,这个写入并不是同步的。
也就是说在断电重启的瞬间,复制的情况并没有写入到文件中。
而再次启动之后,读取这个文件中记录的复制位置,肯定落后于实际执行的位置。
所以会发生主键重复的问题,因为这个记录实际已经执行过了。
解决这个问题有三种方式
1.设置sql_slave_skip_counter跳过Master发来的事件,直到正常的位置
![](http://img.blog.itpub.net/blog/attachment/201406/12/29254281_1402587494jlLK.png?x-oss-process=style/bb)
启动之后,发现报错信息已经变了
![](http://img.blog.itpub.net/blog/attachment/201406/12/29254281_1402587519ZQ90.png?x-oss-process=style/bb)
他重复的主键已经从7940到了7946了,也就说通过一点一点的推进,是可以推进到正常的复制位置的。
但是工作量比较大,需要很有耐心和时间做这个事情。
2.设置slave_skip_errors
在my.cnf配置文件中设置slave_skip_errors=1062,跳过所有主键重复的错误。
但是这个参数设置之后,需要重启服务。对于生产系统来说,没有实际意义。
3.设置slave_exec_mode
MySQL默认的slave执行方式是严格的。
类似主键重复的问题,会直接停止复制,等待人工介入。
slave_exec_mode是一个动态参数,如果设置为IDEMPOTENT可以自动忽略主键重复和没有找到记录的错误。
但是貌似只是在MySQL集群环境有效
http://dev.mysql.com/doc/refman/5.6/en/replication-options-slave.html#sysvar_slave_exec_mode
异常断电和关机除了可能导致主键重复的错误之外,还可能导致中继日志损坏
![](http://img.blog.itpub.net/blog/attachment/201406/13/29254281_1402589731eD0t.png?x-oss-process=style/bb)
针对这个问题,首先,找到master binlog执行的位置
![](http://img.blog.itpub.net/blog/attachment/201406/13/29254281_1402589939TZ18.png?x-oss-process=style/bb)
位置
![](http://img.blog.itpub.net/blog/attachment/201406/13/29254281_1402589953WnuP.png?x-oss-process=style/bb)
然后重新连接Master服务器,(需要先停止slave)
![](http://img.blog.itpub.net/blog/attachment/201406/13/29254281_140259012780Fl.png?x-oss-process=style/bb)
最后查看复制情况,已经正常。
这次的经验是,如果预计可能发生状况,比如这次网络割接,
可以先停止slave的服务器。因为我们的slave只是作为备份的一种方式,而不是用于读写分离。
或者干脆设置slave_skip_errors参数。
来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/29254281/viewspace-1181865/,如需转载,请注明出处,否则将追究法律责任。
转载于:http://blog.itpub.net/29254281/viewspace-1181865/