Changes in MySQL NDB Cluster 7.6.14 (5.7.30-ndb-7.6.14) (2020-04-28, General Availability)

• Functionality Added or Changed

• Bugs Fixed

Functionality Added or Changed

• 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 BACKUP in ndb_mgm and restoring them with ndb_restore, using the --remap-column option implemented in this release (along with --restore-data and possibly other options). --remap-column can 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 db.tbl.col:fn:args, 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's type must be one of INT or BIGINT, and can optionally be UNSIGNED.

  • fn: Function name; currently, the only supported name is offset.

  • 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-column for 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:

  • --auto-inc (short form -a): Includes the next auto-increment value in the output, if the table has an AUTO_INCREMENT column.

  • --context (short form -x): Provides extra information about the table, including the schema, database name, table name, and internal ID.

  These options may be useful for obtaining information about NDB tables when planning a merge, particularly in situations where the mysql client may not be readily available.

  For more information, see the descriptions for --remap-column, --auto-inc, and --context. (Bug #30383950, WL #11796)

• ndb_restore now supports different primary key definitions for source and target tables when restoring from an NDB native backup, using the --allow-pk-changes option 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 TABLE statements 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-updates option 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.

  For more information, see the description of the --allow-pk-changes option in the documentation for ndb_restore. (Bug #26435136, Bug #30383947, Bug #30634010, WL #10730)

• Added the --ndb-log-fail-terminate option for mysqld. When used, this causes the SQL node to terminate if it is unable to log all row events. (Bug #21911930)

  References: See also: Bug #30383919.

Bugs Fixed

• 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 nnn failed log messages (on the order of 15,000 messages per second). (Bug #30293495)

• For NDB tables having no explicit primary key, NdbReceiverBuffer could be allocated with too small a size. This was due to the fact that the attribute bitmap sent to NDB from 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)