Known Issues in NDB Cluster Replication •Using a storage engine which does not perform binary logging for tables on the replica requires special handling. •Use of a nontransactional storage engine for tables on the replica also requires special handling. •The source  mysqld  must be started with  --ndb-log-update-as-write=0  or  --ndb-log-update- as-write=OFF . The next few paragraphs provide additional information about each of the issues just described. Multiple sources not supported when replicating NDB to other storage engines.   For replication from  NDB  to a different storage engine, the relationship between the two databases must be one-to-one. This means that bidirectional or circular replication is not supported between NDB Cluster and other storage engines. In addition, it is not possible to configure more than one replication channel when replicating between  NDB and a different storage engine. (An NDB Cluster database  can  simultaneously replicate to multiple NDB Cluster databases.) If the source uses  NDB  tables, it is still possible to have more than one MySQL Server maintain a binary log of all changes, but for the replica to change sources (fail over), the new source- replica relationship must be explicitly defined on the replica. Replicating NDB tables to a storage engine that does not perform binary logging.  If you attempt to replicate from an NDB Cluster to a replica that uses a storage engine that does not handle its own binary logging, the replication process aborts with the error  Binary logging not possible ... Statement cannot be written atomically since more than one engine involved and at least one engine is self-logging  (Error  1595 ). It is possible to work around this issue in one of the following ways: • Turn off binary logging on the replica.   This can be accomplished by setting  sql_log_bin = 0 . • Change the storage engine used for the mysql.ndb_apply_status table.   Causing this table to use an engine that does not handle its own binary logging can also eliminate the conflict. This can be done by issuing a statement such as  ALTER TABLE mysql.ndb_apply_status ENGINE=MyISAM  on the replica. It is safe to do this when using a storage engine other than  NDB  on the replica, since you do not need to worry about keeping multiple replicas synchronized. • Filter out changes to the mysql.ndb_apply_status table on the replica.   This can be done by starting the replica with  --replicate-ignore-table=mysql.ndb_apply_status . If you need for other tables to be ignored by replication, you might wish to use an appropriate  --replicate-wild- ignore-table  option instead. Important You should  not  disable replication or binary logging of mysql.ndb_apply_status  or change the storage engine used for this table when replicating from one NDB Cluster to another. See Replication and binary log filtering rules with replication between NDB Clusters, for details. Replication from NDB to a nontransactional storage engine.   When replicating from  NDB  to a nontransactional storage engine such as  MyISAM , you may encounter unnecessary duplicate key errors when replicating  INSERT ... ON DUPLICATE KEY UPDATE  statements. You can suppress these by using  --ndb-log-update-as-write=0 , which forces updates to be logged as writes, rather than as updates. Replication and binary log filtering rules with replication between NDB Clusters.   If you are using any of the options  --replicate-do-* ,  --replicate-ignore-* ,  --binlog-do-db , or  --binlog- 4616