General Requirements for NDB Cluster Replication Symbol or Abbreviation Description (Refers to...) R’ Secondary replica 23.6.2 General Requirements for NDB Cluster Replication A replication channel requires two MySQL servers acting as replication servers (one each for the source and replica). For example, this means that in the case of a replication setup with two replication channels (to provide an extra channel for redundancy), there should be a a total of four replication nodes, two per cluster. Replication of an NDB Cluster as described in this section and those following is dependent on row- based replication. This means that the replication source MySQL server must be running with  --binlog- format=ROW  or  --binlog-format=MIXED , as described in Section 23.6.6, “Starting NDB Cluster Replication (Single Replication Channel)” . For general information about row-based replication, see Section 17.2.1, “Replication Formats” . If you attempt to use NDB Cluster Replication with  --binlog- format=STATEMENT , replication fails to work properly because the ndb_binlog_index  table on the source cluster and the  epoch  column of the  ndb_apply_status  table on the replica cluster are not updated (see Section 23.6.4, “NDB Cluster Replication Schema and Tables” ). Instead, only updates on the MySQL server acting as the replication source propagate to the replica, and no updates from any other SQL nodes in the source cluster are replicated. Important The default value for the  --binlog-format  option is  MIXED . Each MySQL server used for replication in either cluster must be uniquely identified among all the MySQL replication servers participating in either cluster (you cannot have replication servers on both the source and replica clusters sharing the same ID). This can be done by starting each SQL node using the  -- server-id= id  option, where  id  is a unique integer. Although it is not strictly necessary, we assume for purposes of this discussion that all NDB Cluster binaries are of the same release version. It is generally true in MySQL Replication that both MySQL servers ( mysqld  processes) involved must be compatible with one another with respect to both the version of the replication protocol used and the SQL feature sets which they support (see Section 17.5.2, “Replication Compatibility Between MySQL Versions” ). It is due to such differences between the binaries in the NDB Cluster and MySQL Server 8.0 distributions that NDB Cluster Replication has the additional requirement that both  mysqld  binaries come from an NDB Cluster distribution. The simplest and easiest way to assure that the  mysqld  servers are compatible is to use the same NDB Cluster distribution for all source and replica  mysqld  binaries. We assume that the replica server or cluster is dedicated to replication of the source cluster, and that no other data is being stored on it. All  NDB  tables being replicated must be created using a MySQL server and client. Tables and other database objects created using the NDB API (with, for example,  Dictionary::createTable() ) are not visible to a MySQL server and so are not replicated. Updates by NDB API applications to existing tables that were created using a MySQL server can be replicated. It is possible to replicate an NDB Cluster using statement-based replication. However, in this case, the following restrictions apply: Note 4611