Known Issues in NDB Cluster Replication NDB Cluster Replication and Unique Keys.  In older versions of NDB Cluster, operations that updated values of unique key columns of  NDB  tables could result in duplicate-key errors when replicated. This issue is solved for replication between  NDB  tables by deferring unique key checks until after all table row updates have been performed. Deferring constraints in this way is currently supported only by  NDB . Thus, updates of unique keys when replicating from  NDB  to a different storage engine such as  InnoDB  or  MyISAM  are still not supported. The problem encountered when replicating without deferred checking of unique key updates can be illustrated using  NDB  table such as  t , is created and populated on the source (and transmitted to a replica that does not support deferred unique key updates) as shown here: CREATE TABLE t ( p INT PRIMARY KEY, c INT, UNIQUE KEY u (c) ) ENGINE NDB; INSERT INTO t VALUES (1,1), (2,2), (3,3), (4,4), (5,5); 4615 •Multi-source and circular replication are not supported (tables on both the source and the replica must use the  NDB  storage engine for this to work). Replication from NDB to other storage engines.   It is possible to replicate an  NDB  table on the source to a table using a different storage engine on the replica, taking into account the restrictions listed here: Restarting with --initial.  Restarting the cluster with the  --initial  option causes the sequence of GCI and epoch numbers to start over from  0 . (This is generally true of NDB Cluster and not limited to replication scenarios involving Cluster.) The MySQL servers involved in replication should in this case be restarted. After this, you should use the  RESET MASTER  and  RESET REPLICA | SLAVE  statements to clear the invalid  ndb_binlog_index  and  ndb_apply_status  tables, respectively. This is because the replica may not be able to separate transactions occurring in one database from those in another if they are written within the same epoch. In addition, every transaction handled by the  NDB storage engine involves at least two databases—the target database and the  mysql  system database— due to the requirement for updating the  mysql.ndb_apply_status  table (see Section 23.6.4, “NDB Cluster Replication Schema and Tables” ). This in turn breaks the requirement for multithreading that the transaction is specific to a given database. Multithreaded replicas not supported.   NDB Cluster does not support multithreaded replicas, and setting related system variables such as  slave_parallel_workers ,  slave_checkpoint_group , and slave_checkpoint_group  (or the equivalent  mysqld  startup options) has no effect. GTIDs not supported.   Replication using global transaction IDs is not compatible with the  NDB  storage engine, and is not supported. Enabling GTIDs is likely to cause NDB Cluster Replication to fail. Every  NDB  table is implicitly partitioned by key when it is created. See Section 24.2.5, “KEY Partitioning” , for more information. The same statement fails with a duplicate key error or other constraint violation on the replica, because the ordering of the row updates is performed for one partition at a time, rather than for the table as a whole. The following  UPDATE  statement on  t  succeeds on the source, since the rows affected are processed in the order determined by the  ORDER BY  option, performed over the entire table: UPDATE t SET c = c - 1 ORDER BY p; Note