Bug #51432 hashmap restore causes crash when endian changes
| Submitted: | 23 Feb 2010 21:04 | Modified: | 15 Mar 2010 14:35 |
|---|---|---|---|
| Reporter: | Andrew Hutchings | Email Updates: | |
| Status: | Closed | Impact on me: | |
| Category: | MySQL Cluster: Cluster (NDB) storage engine | Severity: | S2 (Serious) |
| Version: | 7.0 | OS: | Any |
| Assigned to: | Jonas Oreland | CPU Architecture: | Any |
[23 Feb 2010 21:42]
Andrew Hutchings
This is an endianess problem SPARC -> x86
[5 Mar 2010 13:20]
Jonas Oreland
proposed patch (untested)
Attachment: bug51432.patch (application/octet-stream, text), 817 bytes.
[5 Mar 2010 13:35]
Jonas Oreland
found ctl file at issue, uploading new (tested) patch
[5 Mar 2010 13:36]
Jonas Oreland
new patch this time tested
Attachment: bug51432.patch.v2 (application/octet-stream, text), 821 bytes.
[15 Mar 2010 13:19]
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/103234 3449 Jonas Oreland 2010-03-15 ndb - bug#51432 - handle hashmap wrt endian in backup/restore
[15 Mar 2010 13:22]
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/103237 3450 Jonas Oreland 2010-03-15 ndb - bug#51432 again, took wrong version of patch
[15 Mar 2010 13:26]
Jonas Oreland
pushed to 7.0.14 and 7.1.3
[15 Mar 2010 14:35]
Jon Stephens
Documented bugfix in the NDB-7.0.14 and 7.1.3 changelogs as follows:
Restoring a MySQL Cluster backup between platforms having
different endianness failed when also restoring metadata and the
backup contained a hashmap not already present in the database
being restored to. This issue was discovered when trying to
restore a backup made on Solaris/SPARC to a MySQL Cluster
running on Solaris/x86, but could conceivably occur in other
cases where the endianness of the platform on which the backup
was taken differed from that of the platform being restored to.
Closed.
Portions of this website are copyright © 2001, 2002 The PHP Group
Page generated in 0.066 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.
Description: Restoring DEFAULT-HASHMAP-240-16 causes cluster failure or error: Breakpoint 1, BackupRestore::object (this=0x942860, type=24, ptr=0xaeba30) at restore/consumer_restore.cpp:719 719 if (ret == 0) (gdb) print ret $1 = -1 (gdb) print dict->getNdbError() $2 = (const NdbError &) @0xcc8618: {status = TemporaryError, classification = InternalTemporary, code = 787, mysql_code = -1, message = 0x5b274b "Schema transaction aborted", details = 0x0} (gdb) print old.getName() $4 = 0xcc9300 "DEFAULT-HASHMAP-240-16" (gdb) print old.m_impl $11 = ( NdbHashMapImpl &) @0xbe1040: {<NdbDictionary::HashMap> = {<NdbDictionary::Object> = {_vptr.Object = 0x82cdf0}, m_impl = @0xbe1040}, <NdbDictObjectImpl> = { m_id = 26, m_version = 1, m_type = HashMap, m_status = New}, m_name = { m_chr = 0xcc9300 "DEFAULT-HASHMAP-240-16", m_len = 22}, m_map = { m_items = 0xce4470, m_size = 240, m_incSize = 50, m_arraySize = 260}, m_facade = 0x7fffffff9880} (gdb) print old.getMapLen() $13 = 240 (gdb) print old.getObjectId() $14 = 26 (gdb) print old.getObjectVersion() $15 = 1 (gdb) print old.getObjectStatus() $16 = New perror --ndb 787 NDB error code 787: Schema transaction aborted: Temporary error: Internal temporary Second restore causes cluster failure. How to repeat: .