Bug #46890 ndbmtd: Dropping last table in LQH during LCP can crash node
Submitted: 24 Aug 2009 12:22 Modified: 25 Aug 2009 11:56
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-7.0 OS:Any
Assigned to: Jonas Oreland CPU Architecture:Any

[24 Aug 2009 12:22] Jonas Oreland
Description:
FYI: bug exist in all version, but will only be fixed in >= 7.0
     as with ndbmtd, there can be LQH instances wo/ tables,
     whereas prior to ndbmtd, one had to manually drop our system tables
     to get into this situation.

How to repeat:
start cluster using ndbd
stop cluster
start cluster using ndbmtd
run testDict -n CreateAndDropAtRandom

Suggested fix:
keep correct states
[24 Aug 2009 12:22] Jonas Oreland
btw: found while trying to repeat bug#46873...
[24 Aug 2009 12:25] 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/81410

2965 Jonas Oreland	2009-08-24
      ndb - bug#46890
        1) don't increase cnoOfFragsCheckpointed for tables that are being dropped
        2) set clcpCompletedState if LCP completes wo/ fragments
[24 Aug 2009 12:27] Jonas Oreland
pushed to 7.0.7
[25 Aug 2009 11:56] Jon Stephens
Documented bugfix in the NDB-7.0.7 changelog as follows:

      When using multi-threaded data node processes (ndbmtd), it was possible
      for LQH threads to continue running even after all NDB tables had been
      dropped. This meant that dropping the last remaining NDB table during a
      local checkpoint could cause multi-threaded data nodes to fail.