MySQL Slave异常关机的处理

生产环境有一个MySQL的Master-Slave的复制。前一阵子机房网络升级,但是考虑到一般网络故障恢复之后,只需要start slave即可所以没有做任何的处理。但是第二天上班的时候，在Slave数据库上输入命令，start slave 不能重新启动复制。模拟环境如下在Slave上启动复制，报错如下复制过程出现主键重复了最后，使用status查看，发现MySQL被重启过。估计在割接过程中，莫名其妙的被人按了服务器的重启键吧。但是MySQL复制针对这种情况，异常的脆弱，因为复制的信息都写在一个文件里，考虑到性能的原因，这个写入并不是同步的。也就是说在断电重启的瞬间，复制的情况并没有写入到文件中。而再次启动之后，读取这个文件中记录的复制位置，肯定落后于实际执行的位置。所以会发生主键重复的问题，因为这个记录实际已经执行过了。解决这个问题有三种方式1.设置sql_slave_skip_counter跳过Master发来的事件,直到正常的位置启动之后，发现报错信息已经变了他重复的主键已经从7940到了7946了，也就说通过一点一点的推进，是可以推进到正常的复制位置的。但是工作量比较大，需要很有耐心和时间做这个事情。2.设置slave_skip_errors在my.cnf配置文件中设置slave_skip_errors=1062，跳过所有主键重复的错误。但是这个参数设置之后，需要重启服务。对于生产系统来说，没有实际意义。3.设置slave_exec_modeMySQL默认的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执行的位置位置然后重新连接Master服务器,（需要先停止slave）最后查看复制情况，已经正常。这次的经验是，如果预计可能发生状况，比如这次网络割接，可以先停止slave的服务器。因为我们的slave只是作为备份的一种方式，而不是用于读写分离。或者干脆设置slave_skip_errors参数。 --------------------------------------分割线 --------------------------------------Ubuntu 14.04下安装MySQL http://www.linuxidc.com/Linux/2014-05/102366.htm《MySQL权威指南（原书第2版）》清晰中文扫描版 PDF http://www.linuxidc.com/Linux/2014-03/98821.htmUbuntu 14.04 LTS 安装 LNMP NginxPHP5 （PHP-FPM）MySQL http://www.linuxidc.com/Linux/2014-05/102351.htmUbuntu 14.04下搭建MySQL主从服务器 http://www.linuxidc.com/Linux/2014-05/101599.htmUbuntu 12.04 LTS 构建高可用分布式 MySQL 集群 http://www.linuxidc.com/Linux/2013-11/93019.htmUbuntu 12.04下源代码安装MySQL5.6以及Python-MySQLdb http://www.linuxidc.com/Linux/2013-08/89270.htm--------------------------------------分割线 --------------------------------------本文永久更新链接地址