Bug #66823 Binlogging from MySQL Cluster tightly coupled to NDBCluster

• Submitted: 14 Sep 2012 19:55
• Modified: 28 Mar 2013 16:16
• Reporter: Kevin Benton
• Status: Not a Bug
• Category: MySQL Cluster: Cluster (NDB) storage engine
• Severity: S3 (Non-critical)
• Version: 7.2.4
• OS: Any
• CPU Architecture: Any

[14 Sep 2012 19:55] Kevin Benton

Description:
MySQL Cluster replication is overly tightly coupled to NDBCluster. Replication from MySQL Cluster to a non-clustered slave running a current version of MySQL (but not MySQL Cluster) will not get DDL changes like CREATE TABLE. I'm told by our TAM that this is because we don't have the NDBCluster storage engine on the slave even though we have v1 logging configured on the master.

How to repeat:
Set up replication from a MySQL Cluster to a stand-alone MySQL server that's not running MySQL Cluster binaries but an otherwise compatible version. Set the stand-alone slave up as a slave of the Cluster then create tables without specifying a storage engine on the Cluster (master). Note that the slave does not create the same table(s) though it shows it is up-to-date with the master.

The master will need to log in v1 format so the slave will get the changes properly.

Suggested fix:
Binary logging in v1 format must include any DDL from the master whether or not that master is a MySQL Cluster server or not. The DDL changes are too tightly coupled to the storage engine in MySQL Cluster.

[28 Mar 2013 16:16] Santo Leto

This was the replication chain:

Cluster --> Cluster --> Stand-alone MySQL Server
 7.2.4  -->  7.2.4  --> 5.1.45-enterprise-gpl-advanced-log 

However, log_slave_updates was off on the second cluster.

Closing as not a bug.