Description:
By default ndb_log_update_as_write=ON and the binlog contains INSERT events for update statements. According to the manual (http://dev.mysql.com/doc/refman/5.1/en/mysql-cluster-replication-conflict-resolution.html) setting this variable to OFF should make the cluster log row updates as UPDATE events. This does not work for newly created tables. Only if the logging mysqld is restarted after creating the table, the variable is honored. Another workaround is ALTER TABLE <tablename> ENGINE NDBCLUSTER between CREATE TABLE and the first UPDATE statement to be replicated.
Repeated with 6.3.17, 6.3.18, 6.3-bzr, 6.4-bzr. Not repeatable with 6.2.15.
This affects anybody who replicates from a cluster master into a noncluster slave. The fake INSERT events will cause duplicate key errors on the slave.
How to repeat:
my.cnf:
---
[mysqld]
log-bin
ndb_log_update_as_write=0
test.sql:
---
use test;
drop table if exists t1;
create table t1 (id int primary key, val char(3)) engine ndbcluster;
insert into t1 values (1, "foo"), (2, "bar");
select sleep(1); --wait for another epoch
update t1 set val="baz" where id=2;
then check the binlog event for the update statement. It will look like so:
BINLOG '
74XsSBMBAAAALAAAAAQDAAAAACsAAAAAAAAABHRlc3QAAnQxAAID/gL+AwI=
74XsSBMBAAAAPgAAAEIDAAAAABAAAAAAAAAABW15c3FsABBuZGJfYXBwbHlfc3RhdHVzAAUDCA8I
CAL/AAA=
74XsSBcBAAAAOwAAAH0DAAAAABAAAAAAAAAABR/gAQAAAAQAAAB6AQAAAAAAAAAAAAAAAAAAAAAA
AAA=
### INSERT INTO mysql.ndb_apply_status
### SET
### @1=1
### @2=1623497637892
### @3=''
### @4=0
### @5=0
74XsSBcBAAAAJgAAAKMDAAAQACsAAAAAAAEAAgP8AgAAAANiYXo=
'/*!*/;
### INSERT INTO test.t1
### SET
### @1=2
### @2='baz'
