MySQL Bugs: #31723: ndb_restore giving wrong backup file version information

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

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

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

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

Documented bugfix in 5.1.22-ndb-6.3.6 changelog. Left in PP status.

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

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".

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 ...

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.

i fixed the customer issue
i removing "affects customer" and myself from this bug