MySQL NDB Cluster 7.5.1 is a new release of MySQL NDB Cluster 7.5,
based on MySQL Server 5.7 and including features in version 7.5 of
NDB storage engine, as well as
fixing recently discovered bugs in previous NDB Cluster releases.
Obtaining MySQL NDB Cluster 7.5. MySQL NDB Cluster 7.5 source code and binaries can be obtained from https://dev.mysql.com/downloads/cluster/.
For an overview of changes made in MySQL NDB Cluster 7.5, see What is New in NDB Cluster 7.5.
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.7 through MySQL 5.7.11 (see Changes in MySQL 5.7.11 (2016-02-05, General Availability)).
Important Change: When creating or adding columns to
NDBtables, the default value used for both the
ROW_FORMAToptions is now
This change does not affect the row format or column format used by existing tables. New columns added to such tables use the new defaults, and existing columns are changed to use these as well, provided that the
ALTER TABLEstatement in question uses
ALGORITHM=COPY. Note that this cannot be done implicitly if mysqld is run with
--ndb-allow-copying-alter-table=FALSE(the default is
A new MySQL server option
--ndb-default-column-formatis added for backwards compatibility; set this to
FIXEDto force the old defaults to be used for
This behavior change is superseded in MySQL NDB Cluster 7.5.4.
Scans have been improved by replacing the
DIH_SCAN_GET_NODES_REQsignal, formerly used for communication between the
DBDIHkernel blocks in
NDB, with the
DIGETNODESREQsignal, which supports direct execution and allows for the elimination of
DIH_SCAN_GET_NODES_CONF, as well as for
EXECUTE_DIRECT. This enables enable higher scalability of data nodes when used for scan operations by decreasing the use of CPU resources for scan operations by an estimated five percent in some cases. This should also improve response times, which could help prevent issues with overload of the main threads.
As part of these changes, scans made in the
BACKUPkernel block have also been improved and made more efficient. (WL #8937)
References: See also: Bug #80640, Bug #22884995.
The following improvements have been made to event buffer reporting in the cluster log:
Each report now identifies the API node that sent it.
The fields shown in the report have been improved and expanded. Percentages are now better specified and used only when appropriate. For improved clarity, the
latest_epochfields have been renamed to
latest_buffered_epoch, respectively. The ID of the
Ndbobject serving as the source of the report is now shown, as is the reason for making the report (as the
The frequency of unnecessary reporting has been reduced by limiting reports to those showing only significant changes in event buffer usage.
The MGM API adds a new
NDB_LE_EventBufferStatus2event type to handle the additional information provided by the new event buffer reporting. The
NDB_LE_EventBufferStatusevent type used in older versions of MySQL NDB Cluster is now deprecated, and will eventually be removed.
Important Change: The minimum value for the
BackupDataBufferSizedata node configuration parameter has been lowered from 2 MB to 512 KB. The default and maximum values for this parameter remain unchanged. (Bug #22749509)
OS X: Processing of local checkpoints was not handled correctly on Mac OS X, due to an uninitialized variable. (Bug #80236, Bug #22647462)
Microsoft Windows: Compilation of MySQL with Visual Studio 2015 failed in
ConfigInfo.cpp, due to a change in Visual Studio's handling of spaces and concatenation. (Bug #22558836, Bug #80024)
Microsoft Windows: When setting up event logging for ndb_mgmd on Windows, MySQL NDB Cluster tries to add a registry key to
HKEY_LOCAL_MACHINE, which fails if the user does not have access to the registry. In such cases ndb_mgmd logged the error Could neither create or open key, which is not accurate and which can cause confusion for users who may not realize that file logging is available and being used. Now in such cases, ndb_mgmd logs a warning Could not create or access the registry key needed for the application to log to the Windows EventLog. Run the application with sufficient privileges once to create the key, or add the key manually, or turn off logging for that application. An error (as opposed to a warning) is now reported in such cases only if there is no available output at all for ndb_mgmd event logging. (Bug #20960839)
Microsoft Windows: MySQL NDB Cluster did not compile correctly with Microsoft Visual Studio 2015, due to a change from previous versions in the VS implementation of the
_vsnprintf()function. (Bug #80276, Bug #22670525)
During node failure handling, the request structure used to drive the cleanup operation was not maintained correctly when the request was executed. This led to inconsistencies that were harmless during normal operation, but these could lead to assertion failures during node failure handling, with subsequent failure of additional nodes. (Bug #22643129)
The previous fix for a lack of mutex protection for the internal
TransporterFacade::deliver_signal()function was found to be incomplete in some cases. (Bug #22615274)
References: This issue is a regression of: Bug #77225, Bug #21185585.
When setup of the binary log as an atomic operation on one SQL node failed, this could trigger a state in other SQL nodes in which they appeared to detect the SQL node participating in schema change distribution, whereas it had not yet completed binary log setup. This could in turn cause a deadlock on the global metadata lock when the SQL node still retrying binary log setup needed this lock, while another mysqld had taken the lock for itself as part of a schema change operation. In such cases, the second SQL node waited for the first one to act on its schema distribution changes, which it was not yet able to do. (Bug #22494024)
For busy servers, client connection or communication failure could occur if an I/O-related system call was interrupted. The
mysql_options()C API function now has a
MYSQL_OPT_RETRY_COUNToption to control the number of retries for interrupted system calls. (Bug #22336527)
References: See also: Bug #22389653.
Duplicate key errors could occur when ndb_restore was run on a backup containing a unique index. This was due to the fact that, during restoration of data, the database can pass through one or more inconsistent states prior to completion, such an inconsistent state possibly having duplicate values for a column which has a unique index. (If the restoration of data is preceded by a run with
--disable-indexesand followed by one with
--rebuild-indexes, these errors are avoided.)
Added a check for unique indexes in the backup which is performed only when restoring data, and which does not process tables that have explicitly been excluded. For each unique index found, a warning is now printed. (Bug #22329365)
NdbDictionarymetadata operations had a hard-coded 7-day timeout, which proved to be excessive for short-lived operations such as retrieval of table definitions. This could lead to unnecessary hangs in user applications which were difficult to detect and handle correctly. To help address this issue, timeout behaviour is modified so that read-only or short-duration dictionary interactions have a 2-minute timeout, while schema transactions of potentially long duration retain the existing 7-day timeout.
Such timeouts are intended as a safety net: In the event of problems, these return control to users, who can then take corrective action. Any reproducible issue with
NdbDictionarytimeouts should be reported as a bug. (Bug #20368354)
Optimization of signal sending by buffering and sending them periodically, or when the buffer became full, could cause
SUB_GCP_COMPLETE_ACKsignals to be excessively delayed. Such signals are sent for each node and epoch, with a minimum interval of
TimeBetweenEpochs; if they are not received in time, the
SUMAbuffers can overflow as a result. The overflow caused API nodes to be disconnected, leading to current transactions being aborted due to node failure. This condition made it difficult for long transactions (such as altering a very large table), to be completed. Now in such cases, the
ACKsignal is sent without being delayed. (Bug #18753341)
When setting CPU spin time, the value was needlessly cast to a boolean internally, so that setting it to any nonzero value yielded an effective value of 1. This issue, as well as the fix for it, apply both to setting the
SchedulerSpinTimerparameter and to setting
spintimeas part of a
ThreadConfigparameter value. (Bug #80237, Bug #22647476)
A logic error in an
storage/ndb/src/kernel/blocks/dbacc/DbaccMain.cpprendered useless a check for determining whether
ZREAD_ERRORshould be returned when comparing operations. This was detected when compiling with
-Werror=logical-op. (Bug #80155, Bug #22601798)
References: This issue is a regression of: Bug #21285604.
Suppressed a CMake warning that was caused by use of an incorrectly quoted variable name. (Bug #80066, Bug #22572632)
CREATE INDEXto add an index on either of two
NDBtables sharing circular foreign keys, the query succeeded but a temporary table was left on disk, breaking the foreign key constraints. This issue was also observed when attempting to create an index on a table in the middle of a chain of foreign keys—that is, a table having both parent and child keys, but on different tables. The problem did not occur when using
ALTER TABLEto perform the same index creation operation; and subsequent analysis revealed unintended differences in the way such operations were performed by
To fix this problem, we now make sure that operations performed by a
CREATE INDEXstatement are always handled internally in the same way and at the same time that the same operations are handled when performed by
DROP INDEX. (Bug #79156, Bug #22173891)
PortNumberSCI, SHM, and TCP configuration parameters, which were deprecated in MySQL 5.1.3, have now been removed and are no longer accepted in configuration files.
This change does not affect the
PortNumbermanagement node configuration parameter, whose behavior remains unaltered. (Bug #77405, Bug #21280456)