Incompatible Change; NDB Disk Data: Due to changes in disk file formats, it is necessary to perform an --initial restart 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 DataMemory; the IndexMemory configuration parameter is now deprecated, and is subject to removal in a future NDB version. Any memory which has been set for IndexMemory in the config.ini file is now automatically added to DataMemory. In addition, the default value for DataMemory has been increased to 98M, and the default for IndexMemory has 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 DataMemory remained available.

Because instances of the DBACC kernel 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 DataMemory usage 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:

(WL #9835, WL #10196)

Performance: A number of debugging statements and printouts in the sources for the DBTC and DBLQH kernel 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 ndbinfo information database. The config_nodes table provides information about nodes that are configured as part of a given NDB Cluster, such as node ID and process type. The processes table 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 processes table, a new set_service_uri() method has been added to the NDB API.

For more information, see The ndbinfo config_nodes Table, and The ndbinfo processes Table, as well as Ndb_cluster_connection::set_service_uri(). (WL #9819, WL #10147)

NDB Cluster APIs: The system name of an NDB cluster is now visible in the mysql client as the value of the Ndb_system_name status 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 Name parameter in the [system] section of the cluster configuration file. (WL #10321)

Added the --query-all option to ndb_config. This option acts much like the --query option except that --query-all (short form: -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, NDB now 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 NDB table. ndb_import is intended to function much like mysqlimport or the LOAD DATA SQL statement, and supports many similar options for formatting of the data file. A connection to an NDB management server (ndb_mgmd) is required; there must be an otherwise unused [api] slot in the cluster's config.ini file for this purpose. In addition, the target database and table (created using the NDB storage 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)

Partitioning: The output of EXPLAIN PARTITIONS displayed incorrect values in the partitions column when run on an explicitly partitioned NDB table having a large number of partitions.

This was due to the fact that, when processing an EXPLAIN statement, mysqld calculates the partition ID for a hash value as (hash_value % number_of_partitions), 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 NDB function 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)

Solaris; ndbmemcache: ndbmemcache was 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)

NDB Disk Data: In some cases, setting dynamic in-memory columns of an NDB Disk Data table to NULL was not handled correctly. (Bug #79253, Bug #22195588)

When ndb_report_thresh_binlog_epoch_slip was enabled, an event buffer status message with report_reason=LOW/ENOUGH_FREE_EVENTBUFFER was 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:

(Bug #25726723)

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 DBDIH master 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 PARTITION statement on an NDB table 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.

The internal map() and 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)

Dropped TRANS_AI signals that used the long signal format were not handled by the DBTC kernel block. (Bug #85606, Bug #25777337)

References: See also: Bug #85519, Bug #27540805.

Iproved pushed join handling by eliminating unneeded FLUSH_AI attributes that passed an empty row to the DBSPJ kernel block, when a row should be passed to the SPJ API only; this reduces the set of AttrInfo projections that must be executed in order to produce the result. This also makes it possible to employ packed TRANSID_AI signals 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_AI message is supported by the BACKUP, DBTC, DBLQH, SUMA, DBSPJ, and DBUTIL NDB kernel blocks, but the DBTUP block produced long signals only when sending to DPSPJ or DBUTIL, and otherwise sent a series of short signals instead. Now DBTUP uses 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 DBTUP kernel block reports the size of the TRANSID_AI it has sent to the client in the TUPKEYCONF signal it sends to the requesting DBLQH block. DBLQH is aware of the maximum batch size available for the result set, and terminates the scan batch if this has been exceeded.

The DBSPJ block's FLUSH_AI attribute allows DBTUP to produce two TRANSID_AI results 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 DBTUP block, which caused the controlling DBLQH block 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 DBTC kernel block sends a series of DIGETNODESREQ signals to the DBDIH block in order to obtain dictionary information for each fragment to be scanned. If DBDIH returned 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.pid file 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.pid is 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 TABLE statement, 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 TABLE on the parent immediately after adding or dropping the foreign key; this statement causes the table's metadata to be reloaded. (Bug #82989, Bug #24666177)

Transactions on NDB tables 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 SELECT from 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 NDB for 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)