Documentation Home
MySQL NDB Cluster 7.3 Release Notes
Download these Release Notes
PDF (US Ltr) - 0.9Mb
PDF (A4) - 0.9Mb

MySQL NDB Cluster 7.3 Release Notes  /  Changes in MySQL NDB Cluster 7.3.11 (5.6.27-ndb-7.3.11) (2015-10-19, General Availability)

Changes in MySQL NDB Cluster 7.3.11 (5.6.27-ndb-7.3.11) (2015-10-19, General Availability)

MySQL NDB Cluster 7.3.11 is a new release of NDB Cluster, based on MySQL Server 5.6 and including features from version 7.3 of the NDB storage engine, as well as fixing a number of recently discovered bugs in previous NDB Cluster releases.

Obtaining MySQL NDB Cluster 7.3.  MySQL NDB Cluster 7.3 source code and binaries can be obtained from

For an overview of changes made in MySQL NDB Cluster 7.3, see What is New in NDB Cluster 7.3.

This release also incorporates all bug fixes and changes made in previous NDB Cluster releases, as well as all bug fixes and feature changes which were added in mainline MySQL 5.6 through MySQL 5.6.27 (see Changes in MySQL 5.6.27 (2015-09-30, General Availability)).

Functionality Added or Changed

  • Important Change; NDB Replication: Added the create_old_temporals server system variable to complement the system variables avoid_temporal_upgrade and show_old_temporals introduced in MySQL 5.6.24 and available in MySQL NDB Cluster beginning with NDB 7.3.9 and NDB 7.4.6. Enabling create_old_temporals causes mysqld to use the storage format employed prior to MySQL 5.6.4 when creating any DATE, DATETIME, or TIMESTAMP column—that is, the column is created without any support for fractional seconds. create_old_temporals is disabled by default. The system variable is read-only; to enable the use of pre-5.6.4 temporal types, set the equivalent option (--create-old-temporals) on the command line, or in an option file read by the MySQL server.

    create_old_temporals is available only in MySQL NDB Cluster; it is not supported in the standard MySQL 5.6 server. It is intended to facilitate upgrades from MySQL NDB Cluster 7.2 to MySQL NDB Cluster 7.3 and 7.4, after which table columns of the affected types can be upgraded to the new storage format. create_old_temporals is deprecated and scheduled for removal in a future MySQL NDB Cluster version.

    avoid_temporal_upgrade must also be enabled for this feature to work properly. You should also enable show_old_temporals as well. For more information, see the descriptions of these variables. For more about the changes in MySQL's temporal types, see Date and Time Type Storage Requirements. (Bug #20701918)

    References: See also: Bug #21492598, Bug #72997, Bug #18985760.

Bugs Fixed

  • Important Change: When ndb_restore was run without --disable-indexes or --rebuild-indexes on a table having a unique index, it was possible for rows to be restored in an order that resulted in duplicate values, causing it to fail with duplicate key errors. Running ndb_restore on such a table now requires using at least one of these options; failing to do so now results in an error. (Bug #57782, Bug #11764893)

    References: See also: Bug #22329365, Bug #22345748.

  • NDB Cluster APIs: While executing dropEvent(), if the coordinator DBDICT failed after the subscription manager (SUMA block) had removed all subscriptions but before the coordinator had deleted the event from the system table, the dropped event remained in the table, causing any subsequent drop or create event with the same name to fail with NDB error 1419 Subscription already dropped or error 746 Event name already exists. This occurred even when calling dropEvent() with a nonzero force argument.

    Now in such cases, error 1419 is ignored, and DBDICT deletes the event from the table. (Bug #21554676)

  • NDB Cluster APIs: The internal value representing the latest global checkpoint was not always updated when a completed epoch of event buffers was inserted into the event queue. This caused subsequent calls to Ndb::pollEvents() and pollEvents2() to fail when trying to obtain the correct GCI for the events available in the event buffers. This could also result in later calls to nextEvent() or nextEvent2() seeing events that had not yet been discovered. (Bug #78129, Bug #21651536)

  • Backup block states were reported incorrectly during backups. (Bug #21360188)

    References: See also: Bug #20204854, Bug #21372136.

  • When a data node is known to have been alive by other nodes in the cluster at a given global checkpoint, but its sysfile reports a lower GCI, the higher GCI is used to determine which global checkpoint the data node can recreate. This caused problems when the data node being started had a clean file system (GCI = 0), or when it was more than more global checkpoint behind the other nodes.

    Now in such cases a higher GCI known by other nodes is used only when it is at most one GCI ahead. (Bug #19633824)

    References: See also: Bug #20334650, Bug #21899993. This issue is a regression of: Bug #29167.

  • When restoring a specific database or databases with the --include-databases or --exclude-databases option, ndb_restore attempted to apply foreign keys on tables in databases which were not among those being restored. (Bug #18560951)

  • After restoring the database schema from backup using ndb_restore, auto-discovery of restored tables in transactions having multiple statements did not work correctly, resulting in Deadlock found when trying to get lock; try restarting transaction errors.

    This issue was encountered both in the mysql client, as well as when such transactions were executed by application programs using Connector/J and possibly other MySQL APIs.

    Prior to upgrading, this issue can be worked around by executing SELECT TABLE_NAME, TABLE_SCHEMA FROM INFORMATION_SCHEMA.TABLES WHERE ENGINE = 'NDBCLUSTER' on all SQL nodes following the restore operation, before executing any other statements. (Bug #18075170)

  • ndb_desc used with the --extra-partition-info and --blob-info options failed when run against a table containing one or more TINYBLOB. columns. (Bug #14695968)

  • Trying to create an NDB table with a composite foreign key referencing a composite primary key of the parent table failed when one of the columns in the composite foreign key was the table's primary key and in addition this column also had a unique key. (Bug #78150, Bug #21664899)

  • When attempting to enable index statistics, creation of the required system tables, events and event subscriptions often fails when multiple mysqld processes using index statistics are started concurrently in conjunction with starting, restarting, or stopping the cluster, or with node failure handling. This is normally recoverable, since the affected mysqld process or processes can (and do) retry these operations shortly thereafter. For this reason, such failures are no longer logged as warnings, but merely as informational events. (Bug #77760, Bug #21462846)

  • Adding a unique key to an NDB table failed when the table already had a foreign key. Prior to upgrading, you can work around this issue by creating the unique key first, then adding the foreign key afterwards, using a separate ALTER TABLE statement. (Bug #77457, Bug #20309828)