分类: Mysql/postgreSQL
2011-07-15 07:19:27
mysql cluster的复制既支持cluster之间的复制,也可以支持cluster向innodb等其他存储引擎的复制,如果只是单节点的复制就经常会出现 Last_Error: The incident LOST_EVENTS occured on the master. Message: mysqld startup报错。
出现这个报错的主要有如下情况:
1、主mysql重启的时候
2、主mysql挂掉的时候
3、其他比较特殊的情况,比如slave和master之间的网络中断也会导致这个问题
报错原因剖析:
两个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 master将master转移到另外一个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_file和master_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;