My Oracle Support Banner

Why Does the Secondary Report LOST_EVENTS And What To Do (Doc ID 1024297.1)

Last updated on JUNE 28, 2021

Applies to:

MySQL Cluster - Version 4.1 and later
All Platforms


Disclaimer: Starting from v8.0, some terms have been deprecated. Older releases will only use the deprecated terminology, and new releases will only use new terminology. Please see for a complete list of those changes, and in which minor versions it happened.

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 Secondary 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 Secondary stops replicating. It does this to help protect against the secondary 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 Secondary. Replication stops since data might be missing in the logs.

Below is an example of how the error is reported by the Secondary (edited for clarity):


To view full details, sign in with your My Oracle Support account.

Don't have a My Oracle Support account? Click to get started!

My Oracle Support provides customers with access to over a million knowledge articles and a vibrant support community of peers and Oracle experts.