Chinaunix首页 | 论坛 | 博客
  • 博客访问: 2343756
  • 博文数量: 276
  • 博客积分: 5998
  • 博客等级: 大校
  • 技术积分: 5175
  • 用 户 组: 普通用户
  • 注册时间: 2010-12-24 14:43
文章分类

全部博文(276)

文章存档

2014年(25)

2013年(11)

2012年(69)

2011年(167)

2010年(4)

分类: Mysql/postgreSQL

2011-07-15 07:19:27

 错误Last_Error: The incident LOST_EVENTS occured on the master的解决办法

      mysql cluster的复制既支持cluster之间的复制,也可以支持clusterinnodb等其他存储引擎的复制,如果只是单节点的复制就经常会出现 Last_Error: The incident LOST_EVENTS occured on the master. Message: mysqld startup报错。


出现这个报错的主要有如下情况:
1
、主mysql重启的时候
2
、主mysql挂掉的时候
3
、其他比较特殊的情况,比如slavemaster之间的网络中断也会导致这个问题



报错原因剖析:
两个mysqld节点之间会同步各自的二进制日志,但是有一个mysqld节点挂掉之后,挂掉的那段时间丢失的日志不会再复制,也就是说那段时间挂掉的 mysqld节点的二进制日志是不完整的,我们的复制居于二进制日志来进行的,如果这个时候继续进行复制就会出现数据丢失的现象,因此为了避免这种数据的 丢失,复制的时候当出现主mysql连接不上或者超时的时候就会停止掉复制的SQL线程,出现这个报错:Last_Error: The incident LOST_EVENTS occured on the master. Message: mysqld startup

解决办法:

正确的办法是找到最后的epoch,然后从另外一个mysqld节点进行复制!通过google很多人说下面两条命令可以解决
SET GLOBAL SQL_SLAVE_SKIP_COUNTER = 1;
START SLAVE;

但是采用上面两条命令是有问题的,会造成数据的丢失!大家不要效仿!

 

下面我就分两种情况来介绍这个错误的解决办法!
一、当两边都是cluster环境的时候
两边都是cluster环境的情况比较简单,很好定位epoch位置,然后通过epoch位置找到二进制日志文件名和位置,然后采用change mastermaster转移到另外一个mysqld节点继续复制。
两边都是cluster环境的情况还没遇到,也没有做过实验,但是mysql官网已经给出了解决办法,我就不再详细写了,见如下链接
http://dev.mysql.com/doc/refman/5.1/en/mysql-cluster-replication-failover.html

二、当主是mysql cluser环境,从为innodb等其他的存储引擎的情况。
这个问题是我在测试中遇到过很多次的,因此找到了解决办法和大家共享一下,解决问题的原理和前面第一种情况类似,我就不说了,直接说解决步骤吧!
1
、通过show slave status\G;slave上找到大致的log文件名和位置,然后到master上的ndb_binlog_index表上找到和该log名和位置最 近的epoch
2
、根据前面的epoch到另外一个SQL节点中找到日志文件和位置,比如:
SELECT POSITION,FILE FROM ndb_binlog_index WHERE epoch='60086592471055';
3
、将master上的ndb_binlog_index和另一个sql的这个表在该epoch附近进行对比!验证数据的正确性!
4
、然后再更改slave上的master_host,master_log_filemaster_log_pos从另外一个SQL节点做同步,比如 采用如下命令:

change master to master_host='192.168.3.224',master_user='replication',master_password='123456',
master_log_file='mysql-bin.000021', master_log_pos=1012;

start slave;




阅读(1299) | 评论(0) | 转发(0) |
给主人留下些什么吧!~~