Description:
The rpl_ndb_multi_update3 test started failing in MySQL Cluster after merge in of 5.7.6. The failing query is a multi update which returns different data when using engine = NDB, it has nothing to do with replication.
This multi update query was initially written without the ORDER BY and thus it was undeterministic. Jonas fixed that problem in 2006 and it has been running fine since, setting the value of t2.b to 6 like all other engines.
Now with 5.7.6 it started failing since t2.b is set to 7 (seems like a reasonable value but since all other engines says 6 we would like the same in NDB).
rpl_ndb.rpl_ndb_multi_update3 [ fail ]
--- /home/mblaudd/mysql/trunk-cluster/mysql-test/suite/rpl_ndb/r/rpl_ndb_multi_update3.result
+++ /home/mblaudd/mysql/trunk-cluster/bld/mysql-test/var/log/rpl_ndb_multi_update3.reject
@@ -31,8 +31,8 @@
2 0
SELECT * FROM t2 ORDER BY a;
a b
-1 6
-2 6
+1 7
+2 7
include/sync_slave_sql_with_master.inc
SELECT * FROM t1 ORDER BY a;
a b
@@ -40,8 +40,8 @@
2 0
SELECT * FROM t2 ORDER BY a;
a b
-1 6
-2 6
+1 7
+2 7
drop table t1,t2;
How to repeat:
CREATE TABLE t1 (
a int unsigned not null auto_increment primary key,
b int unsigned
) ENGINE=NDB;
CREATE TABLE t2 (
a int unsigned not null auto_increment primary key,
b int unsigned
) ENGINE=NDB;
INSERT INTO t1 VALUES (NULL, 0), (NULL, 0);
INSERT INTO t2 VALUES (NULL, 0), (NULL,1);
SELECT * FROM t1 ORDER BY a;
a b
1 0
2 0
SELECT * FROM t2 ORDER BY a;
a b
1 0
2 1
UPDATE t2, (SELECT a FROM t1 ORDER BY a ASC) AS t SET t2.b = t.a+5 ;
SELECT * FROM t1 ORDER BY a;
a b
1 0
2 0
SELECT * FROM t2 ORDER BY a;
a b
1 7
2 7
DROP TABLE t1, t2;
Also see attached test script multi_update_order_problem.test
Suggested fix:
Update t2 with same values as other engines.
