content_image/845215.jpg
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); 

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; 

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. 

<img src='content_image/845215.jpg'>

## Note 

Every NDB  table is implicitly partitioned by key when it is created. See Section 24.2.5, “KEY Partitioning” , for more information. 

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. 

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. 

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. 

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. 

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: 

•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). 

