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;