-
Frazer Clement authored
Most of patch originally from JD <john.duncan@oracle.com> Modify Ndb layers in 8.0+ to store and transfer longer opaque metadata in Ndb table definitions using a new key (MysqlDictMetadata) rather than changing the definition of the existing key (FrmData). This avoids breaking compatibility with existing Ndb versions which require that the FrmData keyed data is no longer than 6000 bytes to be able to parse a table definition. Being unable to parse a table definition affects cross version Backup and Restore, which is part of cross version Replication, as well as data node recovery code etc. Existing versions of Ndb will ignore any new key which they do not know, and so will ignore the longer metadata in any table definition they come across. This means that longer metadata will be discarded, but that the tables can still be opened and operated on from the Ndb level. As a result, tables should not be created/altered by a new version API until all data nodes are upgraded to support the new key, as their opaque metadata will be discarded by the old datanodes. Reviewed-by : Magnus Blaudd <magnus.blaudd@oracle.com>
Frazer Clement authoredMost of patch originally from JD <john.duncan@oracle.com> Modify Ndb layers in 8.0+ to store and transfer longer opaque metadata in Ndb table definitions using a new key (MysqlDictMetadata) rather than changing the definition of the existing key (FrmData). This avoids breaking compatibility with existing Ndb versions which require that the FrmData keyed data is no longer than 6000 bytes to be able to parse a table definition. Being unable to parse a table definition affects cross version Backup and Restore, which is part of cross version Replication, as well as data node recovery code etc. Existing versions of Ndb will ignore any new key which they do not know, and so will ignore the longer metadata in any table definition they come across. This means that longer metadata will be discarded, but that the tables can still be opened and operated on from the Ndb level. As a result, tables should not be created/altered by a new version API until all data nodes are upgraded to support the new key, as their opaque metadata will be discarded by the old datanodes. Reviewed-by : Magnus Blaudd <magnus.blaudd@oracle.com>
Loading