I'm currently working with a large network of MySQL 5.1 DBs (using MyISAM tables) and I'm evaluating a move to MySQL Cluster. I would like to have the MySQL Cluster replicate off of one of the existing 5.1 hosts to ensure that it can handle the load we want to send it, and to test failure conditions with real data loads, etc.
So far, I've got the MySQL Cluster mysqld loaded up with all the MyISAM tables and I've got it connected to the replication master. Replication is working just fine (5.1 MyISAM -> 5.5 MyISAM). However, as soon as I convert one of the tables to ENGINE=NDBCLUSTER I get these errors:
121027 16:09:40 [ERROR] Slave SQL: Error 'Got error 0 'No error' from NDBCLUSTER' on query. Default database: 'accounts'. Query: 'UPDATE heartbeat SET ts = NOW() WHERE id = 1', Error_code: 1296
121027 16:09:40 [Warning] Slave: Got error 0 'No error' from NDB Error_code: 1296
121027 16:09:40 [Warning] Slave: Got error 0 'No error' from NDBCLUSTER Error_code: 1296
121027 16:09:40 [ERROR] Error running query, slave SQL thread aborted. Fix the problem, and restart the slave SQL thread with "SLAVE START". We stopped at log 'mysql-bin.027069' position 11283558
"heartbeat" is just some table we have that gets updated once a second. I can run the query by hand while connected to the cluster's API node (the same node that is reading the bin logs). It seems that the failure only occurs when the query is run on the slave thread.
Also, the query itself succeeds -- the heartbeat table is updated with the replicated value of NOW().
I am running 5.5.27 ndb 7.2.8 on 64-bit Linux hosts. I have 4 data nodes, one management node, and one API node (for now). This same error happened with 5.5.22 ndb 7.2.6 -- I'd upgraded to see if that would fix the problem, but no luck.
I have dug around with mysqld-debug trace logs and gdb. Near as I can tell there's a problem writing to the ndb_apply_status table, but I cannot pinpoint exactly what the problem is (nor am I sure that I am on the right track there).
This issue is also being tracked on the MySQL Forums.
1 Answer 1
Ah ha. This seems to be the error you get when you try to replicate from a server that uses statement binlogs. I initially overlooked that this scenario was not supported.
I was able to work around this by adding an intermediate mysqld that just converts the statement replication binlogs into mixed replication binlogs (using log-slave-updates and binlog-format=MIXED).
Hope this helps someone in the future.