Documentation Home
MySQL 8.0 Reference Manual
Related Documentation Download this Manual
PDF (US Ltr) - 44.5Mb
PDF (A4) - 44.5Mb
PDF (RPM) - 40.2Mb
HTML Download (TGZ) - 10.5Mb
HTML Download (Zip) - 10.5Mb
HTML Download (RPM) - 9.1Mb
Man Pages (TGZ) - 204.6Kb
Man Pages (Zip) - 311.6Kb
Info (Gzip) - 3.9Mb
Info (Zip) - 3.9Mb
Excerpts from this Manual

MySQL 8.0 Reference Manual  /  ...  /  What is New in NDB Cluster

22.1.4 What is New in NDB Cluster

The following sections describe changes in the implementation of NDB Cluster in MySQL NDB Cluster 8.0 through 8.0.14, 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.

What is New in NDB Cluster 8.0

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 INFORMATION_SCHEMA.FILES table:

    • Tablespaces and log file groups are no longer represented in the FILES table. (These constructs are not actually files.)

    • Each data file is now represented by a single row in the FILES table. 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 EXTRA column of the FILES table.

    In addition, INFORMATION_SCHEMA tables now are populated with tablespace statistics for MySQL Cluster tables. (Bug #27167728)

  • Error information with ndb_perror.  Removed the deprecated --ndb option for perror. Use ndb_perror to obtain error message information from NDB error 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 -cluster to 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 -DWITH_NDBCLUSTER.

  • 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 NDB cluster performs a node or system restart, or as part of restoring a cluster from backup using ndb_restore --rebuild-indexes.

    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:

    1. The default value for BuildIndexThreads is changed from 0 to 128. This means that offline ordered index builds are now multithreaded by default.

    2. The default value for TwoPassInitialNodeRestartCopy is changed from false to 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.

    3. A new thread type (idxbld) is defined for the ThreadConfig configuration parameter, to allow locking of offline index build threads to specific CPUs.

    In addition, NDB now distinguishes the thread types that are accessible to ThreadConfig by the following two criteria:

    1. Whether the thread is an execution thread. Threads of types main, ldm, recv, rep, tc, and send are execution threads; thread types io, watchdog, and idxbld are not.

    2. Whether the allocation of the thread to a given task is permanent or temporary. Currently all thread types except idxbld are permanent.

    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.logbuffers table 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 REDO and 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_type rows is shown in the logbuffers table 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)

  • processes table on Windows.  The process ID of the monitor process used on Windows platforms by RESTART to spawn and restart a mysqld is now shown in the ndbinfo.processes table as an angel_pid.

  • ODirectSyncFlag.  Added the ODirectSyncFlag configuration 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 fsync.


    This parameter has no effect if at least one of the following conditions is true:

    • ODirect is not enabled.

    • InitFragmentLogFiles is set to SPARSE.

    (Bug #25428560)

  • Data node log buffer size control.  Added the --logbuffer-size option 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. NDB now 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, NDB continues 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)

    (See also.)

  • 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 .frm file, which is no longer supported in MySQL 8.0. To facilitate online upgrades to NDB 8.0, NDB performs 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 NDB software.


    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 NDB backup 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 NDB dictionary.

    Previously, the only NDB objects 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 NDB dictionary following a native backup and restore, in which tablespaces and log file groups were restored to the NDB dictionary, 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_USER value for the sql_mode option in the options file prevents mysqld from starting.

  • Handling of references to nonexistent tablespaces.  It is no longer possible to issue a CREATE TABLE statement that refers to a nonexistent tablespace. Such a statement now fails with an error.

  • RESET MASTER changes.  Because the MySQL Server now executes RESET MASTER with 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 MASTER is 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.


    SHOW BINLOG EVENTS, FLUSH LOGS, and most data definition statements continue, as they did in previous NDB versions, to operate in a synchronous fashion.

User Comments
User comments in this section are, as the name implies, provided by MySQL users. The MySQL documentation team is not responsible for, nor do they endorse, any of the information provided here.
Sign Up Login You must be logged in to post a comment.