Bug #39154 Unexpected row on master in system table "mysql.ndb_apply_status"
Submitted: 1 Sep 2008 10:53 Modified: 25 Oct 2023 15:49
Reporter: Joerg Bruehe Email Updates:
Status: Won't fix Impact on me:
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

[1 Sep 2008 10:53] Joerg Bruehe
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;

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.
[23 Oct 2008 11:29] Jonas Oreland
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...
[23 Oct 2008 11:30] Jonas Oreland
btw, my triage would be D4, W5, I5
[16 Apr 2009 13:23] Jonathan Miller
Assigned to me for verification on currently version
[25 Oct 2023 15:49] Magnus BlÄudd
Posted by developer:
Retested on 8.0.35 and there is no known problem with ndb_rpl_apply_status.test, the ndb_apply_status functionality was revisited in 8.0 when implementing WL#15455 NDB Replica threadsafe

[ 50%] ndb_rpl.ndb_rpl_apply_status              [ pass ]   6047