NDB Cluster Replication See Section 23.4, “NDB Cluster Programs” , for more information about these utilities. NDB Cluster supports  asynchronous replication , more usually referred to simply as “replication” . This section explains how to set up and manage a configuration in which one group of computers operating as an NDB Cluster replicates to a second computer or group of computers. We assume some familiarity on the part of the reader with standard MySQL replication as discussed elsewhere in this Manual. (See Chapter 17,  Replication ). NDB Cluster does not support replication using GTIDs; semisynchronous replication and group replication are also not supported by the  NDB  storage engine. Normal (non-clustered) replication involves a source server and a replica server, the source being so named because operations and data to be replicated originate with it, and the replica being the recipient of these. In NDB Cluster, replication is conceptually very similar but can be more complex in practice, as it may be extended to cover a number of different configurations including replicating between two complete clusters. Although an NDB Cluster itself depends on the  NDB  storage engine for clustering functionality, it is not necessary to use  NDB  as the storage engine for the replica’s copies of the replicated tables (see Replication from NDB to other storage engines). However, for maximum availability, it is possible (and preferable) to replicate from one NDB Cluster to another, and it is this scenario that we discuss, as shown in the following figure: 23.6 NDB Cluster Replication Note In this scenario, the replication process is one in which successive states of a source cluster are logged and saved to a replica cluster. This process is accomplished by a special thread known as the NDB binary 4609 Figure 23.31 NDB Cluster-to-Cluster Replication Layout