It now possible to consolidate data from separate instances of NDB Cluster into a single target NDB Cluster when the original datasets all use the same schema. This is supported when using backups created using
START BACKUPin ndb_mgm and restoring them with ndb_restore, using the
--remap-columnoption implemented in this release (along with
--restore-dataand possibly other options).
--remap-columncan be employed to handle cases of overlapping primary, unique, or both sorts of key values between source clusters, and you need to make sure that they do not overlap in the target cluster. This can also be done to preserve other relationships between tables.
When used together with
--restore-data, the new option applies a function to the value of the indicated column. The value set for this option is a string of the format
, whose components are listed here:
db: Database name, after performing any renames.
tbl: Table name.
col: Name of the column to be updated. This column must use of one of the MySQL integer types (see Integer Types (Exact Value) - INTEGER, INT, SMALLINT, TINYINT, MEDIUMINT, BIGINT).
fn: Function name; currently, the only supported name is
args: The size of the offset to be added to the column value by
offset. The range of the argument is that of the signed variant of the column's type; thus, negative offsets are supported.
You can use
--remap-columnfor updating multiple columns of the same table and different columns of different tables, as well as combinations of multiple tables and columns. Different offset values can be employed for different columns of the same table.
As part of this work, two new options are also added to ndb_desc in this release:
ndb_restore now supports different primary key definitions for source and target tables when restoring from an
NDBnative backup, using the
--allow-pk-changesoption introduced in this release. Both increasing and decreasing the number of columns making up the original primary key are supported. This may be useful when it is necessary to accommodate schema version changes while restoring data, or when doing so is more efficient or less time-consuming than performing
ALTER TABLEstatements involving primary key changes on a great many tables following the restore operation.
When extending a primary key with additional columns, any columns added must not be nullable, and any values stored in any such columns must not change while the backup is being taken. Changes in the values of any such column while trying to add it to the table's primary key causes the restore operation to fail. Due to the fact that some applications set the values of all columns when updating a row even if the values of one or more of the columns does not change, it is possible to override this behavior by using the
--ignore-extended-pk-updatesoption which is also added in this release. If you do this, care must be taken to insure that such column values do not actually change.
When removing columns from the table's primary key, it is not necessary that the columns dropped from the primary key remain part of the table afterwards.
References: See also: Bug #30383919.
When restoring signed auto-increment columns, ndb_restore incorrectly handled negative values when determining the maximum value included in the data. (Bug #30928710)
When a node ID allocation request failed with NotMaster temporary errors, the node ID allocation was always retried immediately, without regard to the cause of the error. This caused a very high rate of retries, whose effects could be observed as an excessive number of Alloc node id for node
nnnfailed log messages (on the order of 15,000 messages per second). (Bug #30293495)
NDBtables having no explicit primary key,
NdbReceiverBuffercould be allocated with too small a size. This was due to the fact that the attribute bitmap sent to
NDBfrom the data nodes always includes the primary key. The extra space required for hidden primary keys is now taken into consideration in such cases. (Bug #30183466)