Changes in MySQL NDB Cluster 7.5.1 (5.7.11-ndb-7.5.1) (2016-03-18, Development Milestone)

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 the 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)).

• Functionality Added or Changed

• Bugs Fixed

Functionality Added or Changed

• Important Change: When creating or adding columns to NDB tables, the default value used for both the COLUMN_FORMAT and ROW_FORMAT options is now DYNAMIC rather than FIXED.

  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 TABLE statement 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 TRUE).

  A new MySQL server option --ndb-default-column-format is added for backwards compatibility; set this to FIXED to force the old defaults to be used for COLUMN_FORMAT and ROW_FORMAT.

  Note

  This behavior change is superseded in MySQL NDB Cluster 7.5.4.

  (WL #8573)

• Scans have been improved by replacing the DIH_SCAN_GET_NODES_REQ signal, formerly used for communication between the DBTC and DBDIH kernel blocks in NDB, with the DIGETNODESREQ signal, which supports direct execution and allows for the elimination of DIH_SCAN_GET_NODES_REF and DIH_SCAN_GET_NODES_CONF, as well as for DIH_SCAN_TAB_REQ and DIH_SCAN_TAB_COMPLETE_REP signals to 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 BACKUP kernel 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 apply_epoch and latest_epoch fields have been renamed to latest_consumed_epoch and latest_buffered_epoch, respectively. The ID of the Ndb object serving as the source of the report is now shown, as is the reason for making the report (as the report_reason field).

  • 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_EventBufferStatus2 event type to handle the additional information provided by the new event buffer reporting. The NDB_LE_EventBufferStatus event type used in older versions of MySQL NDB Cluster is now deprecated, and will eventually be removed.

  For more information, see Event Buffer Reporting in the Cluster Log, as well as The ndb_logevent Structure. (WL #8626)

Bugs Fixed

• Important Change: The minimum value for the BackupDataBufferSize data 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_COUNT option 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-indexes and 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)

• NdbDictionary metadata 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 NdbDictionary timeouts 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_ACK signals 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 SUMA buffers 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 ACK signal 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 SchedulerSpinTimer parameter and to setting spintime as part of a ThreadConfig parameter value. (Bug #80237, Bug #22647476)

• A logic error in an if statement in storage/ndb/src/kernel/blocks/dbacc/DbaccMain.cpp rendered useless a check for determining whether ZREAD_ERROR should be returned when comparing operations. This was detected when compiling with gcc using -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)

• When using CREATE INDEX to add an index on either of two NDB tables 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 TABLE to perform the same index creation operation; and subsequent analysis revealed unintended differences in the way such operations were performed by CREATE INDEX.

  To fix this problem, we now make sure that operations performed by a CREATE INDEX statement are always handled internally in the same way and at the same time that the same operations are handled when performed by ALTER TABLE or DROP INDEX. (Bug #79156, Bug #22173891)

• The PortNumber SCI, 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 PortNumber management node configuration parameter, whose behavior remains unaltered. (Bug #77405, Bug #21280456)