MySQL NDB Cluster 7.6.2 is a new release of NDB 7.6, based on
MySQL Server 5.7 and including features in version 7.6 of the
NDB storage engine, as well as fixing
recently discovered bugs in previous NDB Cluster releases.
Obtaining NDB Cluster 7.6. NDB Cluster 7.6 source code and binaries can be obtained from https://dev.mysql.com/downloads/cluster/.
For an overview of changes made in NDB Cluster 7.6, see What is New in NDB Cluster 7.6.
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.18 (see Changes in MySQL 5.7.18 (2017-04-10, General Availability)).
Incompatible Change; NDB Disk Data: Due to changes in disk file formats, it is necessary to perform an
--initialrestart of each data node when upgrading to or downgrading from this release.
Important Change: As part of an ongoing effort to simplify NDB Cluster configuration, memory for indexes is now allocated dynamically from
IndexMemoryconfiguration parameter is now deprecated, and is subject to removal in a future NDB version. Any memory which has been set for
config.inifile is now automatically added to
DataMemory. In addition, the default value for
DataMemoryhas been increased to 98M, and the default for
IndexMemoryhas been decreased to 0.
In addition to simplifying configuration of
NDB, a further benefit of these changes is that scaling up by increasing the number of LDM threads is no longer limited by having set an insufficiently large value for
IndexMemory. Previously, it was sometimes the case that increasing the number of LDM threads could lead to index memory exhaustion while large amounts of
Because instances of the
DBACCkernel block (responsible for hash index storage) now share memory with each one another as well as with
DBLQH(the kernel block that acts as the local data manager), they can take advantage of the fact that scaling up does not increase
DataMemoryusage greatly, and make use of spare memory for indexes freely. (For more information about these kernel blocks, see The DBACC Block, and The DBLQH Block.) In other words, index memory is no longer a static quantity allocated to each DBACC instance only once, on startup of the cluster, but rather this resource can now be allocated and deallocated whenever conditions require it.
Related changes which have been made as part of this work are listed here:
Several instances of
DataMemoryusage not related to storage of table data now use transaction memory instead.
For this reason, it may be necessary on some systems to increase
SharedGlobalMemory. In addition, systems performing initial bulk loads of data using large transactions may need to break up large transactions into smaller ones.
Data nodes now generate
MemoryUsageevents (see NDB Cluster Log Events) and write appropriate messages in the cluster log when resource usage reaches 99%, in addition to when it reaches 80%, 90%, or 100% as they did previously.
REPORT MEMORYUSAGEand other commands which expose memory consumption now shows index memory consumption using a page size of 32K rather than 8K.
IndexMemoryis no longer one of the values displayed in the
ndbinfo.resourcestable now shows the
RESERVEDresource has been removed.
IndexMemoryis no longer displayed in ndb_config output.
(WL #9835, WL #10196)
Performance: A number of debugging statements and printouts in the sources for the
DBLQHkernel blocks, as well as in related code, were moved into debugging code or removed altogether. This is expected to result in an improvement of up to 10% in the performance of local data management and transaction coordinator threads in many common use cases. (WL #10188)
NDB Cluster APIs; ndbinfo Information Database: Added two tables to the
ndbinfoinformation database. The
config_nodestable provides information about nodes that are configured as part of a given NDB Cluster, such as node ID and process type. The
processestable shows information about nodes currently connected to the cluster; this information includes the process name and system process ID, and service address. For each data node and SQL node, it also shows the process ID of the node's angel process.
As part of the work done to implement the
processestable, a new
set_service_uri()method has been added to the NDB API.
NDB Cluster APIs: The system name of an NDB cluster is now visible in the mysql client as the value of the
Ndb_system_namestatus variable, and can also be obtained by NDB API application using the
Ndb_cluster_connection::get_system_name()method. The system name can be set using the
Nameparameter in the
[system]section of the cluster configuration file. (WL #10321)
--query-alloption to ndb_config. This option acts much like the
--queryoption except that
-a) dumps configuration information for all attributes at one time. (Bug #60095, Bug #11766869)
Previously, when one LDM thread experienced I/O lag, such as during a disk overload condition, it wrote to a local checkpoint more slowly—that is, it wrote in I/O lag mode. However, other LDM threads did not necessarily observe or conform to this state. To ensure that write speed for the LCP is reduced by all LDM threads when such a slowdown is encountered,
NDBnow tracks I/O lag mode globally, so that I/O lag state is reported as soon as at least one thread is writing in I/O lag mode, and thus all LDM threads are forced to write in lag mode while the lag condition persists. This reduction in write speed by other LDM instances should increase overall capacity, enabling the disk overload condition to be overcome more quickly in such cases than before. (WL #10174)
Added the ndb_import tool to facilitate the loading of CSV-formatted data, such as that produced by
SELECT INTO OUTFILE, into an
NDBtable. ndb_import is intended to function much like mysqlimport or the
LOAD DATASQL statement, and supports many similar options for formatting of the data file. A connection to an
NDBmanagement server (ndb_mgmd) is required; there must be an otherwise unused
[api]slot in the cluster's
config.inifile for this purpose. In addition, the target database and table (created using the
NDBstorage engine) must already exist, and the name of the CSV file (less any file extension) must be the same as that of the target table. A running SQL node is needed for creating the target database and table, but is not required for ndb_import to function.
For more information, see ndb_import — Import CSV Data Into NDB. (WL #7614, WL #8862, WL #10653)
This was due to the fact that, when processing an
EXPLAINstatement, mysqld calculates the partition ID for a hash value as (
), which is correct only when the table is partitioned by
HASH, since other partitioning types use different methods of mapping hash values to partition IDs. This fix replaces the partition ID calculation performed by mysqld with an internal
NDBfunction which calculates the partition ID correctly, based on the table's partitioning type. (Bug #21068548)
References: See also: Bug #25501895, Bug #14672885.
Microsoft Windows: When collecting information about CPUs on Windows, the Auto-Installer counted only physical cores, unlike on other platforms, where it collects information about both physical and virtual cores. Now the CPU information obtained on Windows is the same as that provided on other platforms. (Bug #85209, Bug #25636423)
ndbmemcachewas not built correctly on Solaris platforms when compiling NDB Cluster using Developer Studio. (Bug #85477, Bug #25730703)
Solaris; MySQL NDB ClusterJ: ClusterJ was not built correctly on Solaris platforms when compiling NDB Cluster using Oracle Developer Studio. (Bug #25738510)
Solaris: The minimum required version of Solaris is now Solaris 11 update 3, due to a dependency on system runtime libraries.
Solaris: On Solaris, MySQL is now built with Developer Studio 12.5 instead of gcc. The binaries require the Developer Studio C/C++ runtime libraries to be installed. See here for how to install only the libraries:
NDB Disk Data: In some cases, setting dynamic in-memory columns of an NDB Disk Data table to
NULLwas not handled correctly. (Bug #79253, Bug #22195588)
NDB Replication: Execution of
CREATE TABLEcould in some cases cause the replication slave SQL thread to hang. (Bug #85015, Bug #25654833)
References: This issue is a regression of: Bug #83676, Bug #25042101.
ndb_report_thresh_binlog_epoch_slipwas enabled, an event buffer status message with
report_reason=LOW/ENOUGH_FREE_EVENTBUFFERwas printed in the logs when event buffer usage was high and then decreased to a lower level. This calculation was based on total allocated event buffer memory rather than the limit set by
ndb_eventbuffer_max_alloc; it was also printed even when the event buffer had unlimited memory (
ndb_eventbuffer_max_alloc= 0, the default), which could confuse users.
This is fixed as follows:
The calculation of
ndb_eventbuffer_free_percentis now based on
ndb_eventbuffer_max_alloc, rather than the amount actually allocated.
ndb_eventbuffer_free_percentis set and
ndb_eventbuffer_max_allocis equal to 0, event buffer status messages using
report_reason=LOW/ENOUGH_FREE_EVENTBUFFERare no longer printed.
ndb_report_thresh_binlog_epoch_slipis set, an event buffer status message showing
report_reason=BUFFERED_EPOCHS_OVER_THRESHOLDis written each 10 seconds (rather than every second) whenever this is greater than the threshold.
A bulk update is executed by reading records and executing a transaction on the set of records, which is started while reading them. When transaction initialization failed, the transaction executor function was subsequently unaware that this had occurred, leading to SQL node failures. This issue is fixed by providing appropriate error handling when attempting to initialize the transaction. (Bug #25476474)
References: See also: Bug #20092754.
CPU usage of the data node's main thread by the
DBDIHmaster block as the end of a local checkpoint could approach 100% in certain cases where the database had a very large number of fragment replicas. This is fixed by reducing the frequency and range of fragment queue checking during an LCP. (Bug #25443080)
Execution of an online
ALTER TABLE ... REORGANIZE PARTITIONstatement on an
NDBtable having a primary key whose length was greater than 80 bytes led to restarting of data nodes, causing the reorganization to fail. (Bug #25152165)
Multiple data node failures during a partial restart of the cluster could cause API nodes to fail. This was due to expansion of an internal object ID map by one thread, thus changing its location in memory, while another thread was still accessing the old location, leading to a segmentation fault in the latter thread.
unmap()functions in which this issue arose have now been made thread-safe. (Bug #25092498)
References: See also: Bug #25306089.
The planned shutdown of an NDB Cluster having more than 10 data nodes was not always performed gracefully. (Bug #20607730)
TRANS_AIsignals that used the long signal format were not handled by the
DBTCkernel block. (Bug #85606, Bug #25777337)
References: See also: Bug #85519, Bug #27540805.
Iproved pushed join handling by eliminating unneeded
FLUSH_AIattributes that passed an empty row to the
DBSPJkernel block, when a row should be passed to the SPJ API only; this reduces the set of
AttrInfoprojections that must be executed in order to produce the result. This also makes it possible to employ packed
TRANSID_AIsignals when delivering SPJ API results, which is more efficient. (Bug #85525, Bug #25741170)
References: See also: Bug #85545, Bug #25750355.
Use of the long signal format (introduced in NDB 6.4) for an incoming
TRANSID_AImessage is supported by the
DBUTILNDB kernel blocks, but the
DBTUPblock produced long signals only when sending to
DBUTIL, and otherwise sent a series of short signals instead. Now
DBTUPuses long signals for such messages whenever the receiving block supports this optimization. (Bug #85519, Bug #25740805)
To prevent a scan from returning more rows, bytes, or both than the client has reserved buffers for, the
DBTUPkernel block reports the size of the
TRANSID_AIit has sent to the client in the
TUPKEYCONFsignal it sends to the requesting
DBLQHis aware of the maximum batch size available for the result set, and terminates the scan batch if this has been exceeded.
DBTUPto produce two
TRANSID_AIresults from the same row, one for the client, and one for
DBSPJ, which is needed for key lookups on the joined tables. The size of both of these were added to the read length reported by the
DBTUPblock, which caused the controlling
DBLQHblock to believe that it had consumed more of the available maximum batch size than was actually the case, leading to premature termination of the scan batch which could have a negative impact on performance of SPJ scans. To correct this, only the actual read length part of an API request is now reported in such cases. (Bug #85408, Bug #25702850)
Data node binaries for Solaris 11 built using Oracle Developer Studio 12.5 on SPARC platforms failed with bus errors. (Bug #85390, Bug #25695818)
During the initial phase of a scan request, the
DBTCkernel block sends a series of
DIGETNODESREQsignals to the
DBDIHblock in order to obtain dictionary information for each fragment to be scanned. If
DIGETNODESREF, the error code from that signal was not read, and Error 218 Out of LongMessageBuffer was always returned instead. Now in such cases, the error code from the DIGETNODESREF signal is actually used. (Bug #85225, Bug #25642405)
If the user attempts to invoke ndb_setup.py while the Auto-Installer is still running—for example, after closing the terminal in which it was started and later opening a new terminal and invoking it in the new one—the program fails with the error Web server already running, which is expected behavior. In such cases, the
mcc.pidfile must first be removed prior to restarting the Auto-Installer (also expected behavior). Now when the program fails for this reason, the location of
mcc.pidis included in the error message to simplify this task. (Bug #85169, Bug #25611093)
The planned shutdown of a data node after one or more data nodes in the same node group had failed was not always performed correctly. (Bug #85168, Bug #25610703)
There existed the possibility of a race condition between schema operations on the same database object originating from different SQL nodes; this could occur when one of the SQL nodes was late in releasing its metadata lock on the affected schema object or objects in such a fashion as to appear to the schema distribution coordinator that the lock release was acknowledged for the wrong schema change. This could result in incorrect application of the schema changes on some or all of the SQL nodes or a timeout with repeated waiting max
###sec for distributing... messages in the node logs due to failure of the distribution protocol. (Bug #85010, Bug #25557263)
References: See also: Bug #24926009.
When a foreign key was added to or dropped from an NDB table using an
ALTER TABLEstatement, the parent table's metadata was not updated, which made it possible to execute invalid alter operations on the parent afterwards.
Until you can upgrade to this release, you can work around this problem by running
SHOW CREATE TABLEon the parent immediately after adding or dropping the foreign key; this statement causes the table's metadata to be reloaded. (Bug #82989, Bug #24666177)
NDBtables with cascading foreign keys returned inconsistent results when the query cache was also enabled, due to the fact that mysqld was not aware of child table updates. This meant that results for a later
SELECTfrom the child table were fetched from the query cache, which at that point contained stale data.
This is fixed in such cases by adding all children of the parent table to an internal list to be checked by
NDBfor updates whenever the parent is updated, so that mysqld is now properly informed of any updated child tables that should be invalidated from the query cache. (Bug #81776, Bug #23553507)