>  기사  >  데이터 베이스  >  从库宕机引发的主键冲突

从库宕机引发的主键冲突

WBOY
WBOY원래의
2016-06-07 17:37:511231검색

刚刚接到报警短信,从库宕机,马上通知机房重启,在检查MySQL时,发现同步挂了,报主键冲突,询问开发是不是有往里面写数据,回答没有。这就奇怪了,怎么会无缘

刚刚接到报警短信,从库宕机,马上通知机房重启,在检查MySQL时,发现同步挂了,报主键冲突,询问开发是不是有往里面写数据,回答没有。


这就奇怪了,怎么会无缘无故报错呢?在检查了my.cnf配置文件,发现有个参数没有配置:

innodb_overwrite_relay_log_info = 1


当从库宕机后,重新开启主从复制同步,它可以重新执行已提交事务,这样就会造成同步失败,而这个参数就会避免这个问题的出现。


当开启了这个参数后

.... + InnoDB: Warning: innodb_overwrite_relay_log_info is enabled. Updates of other storage engines may have problem of consistency. + InnoDB: relay-log.info is detected. + InnoDB: relay log: position 429, file name ./gauntlet3-relay-bin.000111 + InnoDB: master log: position 280, file name gauntlet3-bin.000015 .... InnoDB: Starting crash recovery. .... InnoDB: Apply batch completed + InnoDB: In a MySQL replication slave the last master binlog file + InnoDB: position 0 468, file name gauntlet3-bin.000015 + InnoDB: and relay log file + InnoDB: position 0 617, file name ./gauntlet3-relay-bin.000111 090205 17:41:31 InnoDB Plugin 1.0.2-3 started; log sequence number 57933 + InnoDB: relay-log.info have been overwritten. .... 090205 17:41:31 [Note] Slave SQL thread initialized, starting replication in log ``gauntlet3-bin.000015`` at position 468, relay log ``./gauntlet3-relay-bin.000111`` position: 617


已经执行完的Position点:

master log: position 280, file name gauntlet3-bin.000015

在恢复时它内部会检测到280这个点已经执行完毕,从下一个点468开始同步,并且重写relay.info文件,,确保了主从同步正确。


建议在从库上添加,如果是官方MySQL,参数是relay_log_recovery=1


具体请参考:



本文出自 “贺春旸的技术专栏” 博客,请务必保留此出处

성명:
본 글의 내용은 네티즌들의 자발적인 기여로 작성되었으며, 저작권은 원저작자에게 있습니다. 본 사이트는 이에 상응하는 법적 책임을 지지 않습니다. 표절이나 침해가 의심되는 콘텐츠를 발견한 경우 admin@php.cn으로 문의하세요.