Prior to MySQL 5.1.18, a MySQL Cluster replication slave mysqld had no way of detecting that the connection from the master had been interrupted (due to, for instance, the master going down or a network failure). For this reason, it was possible for the slave to become inconsistent with the master.

(If high availability is a requirement for the slave server or cluster, then it is still advisable to set up multiple replication lines, to monitor the master mysqld on the primary replication line, and to fail over to a secondary line if and as necessary. For information about implementing this type of setup, see Section 15.10.7, “Using Two Replication Channels”, and Section 15.10.8, “Implementing Failover with MySQL Cluster”.)

Beginning with MySQL 5.1.18, the master issues a “gap” event when connecting to the cluster. When the slave encounters a gap in the replication log, it stops with an error message. This message is available in the output of SHOW SLAVE STATUS, and indicates that the SQL thread has stopped due to an incident registered in the replication stream, and that manual intervention is required. In order to restart the slave, it is necessary to issue the following commands:

SET GLOBAL SQL_SLAVE_SKIP_COUNTER = 1;
START SLAVE; 

The slave then resumes reading the master binlog from the point where the gap was recorded.

Circular replication is not supported for Cluster replication. This is because all log events created in a particular MySQL Cluster are wrongly tagged with the server id of the MySQL server used as master and not with the server id of the originating server.

Because of this misidentification, replicating between MySQL servers A→B→A, where B is any MySQL server connected to a cluster A, causes the cluster table changes (log entries) of A to “lose” the originating server's identifier in the log from B to A. This causes the changes to be reapplied on server A.

The use of data definition statements, such as CREATE TABLE, DROP TABLE, and ALTER TABLE, are recorded in the binary log for only the MySQL server on which they are issued.

In MySQL 5.1.6, only those NDB tables having explicit primary keys could be replicated. This limitation was lifted in MySQL 5.1.7.

Restarting the cluster with the --initial option will cause the sequence of GCI and epoch numbers to start over from 0. (This is generally true of MySQL Cluster and not limited to replication scenarios involving Cluster.) The MySQL servers involved in replication should in this case be replicated. After this, you should use the RESET MASTER and RESET SLAVE statements to clear the invalid ndb_binlog_index and ndb_apply_status tables. respectively.

Trying to set values for the auto_increment_offset and auto_increment_increment server system variables produces unpredictable results. The use of these variables is not supported with MySQL Cluster replication.