从库宕机引发的主键冲突

本文涉及的产品
云数据库 RDS MySQL Serverless,0.5-2RCU 50GB
云数据库 RDS MySQL Serverless,价值2615元额度,1个月
简介:

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


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

1
innodb_overwrite_relay_log_info = 1


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


当开启了这个参数后

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
....
+ 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


具体请参考:http://www.percona.com/doc/percona-server/5.5/reliability/crash_resistant_replication.html















本文转自hcymysql51CTO博客,原文链接: http://blog.51cto.com/hcymysql/1332012,如需转载请自行联系原作者


相关实践学习
基于CentOS快速搭建LAMP环境
本教程介绍如何搭建LAMP环境,其中LAMP分别代表Linux、Apache、MySQL和PHP。
全面了解阿里云能为你做什么
阿里云在全球各地部署高效节能的绿色数据中心,利用清洁计算为万物互联的新世界提供源源不断的能源动力,目前开服的区域包括中国(华北、华东、华南、香港)、新加坡、美国(美东、美西)、欧洲、中东、澳大利亚、日本。目前阿里云的产品涵盖弹性计算、数据库、存储与CDN、分析与搜索、云通信、网络、管理与监控、应用服务、互联网中间件、移动服务、视频服务等。通过本课程,来了解阿里云能够为你的业务带来哪些帮助     相关的阿里云产品:云服务器ECS 云服务器 ECS(Elastic Compute Service)是一种弹性可伸缩的计算服务,助您降低 IT 成本,提升运维效率,使您更专注于核心业务创新。产品详情: https://www.aliyun.com/product/ecs
相关文章
|
9月前
|
SQL 网络协议 关系型数据库
mysql主库更新后,从库都读到最新值了,主库还有可能读到旧值吗?
mysql主库更新后,从库都读到最新值了,主库还有可能读到旧值吗?
77 0
|
7月前
|
存储 消息中间件 缓存
场景应用:如何保证缓存与数据库的双写一致性?
场景应用:如何保证缓存与数据库的双写一致性?
|
10月前
|
消息中间件 存储 缓存
如何保证缓存与数据库双写时的数据一致性?
如何保证缓存与数据库双写时的数据一致性?
|
12月前
举例:在从库上备份,到主库上恢复
在备库上备份,在主库上恢复 control file和recovery catalog的同步
|
12月前
|
监控 关系型数据库 MySQL
如何避免主从不同步
如何避免主从不同步
74 0
|
CDN
多主复制下处理写冲突(1)-同步与异步冲突检测及避免冲突
多主复制的最大问题:可能发生写冲突,这是必须要解决的。
88 0
|
消息中间件 canal 缓存
如何保证数据库和缓存双写一致性?
如何保证数据库和缓存双写一致性?
如何保证数据库和缓存双写一致性?
|
运维
简单记录一次ADG备库同步故障
这是一套11g的老库,主库3节点,备库1节点。项目上于昨天晚上做某测试扩容了表空间,在其他位置新建了9个数据文件,在备库无法创建这个非标准位置的datafile,从而导致同步中断。
332 0
|
SQL Oracle 关系型数据库
PostgreSQL pg_rewind,时间线修复,脑裂修复,flashback - 从库开启读写后,回退为只读从库。异步主从发生角色切换后,主库rewind为新主库的从库
PostgreSQL pg_rewind,时间线修复,脑裂修复,flashback - 从库开启读写后,回退为只读从库。异步主从发生角色切换后,主库rewind为新主库的从库
1898 1
一主两从的环境,如果主库挂了,如何选举一个从库作为主库?
一主两从的环境,如果主库挂了,如何选举一个从库作为主库? 如图: 如果M挂了,怎么从S1和S2中选举一个从库作为主库? 传统复制的解决方法 (1)查看从库状态: S1:show slave status; S2:show slave status; root@l...
914 0