Known Issues in NDB Cluster Replication •All updates to data rows on the cluster acting as the source must be directed to a single MySQL server. •It is not possible to replicate a cluster using multiple simultaneous MySQL replication processes. •Only changes made at the SQL level are replicated. These are in addition to the other limitations of statement-based replication as opposed to row-based replication; see Section 17.2.1.1, “Advantages and Disadvantages of Statement-Based and Row-Based Replication” , for more specific information concerning the differences between the two replication formats. This section discusses known problems or issues when using replication with NDB Cluster. Loss of connection between source and replica.  A loss of connection can occur either between the source cluster SQL node and the replica cluster SQL node, or between the source SQL node and the data nodes of the source cluster. In the latter case, this can occur not only as a result of loss of physical connection (for example, a broken network cable), but due to the overflow of data node event buffers; if the SQL node is too slow to respond, it may be dropped by the cluster (this is controllable to some degree by adjusting the  MaxBufferedEpochs  and  TimeBetweenEpochs  configuration parameters). If this occurs,  it is entirely possible for new data to be inserted into the source cluster without being recorded in the source SQL node’s binary log . For this reason, to guarantee high availability, it is extremely important to maintain a backup replication channel, to monitor the primary channel, and to fail over to the secondary replication channel when necessary to keep the replica cluster synchronized with the source. NDB Cluster is not designed to perform such monitoring on its own; for this, an external application is required. The source SQL node issues a “gap”  event when connecting or reconnecting to the source cluster. (A gap event is a type of “incident event,”  which indicates an incident that occurs that affects the contents of the database but that cannot easily be represented as a set of changes. Examples of incidents are server failures, database resynchronization, some software updates, and some hardware changes.) When the replica encounters a gap in the replication log, it stops with an error message. This message is available in the output of  SHOW REPLICA | 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. See Section 23.6.8, “Implementing Failover with NDB Cluster Replication” , for more information about what to do in such circumstances. Because NDB Cluster is not designed on its own to monitor replication status or provide failover, if high availability is a requirement for the replica server or cluster, then you must set up multiple replication lines, monitor the source  mysqld on the primary replication line, and be prepared fail over to a secondary line if and as necessary. This must be done manually, or possibly by means of a third- party application. For information about implementing this type of setup, see Section 23.6.7, “Using Two Replication Channels for NDB Cluster Replication” , and Section 23.6.8, “Implementing Failover with NDB Cluster Replication” . If you are replicating from a standalone MySQL server to an NDB Cluster, one channel is usually sufficient. Circular replication.  NDB Cluster Replication supports circular replication, as shown in the next example. The replication setup involves three NDB Clusters numbered 1, 2, and 3, in which Cluster 1 Important 23.6.3 Known Issues in NDB Cluster Replication 4612