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