错误描述：错误Last_Error: The incident LOST_EVENTS occured on themaster的解决办法；

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很多人说下面两条命令可以解决

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

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

二、当主是mysql cluser环境，从为innodb等其他的存储引擎的情况。
这个问题是我在测试中遇到过很多次的，因此找到了解决办法和大家共享一下，解决问题的原理和前面第一种情况类似，我就不说了，直接说解决步骤吧！
1、通过show slave statusG;在slave上找到大致的log文件名和位置，然后到master上的ndb_binlog_index表上找到和该log名和位置最 近的epoch
2、根据前面的epoch到另外一个SQL节点中找到日志文件和位置，比如：

3、将master上的ndb_binlog_index和另一个sql的这个表在该epoch附近进行对比！验证数据的正确性！
4、然后再更改slave上的master_host,master_log_file和master_log_pos从另外一个SQL节点做同步，比如 采用如下命令：

--转自