Bug #33406 ndb_restore -e restores epoch with wrong (big) value from old backups

Submitted: 20 Dec 2007 15:34 Modified: 7 Jan 2008 12:09
Reporter: Tomas Ulin Email Updates:
Status: Closed Impact on me:
None 
Category:MySQL Cluster: Replication Severity:S3 (Non-critical)
Version:CGE 6.2/3 OS:Any
Assigned to: Tomas Ulin CPU Architecture:Any

[20 Dec 2007 15:34] Tomas Ulin
Description:
ndb_restore -e restores to big value into apply_status if restore done from old (pre micro GCP) version, e.g. mysql-5.0/1 or CGE-6.1

How to repeat:
.

Suggested fix:
workaround in current CGE versions is to shift value of epoch down 32 bits to get correct value
[20 Dec 2007 16:04] 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/40278

ChangeSet@1.2683, 2007-12-20 16:36:18+01:00, tomas@whalegate.ndb.mysql.com +4 -0
  Bug #33406  	ndb_restore -e restores epoch with wrong (big) value from old backups
[7 Jan 2008 12:09] Jon Stephens
Documented in the 5.1.23-ndb-6.3.8 changelog as follows:

      
        ndb_restore -e restored excessively large
        values to the ndb_apply_status table's
        epoch column when restoring to a MySQL
        Cluster version supporting Micro-GCPs from an older version that
        did not support these.        
      
      
      
        A workaround when restoring to MCCGE releases
        supporting micro-GCPs previous to MySQL 5.1.23-ndb-6.3.8 is to
        perform a 32-bit shift on the epoch column
        values to reduce them to their proper size.
[2 Feb 2008 11:53] Jon Stephens
Also documented for 5.1.23-ndb-6.2.11.
[20 Feb 2008 16:03] Bugs System
Pushed into 6.0.5-alpha

Portions of this website are copyright © 2001, 2002 The PHP Group

Page generated in 0.054 sec. using MySQL 8.4.7-u6-cloud

Timestamp references displayed by the system are UTC.
Content reproduced on this site is the property of the respective copyright holders.
It is not reviewed in advance by Oracle and does not necessarily represent the opinion of Oracle or any other party.