Bug #31723 ndb_restore giving wrong backup file version information
Submitted: 19 Oct 2007 20:29 Modified: 18 Dec 2007 12:41
Reporter: Hartmut Holzgraefe Email Updates:
Status: Verified Impact on me:
None 
Category:MySQL Cluster: Cluster (NDB) storage engine Severity:S3 (Non-critical)
Version:mysql-5.1 OS:Linux
Assigned to: CPU Architecture:Any
Tags: 5.x and CGE
Triage: Triaged: D4 (Minor)

[19 Oct 2007 20:29] Hartmut Holzgraefe
Description:
When restoring using a ndb_restore binary from a CGE version 
the tool will always claim that the backup file was created
by a ndb-* version, too. On the other hand a non-CGE ndb_restore
will just print the version number without the CGE prefix.

Problem is that the ndb- prefix is not stored in the BACKUP*.ctl
files but only the numeric part of the version number (with
the major, minor, and build number in bytes 10, 11 and 12 of
the .ctl file).

The ndb- prefix is only generated by the getVersionString()
function from storage/ndb/src/common/util/version.c so it 
is always prepended by a ndb_restore binary from a CGE release.

even worse: this will lead to version number clashes in future
releases. If we ever get to a regular MySQL 6.1 release backup
files from regular 6.1.x are not distiguishable from ndb-6.1.x
backup files by just looking at the version field in the header.

How to repeat:
Create a backup with a regular 5.1.22 cluster setup
and try to restore it in e.g. 5.1.22-ndb-6.3.3 or vice versa

output from test script:

starting plain 5.1.22
backing up plain 5.1.22
restoring backup from plain 5.1.22
Ndb version in backup files: Version 5.1.22
=======
starting 5.1.22 ndb-6.3.3
restoring backup from plain 5.1.22
Ndb version in backup files: ndb-5.1.22
backing up 5.1.22 ndb-6.3.3
restoring backup from 5.1.22 ndb-6.3.3
Ndb version in backup files: ndb-6.3.3
=======
starting plain 5.1.22 again
restoring 5.1.22 ndb-6.3.3 backup
Ndb version in backup files: Version 6.3.3
Restore program older than backup version. Not supported. 
Use new restore program

Suggested fix:
Find a better (and if possible: backwards compatible) way 
to store version information in the backup .ctl files
[1 Nov 2007 15:06] 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/36890

ChangeSet@1.2676, 2007-11-01 16:05:45+01:00, jonas@perch.ndb.mysql.com +3 -0
  ndb - bug#31723
    fix restore from drop6p>=3
[6 Nov 2007 9:40] 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/37165

ChangeSet@1.2713, 2007-11-06 10:43:57+01:00, tomas@whalegate.ndb.mysql.com +3 -0
  ndb - bug#31723
     fix restore from drop6p >= 3
[8 Nov 2007 13:03] Jon Stephens
Documented bugfix in 5.1.22-ndb-6.3.6 changelog. Left in PP status.
[14 Nov 2007 12:44] Jonas Oreland
ndb_restore now supports drop6 backups.
this fixes the problem in the issue...

i would like to close this bug report...
what do you think...

/Jonas
[15 Dec 2007 0:00] Bugs System
No feedback was provided for this bug for over a month, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".
[18 Dec 2007 12:41] Hartmut Holzgraefe
The problem with CGE ndb_restore just printing "ndb-" in front of every backup file version number output still exists, e.g. ndb_restore from 5.1.22-ndb-6.3.6 prints the following when reading a backup created from a 5.1.22-RC cluster:

  [...]
  Ndb version in backup files: ndb-5.1.22 
  [...]

So the information given is still confusing, and as soon as we start a 6.1 development branch it will even become ambiguous, so i don't see how this could be closed ...
[18 Dec 2007 12:44] Hartmut Holzgraefe
Workaround for now: simply don't trust the "ndb-" prefix in version numbers reported by ndb_restore, instead take version numbers >=6.1.0 as CGE version numbers and version numbers <6.1.0 as regular MySQL release version numbers.

For now this should be an acceptable workaround but the very moment we start work on a regular 6.1 branch the Workaround Viability would change from W4 to W2 or even W1 as there is no good way to work around the ambiguity anymore.
[20 Dec 2007 11:29] Jonas Oreland
i fixed the customer issue
i removing "affects customer" and myself from this bug