Bug #36500 Endless 410 with long running transaction
Submitted: 5 May 2008 9:45 Modified: 8 Dec 2009 16:23
Reporter: Jonas Oreland Email Updates:
Status: Closed Impact on me:
None 
Category:MySQL Cluster: Cluster (NDB) storage engine Severity:S3 (Non-critical)
Version:mysql-5.1-telco-6.2 OS:Any
Assigned to: Jonas Oreland CPU Architecture:Any

[5 May 2008 9:45] Jonas Oreland 
Description:
thread1> begin; insert
thread2> update until 410 (out of REDO)
thread1> commit/rollback;

still endless 410

How to repeat:
.

Suggested fix:
.
[5 May 2008 9:52] Jonas Oreland 
Patch for drop6

Attachment: bug36500.patch (text/x-patch), 6.47 KiB.
[7 Dec 2009 11:05] Bugs System 
A patch for this bug has been committed. After review, it may
be pushed to the relevant source trees for release in the next
version. You can access the patch from:

  http://lists.mysql.com/commits/93037

3180 Jonas Oreland	2009-12-07
      ndb - bug#36500 - 1) force lcp from LQH if redo gets too full 2) try to handle case where tail does not move in setLogTail by changing head forwardquilt top
[7 Dec 2009 11:21] Bugs System 
Pushed into 5.1.39-ndb-7.1.0 (revid:jonas@mysql.com-20091207111648-6zex5m570elrr1dw) (version source revid:jonas@mysql.com-20091207111648-6zex5m570elrr1dw) (merge vers: 5.1.39-ndb-7.1.0) (pib:13)
[7 Dec 2009 11:25] Jonas Oreland 
pushed to 6.3.29 and 7.0.10
for docs:
When a long running transaction, that lasted long enough to cause 410 (out of redo log) later got committed/rolledback, it could happen that cluster did not manage to release log-space, so that the 410 stuck around for-ever.

The most likely cause of such transaction is an application bug.
The fix, (hopefully) handles most cases of this.
[8 Dec 2009 13:59] Bugs System 
A patch for this bug has been committed. After review, it may
be pushed to the relevant source trees for release in the next
version. You can access the patch from:

  http://lists.mysql.com/commits/93199

3181 Martin Skold	2009-12-08 [merge]
      Merge
      modified:
        configure.in
        mysql-test/std_data/ndb_config_mycnf1.cnf
        mysql-test/suite/ndb/r/ndb_config.result
        mysql-test/suite/ndb/t/ndb_config.test
        sql/ha_ndbcluster_binlog.cc
        storage/ndb/src/kernel/blocks/dbdih/DbdihMain.cpp
        storage/ndb/src/kernel/blocks/dblqh/Dblqh.hpp
        storage/ndb/src/kernel/blocks/dblqh/DblqhInit.cpp
        storage/ndb/src/kernel/blocks/dblqh/DblqhMain.cpp
        storage/ndb/src/ndbapi/Ndb.cpp
        storage/ndb/test/ndbapi/testBlobs.cpp
[8 Dec 2009 16:23] Jon Stephens 
Documented bugfix in the NDB-6.3.29 and 7.0.10 changelogs as follows:

        When a long-running transaction lasting long enough to cause
        Error 410 (REDO log files overloaded) was later committed or
        rolled back, it could happen that NDBCLUSTER was not able to
        release the space used for the REDO log, so that the error
        condition persisted indefinitely.

        The most likely cause of such transactions is a bug in the
        application using MySQL Cluster. This fix should handle most
        cases where this might occur.

Closed.