The following sections describe changes in the implementation of NDB Cluster in MySQL NDB Cluster 8.0 through 8.0.17, as compared to earlier release series. NDB Cluster 8.0 is currently available in a Developer Preview release. NDB Cluster 7.6 is available as a General Availability release, as is NDB Cluster 7.5 For information about additions and other changes in NDB Cluster 7.6, see What is New in NDB Cluster 7.5; for information about new features and other changes in NDB Cluster 7.5, see What is New in NDB Cluster 7.6.
NDB Cluster 7.4 and 7.3 are recent General Availability releases, and are still supported. NDB Cluster 7.2 is a previous GA release, still supported in production for existing deployments. NDB 7.1 and earlier releases series are no longer maintained or supported in production. We recommend that new deployments use NDB Cluster 7.6 or NDB Cluster 7.5. For information about NDB 7.4 and NDB 7.3, see MySQL NDB Cluster 7.3 and NDB Cluster 7.4. For information about NDB 7.2 and previous NDB releases, see MySQL NDB Cluster 7.2.
Major changes and new features in NDB Cluster 8.0 which are likely to be of interest are shown in the following list:
INFORMATION_SCHEMA changes. The following changes are made in the display of information about Disk Data files in the
Tablespaces and log file groups are no longer represented in the
FILEStable. (These constructs are not actually files.)
Each data file is now represented by a single row in the
FILEStable. Each undo log file is also now represented in this table by one row only. (Previously, a row was displayed for each copy of each of these files on each data node.)
For rows corresponding to data files or undo log files, node ID and undo log buffer information is no longer displayed in the
EXTRAcolumn of the
INFORMATION_SCHEMAtables now are populated with tablespace statistics for MySQL Cluster tables. (Bug #27167728)
Error information with ndb_perror. Removed the deprecated
--ndboption for perror. Use ndb_perror to obtain error message information from
NDBerror codes instead. (Bug #81704, Bug #81705, Bug #23523926, Bug #23523957)
Development in parallel with MySQL server. Beginning with this release, MySQL NDB Cluster is being developed in parallel with the standard MySQL 8.0 server under a new unified release model with the following features:
NDB 8.0 is developed in, built from, and released with the MySQL 8.0 source code tree.
The numbering scheme for NDB Cluster 8.0 releases follows the scheme for MySQL 8.0, starting with the current MySQL release (8.0.13).
Building the source with NDB support appends
-clusterto the version string returned by mysql
-V, as shown here:
shell≫ mysql -V mysql Ver 8.0.13-cluster for Linux on x86_64 (Source distribution)
NDB binaries continue to display both the MySQL Server version and the NDB engine version, like this:
shell> ndb_mgm -V MySQL distrib mysql-8.0.13 ndb-8.0.13-dmr, for Linux (x86_64)
In MySQL Cluster NDB 8.0, these two version numbers are always the same.
To build the MySQL 8.0.13 (or later) source with NDB Cluster support, use the CMake option
Offline multithreaded index builds. It is now possible to specify a set of cores to be used for I/O threads performing offline multithreaded builds of ordered indexes, as opposed to normal I/O duties such as file I/O， compression， or decompression. “Offline” in this context refers to building of ordered indexes performed when the parent table is not being written to; such building takes place when an
NDBcluster performs a node or system restart, or as part of restoring a cluster from backup using ndb_restore
In addition, the default behaviour for offline index build work is modified to use all cores available to ndbmtd, rather limiting itself to the core reserved for the I/O thread. Doing so can improve restart and restore times and performance, availability, and the user experience.
This enhancement is implemented as follows:
The default value for
BuildIndexThreadsis changed from 0 to 128. This means that offline ordered index builds are now multithreaded by default.
The default value for
TwoPassInitialNodeRestartCopyis changed from
true. This means that an initial node restart first copies all data from a “live” node to one that is starting—without creating any indexes—builds ordered indexes offline, and then again synchronizes its data with the live node, that is, synchronizing twice and building indexes offline between the two synchonizations. This causes an initial node restart to behave more like the normal restart of a node, and reduces the time required for building indexes.
A new thread type (
idxbld) is defined for the
ThreadConfigconfiguration parameter, to allow locking of offline index build threads to specific CPUs.
NDBnow distinguishes the thread types that are accessible to “ThreadConfig” by the following two criteria:
Whether the thread is an execution thread. Threads of types
sendare execution threads; thread types
Whether the allocation of the thread to a given task is permanent or temporary. Currently all thread types except
For additonal information, see the descriptions of the parameters in the Manual. (Bug #25835748, Bug #26928111)
logbuffers table backup process information. When performing an NDB backup, the
ndbinfo.logbufferstable now displays information regarding buffer usage by the backup process on each data node. This is implemented as rows reflecting two new log types in addition to
DD-UNDO. One of these rows has the log type
BACKUP-DATA, which shows the amount of data buffer used during backup to copy fragments to backup files. The other row has the log type
BACKUP-LOG, which displays the amount of log buffer used during the backup to record changes made after the backup has started. One each of these
log_typerows is shown in the
logbufferstable for each data node in the cluster. Rows having these two log types are present in the table only while an NDB backup is currently in progress. (Bug #25822988)
ODirectSyncFlag. Added the
ODirectSyncFlagconfiguration parameter for data nodes. When enabled, the data node treats all completed filesystem writes to the redo log as though they had been performed using
This parameter has no effect if at least one of the following conditions is true:
ODirectis not enabled.
InitFragmentLogFilesis set to
Data node log buffer size control. Added the
--logbuffer-sizeoption for ndbd and ndbmtd, for use in debugging with a large number of log messages. This controls the size of the data node log buffer; the default (32K) is intended for normal operations. (Bug #89679, Bug #27550943)
String hashing improvements. Prior to NDB 8.0, all string hashing was based on first transforming the string into a normalized form, then MD5-hashing the resulting binary image. This could give rise to some performance problems, for the following reasons:
The normalized string is always space padded to its full length. For a
VARCHAR, this often involved adding more spaces than there were characters in the original string.
The string libraries were not optimized for this space padding, and added considerable overhead in some use cases.
The padding semantics varied between character sets, some of which were not padded to their full length.
The transformed string could become quite large, even without space padding; some Unicode 9.0 collations can transform a single code point into 100 bytes of character data or more.
Subsequent MD5 hashing consisted mainly of padding with spaces, and was not particularly efficient, possibly causing additional performance penalties by flush significant portions of the L1 cache.
Collations provide their own hash functions, which hash the string directly without first creating a normalized string. In addition, for Unicode 9.0 collations, the hashes are computed without padding.
NDBnow takes advantage of this built-in function whenever hashing a string identified as using a Unicode 9.0 collation.
Since, for other collations there are existing databases which are hash partitioned on the transformed string,
NDBcontinues to employ the previous method for hashing strings that use these, to maintain compatibility. (Bug #89590, Bug #89604, Bug #89609, Bug #27515000, Bug #27523758, Bug #27522732)
On-the-fly upgrades of tables using .frm files. A table created in NDB 7.6 and earlier contains metadata in the form of a compressed
.frmfile, which is no longer supported in MySQL 8.0. To facilitate online upgrades to NDB 8.0,
NDBperforms on-the-fly translation of this metadata and writes it into the MySQL Server's data dictionary, which enables the mysqld in NDB Cluster 8.0 to work with the table without preventing subsequent use of the table by a previous version of the
Once a table's structure has been modified in NDB 8.0, its metadata is stored using the Data Dictionary, and it can no longer be accessed by NDB 7.6 and earlier.
This enhancement also makes it possible to restore an
NDBbackup made using an earlier version to a cluster running NDB 8.0 (or later).
Schema synchronization of tablespace objects. When a MySQL Server connects as an SQL node to an NDB cluster, it synchronizes its data dictionary with the information found in
Previously, the only
NDBobjects synchronized on connection of a new SQL node were databases and tables; MySQL NDB Cluster 8.0.14 and later also implement schema synchronization of disk data objects including tablespaces and log file groups. Among other benefits, this eliminates the possibility of a mismatch between the MySQL data dictionary and the
NDBdictionary following a native backup and restore, in which tablespaces and log file groups were restored to the
NDBdictionary, but not to the MySQL Server's data dictionary.
Handling of NO_AUTO_CREATE_USER in mysqld options file. An error now is written to the server log when the presence of the
NO_AUTO_CREATE_USERvalue for the
sql_modeoption in the options file prevents mysqld from starting.
Handling of references to nonexistent tablespaces. It is no longer possible to issue a
CREATE TABLEstatement that refers to a nonexistent tablespace. Such a statement now fails with an error.
RESET MASTER changes. Because the MySQL Server now executes
RESET MASTERwith a global read lock, the behavior of this statement when used with NDB Cluster has changed in the following two respects:
It is no longer guaranteed to be synonchrous; that is, it is now possible that a read coming immediately before
RESET MASTERis issued may not be logged until after the binary log has been rotated.
It now behaves identically, regardless of whether the statement is issued on the same SQL node that is writing the binary log, or on a different SQL node in the same cluster.
NDB table extra metadata changes. In NDB 8.0.14 and later, the extra metadata property of an
NDBtable is used for storing serialized metadata from the MySQL data dictionary rather than storing the binary representation of the table as in previous versions. (This was a
.frmfile, no longer used by the MySQL Server—see Chapter 14, MySQL Data Dictionary.) As part of the work to support this change, the available size of the table's extra metadata has been increased. This means that
NDBtables created in NDB Cluster 8.0.14 and later are not compatible with previous NDB Cluster releases. Tables created in previous releases can be used with NDB 8.0.14 and later, but cannot be opened afterwards by an earlier version.
For more information, see Section 22.2.8, “Upgrading and Downgrading NDB Cluster”.
Disk data file distribution. Beginning with NDB Cluster 8.0.14,
NDBuses the MySQL data dictionary to make sure that disk data files and related constructs such as tablespaces and log file groups are correctly distributed between all connected SQL nodes.
ndb_log_bin system variable. Beginning with NDB 8.0.16, the default value of the
ndb_log_binsystem variable has changed from
NDB metadata change detection. NDB 8.0.16 implements a new mechanism for detection of updates to metadata for data objects such as tables, tablespaces, and log file groups with the MySQL data dictionary. This is done using a thread, the
NDBmetadata change monitor thread, which runs in the background and checks periodically for inconsistencies between the
NDBdictionary and the MySQL data dictionary.
The monitor performs metadata checks every 60 seconds by default. The polling interval can be adjusted by setting the value of the
ndb_metadata_check_intervalsystem variable; polling can be disabled altogether by setting the
ndb_metadata_checksystem variable to OFF. A status variable,
Ndb_metadata_detected_countshows the number of times since mysqld was last started that inconsistencies have been detected.
NDB 7.x distributed privileges no longer supported. Most
NDBcode supporting distribution of privileges between MySQL servers connected to an NDB Cluster, as implemented in NDB 7.6 and earlier (see Distributed MySQL Privileges for NDB Cluster), has been removed. This is due to the fact that such privilege tables do not function correctly in NDB 8.0, and is the result of changes to the MySQL server's privilege system (see Section 6.2.3, “Grant Tables”).
It is safe but not necessary to retain privilege tables that use the
NDBstorage engine and were created in a previous release, but they are no longer used for access control in NDB Cluster 8.0. In NDB 8.0.16 and later, when a mysqld acting as an SQL node detects such tables in
NDB, it writes a warning to the MySQL server log, and creates
InnoDBshadow tables local to itself; such shadow tables are created on each MySQL server connected to an NDB Cluster. When performing an upgrade from NDB 7.6 or earlier, the privilege tables in
NDBcan be removed safely using ndb_drop_table once all MySQL servers acting as SQL nodes have been upgraded.
The ndb_restore utility's
--restore-privilege-tablesoption continues to be honored in NDB 8.0, and can still be used to restore distributed privilege tables present in a backup taken from a previous release of NDB Cluster to a cluster running NDB 8.0. These tables are handled as described in the preceeding paragraph.
For additional information regarding upgrades from previous NDB Cluster releases to NDB 8.0, see Section 22.2.8, “Upgrading and Downgrading NDB Cluster”.
Dynamic transactional resource allocation. Allocation of resources in the transaction corrdinator (see The DBTC Block) is now performed using dynamic memory pools. This means that resource allocation determined by data node configuration parameters such as
TransactionBufferMemoryis now done in such a way that, if the load represented by each of these parameters is within the target load for all such resources, others of these resources can be limited so as not to exceed the total resources available.
As part of this work, several new data node parameters controlling transactional resources in
DBTC, listed here, have been added:
Backups using multiple LDMs per data node.
NDBbackups can now be performed in a parallel fashion on individual data nodes using multiple local data managers (LDMs). (Previously, backups were done in parallel across data nodes, but were always serial within data node processes.) No special syntax is required for the
START BACKUPcommand in the ndb_mgm client to enable this feature, but all data nodes must be using multiple LDMs. This means that data nodes must be running ndbmtd (ndbd is single-threaded and thus always has only one LDM) and they must be configured to use multiple LDMs before taking the backup; you can do this by choosing an appropriate setting for one of the multi-threaded data node configuration parameters
Backups using multiple LDMs create subdirectories, one per LDM, under the
BACKUP/BACKUP-directory. ndb_restore now detects these subdirectories automatically, and if they exist, attempts to restore the backup in parallel; see Section 188.8.131.52, “Restoring from a backup taken in parallel”, for details. (Single-threaded backups are restored as in previous versions of
NDB.) It is also possible to restore backups taken in parallel using an ndb_restore binary from a previous version of NDB Cluster by modifying the usual restore procedure; Section 184.108.40.206.2, “Restoring a parallel backup serially”, provides information on how to do this.
Condition pushdown enhancements. Previously, condition pushdown was limited to predicate terms referring to column values from the same table to which the condition was being pushed. In NDB 8.0.16, this restriction is removed such that column values from tables earlier in the query plan can also be referred to from pushed conditions.
Pushing down larger parts of a condition allows more rows to be filtered out by the data nodes, thereby reducing the number of rows which mysqld must handle during join processing. Another benefit of this enhancement is that filtering can be performed in parallel in the LDM threads, rather than in a single mysqld process on an SQL node; this has the potential to improve query performance significantly.
Existing rules for type compatibility between column values being compared continue to apply (see Section 220.127.116.11, “Engine Condition Pushdown Optimization”).
ndb_mgm SHOW command and single user mode. Beginning with NDB 8.0.17, when the cluster in single user mode, the output of the management client
SHOWcommand indicates the API or SQL node having exclusive access while this mode is in effect.
Schema distribution enhancements. The
NDBschema distribution coordinator, which handles schema operations and tracks their progress, has been extended in NDB 8.0.17 to ensure that resources used during a schema operation are released at its conclusion. Previously, some of this work was done by the schema distribution client; this has been changed due to the fact that the client did not always have all needed state information, which could lead to resource leaks when the client decided to abandon the schema operation prior to completion and without informing the coordinator.
To help fix this issue, schema operation timeout detection has been moved from the schema distribution client to the coordinator, providing the coordinator with an opportunity to clean up any resources used during the schema operation. The coordinator now checks ongoing schema operations for timeout at regular intervals, and marks participants that have not yet completed a given schema operation as failed when detecting timeout. It also provides suitable warnings whenever a schema operation timeout occurs. (It should be noted that, after such a timeout is detected, the schema operation itself continues.) Additional reporting is done by printing a list of active schema operations at regular intervals whenever one or more of these operations is ongoing.