MySQL Cluster information database (ndbinfo).  The ndbinfo information database makes it possible to obtain real-time characteristics of a MySQL Cluster by issuing queries from the mysql client or other MySQL client applications. ndbinfo provides metadata specific to MySQL Cluster similarly to how the INFORMATION_SCHEMA database provides metadata for the standard MySQL Server. This eliminates much of the need to read log files, issue REPORT or DUMP commands in the ndb_mgm client, or parse the output of ndb_config in order to get configuration and status information from a running MySQL Cluster.

For more information, see Section 17.5.10, “The ndbinfo MySQL Cluster Information Database”.

Java connectors for MySQL Cluster.  The MySQL Cluster distribution now includes 2 new Java user APIs, ClusterJ and ClusterJPA. ClusterJ is an object-relational interface in a manner similar to that of Java persistence frameworks such as Hibernate. Cluster JPA is a reimplementation of OpenJPA. ClusterJ uses a backend library (NdbJTie) that provides access to the NDB storage engine without using a MySQL Server connection or JDBC. ClusterJPA also uses NdbJTie when it improves performance, but can also process complex queries using JDBC and a MySQL Server connection, where it can take advantage of the MySQL query optimizer.

ClusterJ and Cluster JPA can also be made to work with recent MySQL Cluster NDB 7.0 releases although the necessary library and JAR files are included only in MySQL Cluster NDB 7.1.1 and later.

For more information about using ClusterJ and ClusterJPA, see MySQL Cluster Connector for Java.

New CHANGE MASTER TO option for circular replication.  Beginning with MySQL Cluster NDB 7.1.0, the CHANGE MASTER TO statement supports an IGNORE_SERVER_IDS option which takes a comma-separated list of server IDs and causes events originating from the corresponding servers to be ignored. (Log rotation and log deletion events are preserved.)

See Section 13.4.2.1, “CHANGE MASTER TO Syntax”, as well as Section 13.7.5.36, “SHOW SLAVE STATUS Syntax”, for more information.

Native support for default column values.  Starting with MySQL Cluster NDB 7.1.4, default values for table columns are stored in the NDB kernel rather than by the MySQL server as was done previously. This means that inserts on tables having column value defaults can be smaller and faster than before, because less data must be sent from SQL nodes to NDBCLUSTER.

Tables created using previous MySQL Cluster releases can still be used in MySQL Cluster 7.1.4 and later; however, they do not support native default values until they are upgraded. You can upgrade a table with non-native default values to support native default values using an offline ALTER TABLE statement.

MySQL Cluster on Windows (Production).  Beginning with MySQL Cluster NDB 7.1.3, MySQL Cluster is available for production use on Microsoft Windows operating systems; MySQL Cluster NDB 7.1 binaries for Windows can be obtained from http://dev.mysql.com/downloads/cluster/.

Features and behavior are generally comparable to those found on previously supported platforms such as Linux and Solaris. However, you must install the binaries manually.

Beginning with MySQL Cluster NDB 7.1.5, MySQL Cluster processes can be run as Windows services.

If you wish to build MySQL Cluster from source on Windows, you must configure the build using the WITH_NDBCLUSTER_STORAGE_ENGINE option. For more information, see Section 2.11.7, “Installing MySQL from Source on Windows”.

--nowait-nodes option for management servers.  It is now possible to configure a cluster with two management servers, but to start the cluster using only one of them by starting the management node daemon with the --nowait-nodes option. The other management server can then be started at a later time to join the running MySQL Cluster.

Improved lock handling for primary key lookups on BLOB tables.  A MySQL Cluster table stores all but the first 256 bytes of any BLOB or TEXT column values in a separate BLOB table; when executing queries against such tables, a shared lock is obtained. Prior to MySQL Cluster NDB 7.1.1, when the query used a primary key lookup and took place within a transaction, the lock was held for the duration of the transaction, even after no more data was being read from the NDB table. Now in such cases, the lock is released when all BLOB data associated with the table has been read. (Bug #49190)

Heartbeat thread policy and priority.  Beginning with MySQL Cluster NDB 7.1.2, a new configuration parameter HeartbeatThreadPriority makes it possible to set the policy and the priority for the heartbeat thread on management and API nodes.

Improved access to partitioning information.  The ndb_desc utility now provides additional information about the partitioning of data stored in MySQL Cluster. Beginning with MySQL Cluster NDB 7.1.2, the --blob-info option causes this program to include partition information for BLOB tables in its output. Also beginning with MySQL Cluster NDB 7.1.2, the --extra-node-info option causes ndb_desc to include information about data distribution (that is, which table fragments are stored on which data nodes). Each of these options also requires the use of the --extra-partition-info option.

Information about partition-to-node mappings can also be obtained using the Table::getFragmentNodes() method, also added in MySQL Cluster NDB 7.1.2.

Replication attribute promotion and demotion.  Beginning with MySQL Cluster NDB 7.1.3, MySQL Cluster Replication supports attribute promotion and demotion when replicating between columns of different but similar types on the master and the slave. For example, it is possible to promote an INT column on the master to a BIGINT column on the slave, and to demote a TEXT column to a VARCHAR column.

The implementation of type demotion distinguishes between lossy and non-lossy type conversions, and their use on the slave can be controlled by setting the slave_type_conversions global server system variable.

For more information, see Attribute promotion and demotion (MySQL Cluster).

Change in ndbinfo database.  The experimental pools table was removed from ndbinfo in MySQL Cluster NDB 7.1.3. Applications which used this table can and should be rewritten to use other ndbinfo tables.

Configuration caching control.  Beginning with MySQL Cluster NDB 7.1.4, it is possible to disable the management server's configuration cache using the --config-cache option, which forces ndb_mgmd to read its configuration data from the config.ini configuration file every time it starts. For more information about configuration caching and this option, see Section 17.3.2, “MySQL Cluster Configuration Files”. See also Section 17.4.4, “ndb_mgmd — The MySQL Cluster Management Server Daemon”.

Incompatible change in NDB API event reporting.  Beginning with MySQL Cluster NDB 7.1.4, DDL events are no longer reported on Event objects by default. Instead the desired level of event reporting (EventReport value) must be set explicitly using Event::setReport().

Number of table attributes.  Beginning with MySQL Cluster NDB 7.1.4, the maximum number of attributes (columns plus indexes) per table has been increased from 128 to 512.

InnoDB support in commercial binaries.  Beginning with MySQL Cluster NDB 7.1.4b, all commercial binary releases of MySQL Cluster provide support for the InnoDB storage engine.

Heartbeat ordering.  Beginning with MySQL Cluster NDB 7.1.5, it is possible to set a specific order for transmission of heartbeats between data nodes, using the HeartbeatOrder data node configuration parameter introduced in this version. This parameter can be useful in situations where multiple data nodes are running on the same host and a temporary disruption in connectivity between hosts would otherwise cause the loss of a node group (and thus failure of the cluster).

Relaxed ndb_restore column comparison rules.  When restoring data, ndb_restore compares the attributes of a column for equality with the definition of the column in the target table. However, not all of these attributes need to be the same for ndb_restore to be meaningful, safe and useful. Beginning with MySQL Cluster NDB 7.1.5, ndb_restore automatically ignores differences in certain column attributes which do not necessarily have to match between the version of the column in a backup and the version of that column in the MySQL Cluster to which the column data is being restored. These attributes include the following:

In such cases, ndb_restore reports any such differences to minimize any chance of user error.

Storage of user data in anyValue.  When writing NDB events to the binary log, MySQL Cluster uses OperationOptions::anyValue to store the server ID. Beginning with MySQL Cluster NDB 7.1.6, it is possible to store user data from an NDB API application in part of the anyValue when mysqld has been started with the --server-id-bits option set to a nondefault value. Also beginning with MySQL Cluster NDB 7.1.6, it is possible to view this data in the output of mysqlbinlog, for which its own --server-id-bits option is added.

--add-drop-trigger option for mysqldump.  Beginning with MySQL Cluster NDB 7.1.8, this option can be used to force all CREATE TRIGGER statements in mysqldump output to be preceded by a DROP TRIGGER IF EXISTS statement.

Forcing node shutdown and restart.  In MySQL Cluster NDB 7.1.8 and later, it is possible using the ndb_mgm management client or the MGM API to force a data node shutdown or restart even if this would force the shutdown or restart of the entire cluster. In the management client, this is implemented through the addition of the -f (force) option to the STOP and RESTART commands. For more information, see Section 17.5.2, “Commands in the MySQL Cluster Management Client”. The MGM API also adds two new methods for forcing such a node shutdown or restart; see ndb_mgm_stop4(), and ndb_mgm_restart4(), for more information about these methods.

Disk Data usage statistics (diskpagebuffer table).  MySQL Cluster 7.1.9 introduces a new table in the ndbinfo information database. The diskpagebuffer table provides real-time data on disk page buffer usage. These statistics can be used to monitor performance of MySQL Cluster Disk Data read and write operations, and can prove useful in the tuning of Disk Data parameters such as DiskPageBufferMemory.

InnoDB Plugin support.  Beginning with MySQL Cluster NDB 7.1.9, the MySQL Server supplied with MySQL Cluster supports the InnoDB Plugin. For more information about enabling the plugin if you are building MySQL Cluster from source, see Section 17.2, “MySQL Cluster Installation and Upgrades”.

TimeBetweenEpochsTimeout and GCP stop control.  Beginning with MySQL Cluster NDB 7.1.10, it is possible to disable GCP stops by setting TimeBetweenEpochsTimeout to 0. In addition, a warning is written to the cluster log whenever the time required for a GCP save exceeds 60 seconds or the time required for a GCP commit exceeds 10 seconds. This warning includes a report of the current value of TimeBetweenEpochsTimeout. For more information, see Disk Data and GCP Stop errors.

Skipping corrupted tables in NDB native backups.  Beginning with MySQL Cluster NDB 7.1.10, you can cause ndb_restore to ignore tables that are corrupted due to missing blob parts tables by using the the --skip-broken-objects option. When this option is used, such tables are skipped, and the restoration of any remaining uncorrupted tables in the backup continues.

BLOB read and write batching.  Beginning with MySQL Cluster NDB 7.1.10, it possible to control batching of BLOB read and write operations. For SQL nodes, this can be done using the --ndb-blob-read-batch-bytes and --ndb-blob-write-batch-bytes options for mysqld. In NDB API applications, you can control batching of BLOB reads and writes using the NdbTransaction methods setMaxPendingBlobReadBytes(), getMaxPendingBlobReadBytes(), setMaxPendingBlobWriteBytes(), and getMaxPendingBlobWriteBytes().

Restoring from a NDB native backup to a differently-named database.  MySQL Cluster NDB 7.1.11 adds a new --rewrite-database option to ndb_restore, which makes it possible to restore to a database having a different name from that of the database in the backup. The option can be used multiple times, and it is possible to restore from more than one source database in the backup to a single target database (although no protection against table or other object name collision is provided).

See Section 17.4.18, “ndb_restore — Restore a MySQL Cluster Backup”, for more information.

Selective over-commit handling.  Beginning with MySQL Cluster NDB 7.1.10, it is possible to exercise more direct control over uncommitted operations from transactions aborted due to timeouts flushing redo logs to disk. This is implemented using three configuration parameters added in this version of MySQL Cluster: the data node configuration parameters RedoOverCommitCounter and RedoOverCommitLimit, and the API node configuration parameter DefaultOperationRedoProblemAction.

When an attempt to flush a given redo log takes longer than RedoOverCommitLimit seconds, and this occurs RedoOverCommitLimit times or more, the transactions contained within the redo log are aborted. Any operations left uncommitted as a result are either aborted or re-tried, according to the value of DefaultOperationRedoProblemAction.

For more information, see Redo log over-commit handling

INFORMATION_SCHEMA improvements.  Beginning with MySQL Cluster NDB 7.1.11, Beginning with MySQL Cluster NDB 7.0.22, INFORMATION_SCHEMA provides disk usage information for MySQL Cluster Disk Data tables. Previously, INFORMATION_SCHEMA.TABLES showed only the space usage for the in-memory data part of the table. Now, it also shows the space allocated for and used by the disk_part data of that table as well.

In addition, the INFORMATION_SCHEMA.PARTITIONS table (which did not show any statistics for NDB tables) now shows correct values in this table's TABLE_ROWS, AVG_ROW_LENGTH, DATA_LENGTH, MAX_DATA_LENGTH, and DATA_FREE columns, for each partition.

ndb_restore attribute demotion.  Beginning with MySQL Cluster NDB 7.1.11, it is possible to enable attribute demotion when restoring a MySQL Cluster from a native backup running ndb_restore with a new --lossy-conversions option.

In general,the rules governing demotion are the same as for MySQL replication, although there are some exceptions that you may need to take into account being employing this option. See Section 16.4.1.9.2, “Replication of Columns Having Different Data Types”, for information about type conversions currently supported by attribute promotion and demotion in MySQL Cluster.

Improved multi-threaded order index building.  Previously, it was not possible to enable multi-threaded building of ordered indexes during initial restarts. In MySQL Cluster NDB 7.1.11, this can now be done, using the new TwoPassInitialNodeRestartCopy data node configuration parameter.

Configuration version information in ndbinfo.nodes.  You can see which version or versions of the MySQL Cluster configuration file are in effect on the data nodes by checking the config_generation column which is added to the nodes table in MySQL Cluster NDB 7.1.13.

Configuration version information in ndbinfo.nodes.  You can see which version or versions of the MySQL Cluster configuration file are in effect on the data nodes by checking the config_generation column which is added to the nodes table in MySQL Cluster NDB 7.1.13.

Improvements in adding data nodes online.  Begining with MySQL Cluster NDB 7.0.24, it is possible to add data nodes online to a running MySQL Cluster without performing a rolling restart of the cluster or starting data node processes with the --nowait-nodes option. This can be done by setting Nodegroup = 65536 in the config.ini file for any data nodes that should be started at a later time, when first starting the cluster. The amount of time the cluster waits before doing this can be controlled using the StartNoNodeGroupTimeout data node configuration parameter.

Unique key updates in replication.  It is possible in MySQL Cluster NDB 7.1.14 and later to employ operations that update unique keys when replicating NDB tables. Previously this could lead to duplicate key errors when trying to execute the binary log (due to the fact that row events in the binary log were ordered according to the partitioning of the base table, and could differ in order within the epoch for that in which they were executed).

Starting with MySQL Cluster NDB 7.1.17, the NDB kernel implements a number of statistical counters relating to actions performed by or affecting Ndb objects. Such events include starting, closing, and aborting transactions; operations using primary keys or unique keys; table, range, and pruned scans; blocking of threads by incompleted operations; and data and events sent and received by MySQL Cluster nodes. NDB API statistics counters are incremented inside the NDB kernel whenever NDB API calls are made or data is sent to or received by the data nodes. A MySQL Server running as an SQL node in the cluster can access the values of these counters as system status variables, as seen in the output of SHOW STATUS, or in the results of queries against the SESSION_STATUS or GLOBAL_STATUS table in the INFORMATION_SCHEMA database. By comparing the values of these status variables before and after the execution of statements affecting NDB tables, you can observe the corresponding actions taken on the NDB API level. This can be highly useful when monitoring and tuning MySQL Cluster.

For more information, see Section 17.5.15, “NDB API Statistics Counters and Variables”. See also Section 17.3.4.4, “MySQL Cluster Status Variables”, for information about the individual status variables.

Version 2 binary log row events.  New versions of the WRITE_ROW, UPDATE_ROW, and DELETE_ROW events have been implemented in MySQL Cluster NDB 7.1.16, extending them with additional information intended to support future enhancements; these are referred to as “Version 2” binary log events.

Version 2 log events are not backward compatible, and cannot be read by older slaves. A new mysqld option --log-bin-use-v1-row-events can be employed to force use of Version 1 events when writing the binary log. This can be used during upgrades to make a newer mysqld generate Version 1 binary log row events that can be read by older slaves.

Circular replication: “Primary wins first” conflict detection.  Two new conflict detection functions NDB$EPOCH() and NDB$EPOCH_TRANS() can be useful in “active-active” circular replication scenarios with two MySQL Clusters. For each case, we designate one cluster as primary and one as secondary, and implement a “primary always wins” rule for determining whether to accept conflicting changes. When using NDB$EPOCH(), conflicting rows on the secondary are realigned with those on the primary; when using NDB$EPOCH_TRANS(), it is transactions containing rows in conflict (and any transactions which depend on them) on the secondary that are realigned.

When using NDB$EPOCH_TRANS() as the conflict detection function, the binary log must be written using Version 2 binary logging row events; that is, the mysqld processes on both the primary and the secondary must be started with --log-bin-use-v1-row-events=0. In addition, the secondary's binary log must include transaction IDs for all rows, that is, by setting --ndb-log-transaction-id=1.

You can monitor conflict detection and resolution performed using these functions by reading a number of related server status variables, including Ndb_conflict_fn_epoch, Ndb_conflict_fn_epoch_trans, and Ndb_conflict_trans_row_conflict_count (among others). See Section 17.3.4.4, “MySQL Cluster Status Variables”.

For more information, see Section 17.6.11, “MySQL Cluster Replication Conflict Resolution”.

Fail-fast data node capability.  Beginning with MySQL Cluster NDB 7.1.17, it is possible to enable fail-fast behavior for data nodes by enabling the CrashOnCorruptedTuple configuration parameter introduced in this version (disabled by default). Doing so causes data nodes to fail whenever they detect a corrupted tuple.

Rows per partition limit removed.  Previously it was possible to store a maximum of 46137488 rows in a single MySQL Cluster partition—that is, per data node. Beginning with MySQL Cluster NDB 7.0.36 and MySQL Cluster NDB 7.1.25, this limitation has been lifted, and there is no longer any practical upper limit to this number. (Bug #13844405, Bug #14000373)