MySQL Bugs: #39154: Unexpected row on master in system table "mysql.ndb_apply

Bug #39154	Unexpected row on master in system table "mysql.ndb_apply_status"
Submitted:	1 Sep 2008 10:53
Reporter:	Joerg Bruehe	Email Updates:
Status:	Verified	Impact on me:	None
Category:	MySQL Cluster: Cluster (NDB) storage engine	Severity:	S2 (Serious)
Version:	mysql-5.1-telco-6.3	OS:	Any
Assigned to:	Assigned Account	CPU Architecture:	Any
Tags:	mysql-5.1-telco-6.3.17
Triage:	Triaged: D3 (Medium) / R2 (Low) / E2 (Low)

Description:
Observed when running the tests of the Cluster 6.3.17 build:

=====
rpl_ndb.rpl_ndb_apply_status   [ fail ]

--- /PATH/mysql-test/suite/rpl_ndb/r/rpl_ndb_apply_status.result
+++ /PATH/mysql-test/suite/rpl_ndb/r/rpl_ndb_apply_status.reject
@@ -14,6 +14,7 @@
 *** on master it should be empty ***
 select * from mysql.ndb_apply_status;
 server_id      epoch   log_name        start_pos       end_pos
+0      450971566080            0       0
 *** on slave there should be one row ***
 select count(*) from mysql.ndb_apply_status;
 count(*)
=====

Observed on various (but not all) platforms:
- RPM builds on SLES 10 for x86 and x86_64,
- RPM builds on SLES 9 for x86,
- RPM builds on RedHat 5 for x86 and x86_64,
- RPM builds on RedHat 4 for x86_64,
- Solaris 10 using Sparc (32), Sparc-64, x86, or x86_64,
- Solaris 9 using Sparc-64 or x86,
- OS X 10.5 using x86 or x86_64.

Observed only in a test suite run that used these options:
   --ps-protocol --mysqld=--binlog-format=row
On the same platforms, the test passed when neither option was used.
(There is no run using only one of these options, so I cannot say which one caused it.)

On several of the platforms listed with this failure, the test failed (or was not taken) for other reasons, which will be reported separately:
- SLES 9 and 10 on IA64: "Cluster Master was not installed ok"
- RedHat 3, 4, and 5 on IA64: "Cluster Master was not installed ok"
- RedHat 3 on x86 or x86_64: "Cluster Master was not installed ok"
- on several platforms, the suite was not taken for other reasons.

However, there is one platform where it passed:
- SLES 9 on x86_64 had very different symptoms throughout the tests.

How to repeat:
Run the *full* tests.

i 99% sure I fixed this
didnt know there was a bug,

problem was the ndb_restore (with some options) put a row in ndb_apply_status
and tomas reordered the tests...

btw, my triage would be D4, W5, I5

Assigned to me for verification on currently version