Why Does the Slave Report LOST_EVENTS And What To Do
Last updated on OCTOBER 09, 2016
Applies to:MySQL Cluster - Version 4.1 and later
Geographic replication enables asynchronous replication across geographically separate clusters. This is often used for disaster recovery.
During MySQL Cluster geographical replication it might happen that the Slave SQL Node is reporting the LOST_EVENTS incident. This happens whenever the SQL node looses connection to the cluster (either by a controlled or crashing restart) and is trying to make sure that the Slave stops replicating. It does this to help protect against the slave becoming out-of-sync.
As an example, suppose a MySQL server responsible for logging all updates executed in MySQL Cluster is restarted. Suppose further that there is a moment in which it will be unable to log any changes done in the cluster. This means that changes made using another SQL or API node will not be in the binary log and consequently not replicated. Therefore, a LOST_EVENTS incident is reported in the binary logs and handled as an error by the Slave. Replication stops since data might be missing in the logs.
Below is an example of how the error is reported by the Slave (edited for clarity):
Last_Error: The incident LOST_EVENTS occured on the master. Message: mysqld startup
There are two cases when a LOST_EVENTS incident is written by the Master in its binary logs. Either will be in the Last_Error reported by the Slave as follows:
Sign In with your My Oracle Support account
Don't have a My Oracle Support account? Click to get started
Million Knowledge Articles and hundreds of Community platforms