Bug #43042 backup_id is not handled correctly larger than 65535
Submitted: 20 Feb 2009 4:27 Modified: 20 Feb 2009 11:19
Reporter: Mikiya Okuno Email Updates:
Status: Closed Impact on me:
None 
Category:MySQL Cluster: Cluster (NDB) storage engine Severity:S3 (Non-critical)
Version:6.3.20 OS:Any
Assigned to: Jonas Oreland CPU Architecture:Any

[20 Feb 2009 4:27] Mikiya Okuno
Description:
While backup_id is defined as Uint32 in class Backup, backup_id larger than 65535 is handled incorrectly. START BACKUP should handle backup_id up to 2^32.

Problem 1.

backup_id cannot be incremented unless it is not specified explicitly.

Problem 2.

backup_id larger than 2^31 result in minus values.

How to repeat:
Problem 1.

ndb_mgm> START BACKUP 65536
Waiting for completed, this may take several minutes
Node 11: Backup 65536 started from node 1
Node 11: Backup 65536 started from node 1 completed
 StartGCP: 31190 StopGCP: 31196
 #Records: 1062989 #LogRecords: 0
 Data: 298903896 bytes Log: 0 bytes
ndb_mgm> START BACKUP 
Waiting for completed, this may take several minutes
Node 11: Backup 1 started from node 1
ndb_mgm> Node 11: Backup 1 started from node 1 completed
 StartGCP: 31200 StopGCP: 31208
 #Records: 1062989 #LogRecords: 0
 Data: 298903896 bytes Log: 0 bytes

problem 2.

ndb_mgm> start backup 2147483649
Waiting for completed, this may take several minutes
Node 11: Backup -2147483647 started from node 1
ndb_mgm> Node 11: Backup 2147483649 started from node 1 completed
 StartGCP: 31285 StopGCP: 31293
 #Records: 1062989 #LogRecords: 0
 Data: 298903896 bytes Log: 0 bytes

After taking these three backups above, you can find the following sub-directories under BACKUP directory:
shell> ls BACKUP
BACKUP--2147483647  BACKUP-1  BACKUP-65536

Suggested fix:
Please have ndbd and ndb_mgmd to handle backup_id correctly, or limit it to 65535.
[20 Feb 2009 6:05] Jonas Oreland
can you check if this is a duplicate of bug#41031
which I fixed yesterday (i.e not yet released)
[20 Feb 2009 8:25] Mikiya Okuno
Jonas,

I confirmed that the "Problem 1" is fixed in the current 6.3 tree. However, the "Problem 2" is remaining still. I guess some part which decides a backup dir name has %d instead of %u in sprintf like functions.

Kind regards,
Mikiya
[20 Feb 2009 8:43] 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/66991

2849 Jonas Oreland	2009-02-20
      ndb - bug#43042 - fix %d/%u handling wrt backup-id
[20 Feb 2009 8:47] 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/66992

2849 Jonas Oreland	2009-02-20
      ndb - bug#43042 - fix %d/%u handling wrt backup-id
[20 Feb 2009 8:54] Bugs System
Pushed into 5.1.32-ndb-6.3.23 (revid:jonas@mysql.com-20090220085122-wtwo4vj5fyelk4mn) (version source revid:jonas@mysql.com-20090220085122-wtwo4vj5fyelk4mn) (merge vers: 5.1.32-ndb-6.3.23) (pib:6)
[20 Feb 2009 8:55] Bugs System
Pushed into 5.1.32-ndb-6.4.3 (revid:jonas@mysql.com-20090220085344-ymjrn5kc4rgi3b15) (version source revid:jonas@mysql.com-20090220085344-ymjrn5kc4rgi3b15) (merge vers: 5.1.32-ndb-6.4.3) (pib:6)
[20 Feb 2009 8:56] Jonas Oreland
docs: Fixed various printouts that caused backup id >= 2^31 to be printed
  as a negative number
[20 Feb 2009 8:56] Bugs System
Pushed into 5.1.32-ndb-6.2.17 (revid:jonas@mysql.com-20090220084610-zfheg4ipg83vbz9b) (version source revid:jonas@mysql.com-20090220084610-zfheg4ipg83vbz9b) (merge vers: 5.1.32-ndb-6.2.17) (pib:6)
[20 Feb 2009 11:19] Jon Stephens
Documented in the NDB-6.2.17, 6.3.23, and 6.4.3 changelogs as follows:

        Backup IDs greater than 2³¹ were not handled correctly, causing 
        negative values to be used in backup directory names and 
        printouts.