Enhanced backup status reporting.  Backup status reporting has been improved, aided in part by the introduction of a BackupReportFrequency configuration parameter; see Defining Data Nodes: BackupReportFrequency, for more information.

Multiple cluster connections per SQL node.  A single MySQL server acting as a MySQL Cluster SQL node can employ multiple connections to the cluster using the --ndb-cluster-connection-pool startup option for mysqld. This option is described in MySQL Cluster-Related Command Options for mysqld: --ndb-cluster-connection-pool option.

New data access interface.  The NdbRecord interface provides a new and simplified data handler for use in NDB API applications. See The NdbRecord Interface, for more information.

New reporting commands.  The new management client REPORT BackupStatus and REPORT MemoryUsage commands provide better access to information about the status of MySQL Cluster backups and how much memory is being used by MySQL Cluster for data and index storage. See Section 20.7.2, “Commands in the MySQL Cluster Management Client”, for more information about the REPORT commands. In addition, in-progress status reporting is provided by the ndb_restore utility; see Section 20.9.3, “ndb_restore — Restore a Cluster Backup”.

Improved memory allocation and configuration.  Memory is now allocated by the NDB kernel to tables on a page-by-page basis, which significantly reduces the memory overhead required for maintaining NDBCLUSTER tables. In addition, the MaxAllocate configuration parameter now makes it possible to set the maximum size of the allocation unit used for table memory; for more information about this configuration parameter, see Defining Data Nodes: MaxAllocate.

Choice of fixed-width or variable-width columns.  You can control whether fixed-width or variable-width storage is used for a given column of an NDB table by employing of the COLUMN_FORMAT specifier as part of the column's definition in a CREATE TABLE or ALTER TABLE statement. In addition, the ability to control whether a given column of an NDB table is stored in memory or on disk, using the STORAGE specifier as part of the column's definition in a CREATE TABLE or ALTER TABLE statement. For more information, see Section 12.1.10, “CREATE TABLE Syntax”, and Section 12.1.4, “ALTER TABLE Syntax”.

Controlling management client connections.  The --bind-address cluster management server startup option makes it possible to restrict management client connections to ndb_mgmd to a single host (IP address or hostname) and port, which can make MySQL Cluster management operations more secure. For more information about this option, see Section 20.6.5.2, “Command Options for ndb_mgmd”.

Micro-GCPs.  Due to a change in the protocol for handling of global checkpoints (GCPs handled in this manner sometimes being referred to as “micro-GCPs”), it is now possible to control how often the GCI number is updated, and how often global checkpoints are written to disk, using the TimeBetweenEpochs configuration parameter. This improves the reliability and performance of MySQL Cluster Replication. For more information, see Defining Data Nodes: TimeBetweenEpochs and Defining Data Nodes: TimeBetweenEpochsTimeout.

Core online schema change support.  Support for the online ALTER TABLE operations ADD COLUMN, ADD INDEX, and DROP INDEX is available. When the ONLINE keyword is used, the ALTER TABLE is non-copying, which means that indexes do not have to be re-created, which provides these benefits:

Online CREATE INDEX and DROP INDEX statements are also supported. Online changes can be suppressed using the OFFLINE key word. See Section 12.1.4, “ALTER TABLE Syntax”, Section 12.1.7, “CREATE INDEX Syntax”, and Section 12.1.13, “DROP INDEX Syntax”, for more detailed information.

mysql.ndb_binlog_index improvements.  More information has been added to the mysql.ndb_binlog_index table so that it is possible to determine which originating epochs have been applied inside an epoch. This is particularly useful for 3-way replication. See Section 20.11.4, “Cluster Replication Schema and Tables”, for more information.

Epoch lag control.  The MaxBufferedEpochs data node configuration parameter provides a means to control the maximum number of unprocessed epochs by which a subscribing node can lag. Subscribers which exceed this number are disconnected and forced to reconnect. For a discussion of this configuration parameter, see Defining Data Nodes: MaxBufferedEpochs.