Performance: Significant improvements in redo log handling and other filesystem operations can yield a considerable reduction in the time required for restarts. While actual restart times observed in a production setting will naturally vary according to database size, hardware, and other conditions, our own preliminary testing shows that these optimizations can yield startup times that are faster than those typical of previous MySQL Cluster releases by a factor of 50 or more.

Important Change: The --with-ndb-port-base option for configure did not function correctly, and has been deprecated. Attempting to use this option produces the warning Ignoring deprecated option --with-ndb-port-base.

Beginning with MySQL Cluster NDB 7.1.0, the deprecation warning itself is removed, and the --with-ndb-port-base option is simply handled as an unknown and invalid option if you try to use it. (Bug#47941)

See also Bug#38502.

In certain cases, performing very large inserts on NDB tables when using ndbmtd caused the memory allocations for ordered or unique indexes (or both) to be exceeded. This could cause aborted transactions and possibly lead to data node failures. (Bug#48037)

See also Bug#48113.

For UPDATE IGNORE statements, batching of updates is now disabled. This is because such statements failed when batching of updates was employed if any updates violated a unique constraint, to the fact a unique constraint violation could not be handled without aborting the transaction. (Bug#48036)

Starting a data node with a very large amount of DataMemory (approximately 90G or more) could lead to crash of the node due to job buffer congestion. (Bug#47984)

When an UPDATE statement was issued against an NDB table where an index was used to identify rows but no data was actually changed, the NDB storage returned zero found rows.

For example, consider the table created and populated using these statements:

CREATE TABLE t1 
(
    c1 INT NOT NULL, 
    c2 INT NOT NULL,
    PRIMARY KEY(c1), 
    KEY(c2)
) 
ENGINE = NDB;

INSERT INTO t1 VALUES(1, 1);

The following UPDATE statements, even though they did not change any rows, each still matched a row, but this was reported incorrectly in both cases, as shown here:

mysql> UPDATE t1 SET c2 = 1 WHERE c1 = 1;
Query OK, 0 rows affected (0.00 sec)
Rows matched: 0  Changed: 0  Warnings: 0

mysql> UPDATE t1 SET c1 = 1 WHERE c2 = 1;
Query OK, 0 rows affected (0.00 sec)
Rows matched: 0  Changed: 0  Warnings: 0

Now in such cases, the number of rows matched is correct. (In the case of each of the example UPDATE statements just shown, this is displayed as Rows matched: 1, as it should be.)

This issue could affect UPDATE statements involving any indexed columns in NDB tables, regardless of the type of index (including KEY, UNIQUE KEY, and PRIMARY KEY) or the number of columns covered by the index. (Bug#47955)

On Solaris, shutting down a management node failed when issuing the command to do so from a client connected to a different management node. (Bug#47948)

Setting FragmentLogFileSize to a value greater than 256 MB led to errors when trying to read the redo log file. (Bug#47908)

SHOW CREATE TABLE did not display the AUTO_INCREMENT value for NDB tables having AUTO_INCREMENT columns. (Bug#47865)

Under some circumstances, when a scan encountered an error early in processing by the DBTC kernel block (see The DBTC Block), a node could crash as a result. Such errors could be caused by applications sending incorrect data, or, more rarely, by a DROP TABLE operation executed in parallel with a scan. (Bug#47831)

When starting a node and synchronizing tables, memory pages were allocated even for empty fragments. In certain situations, this could lead to insufficient memory. (Bug#47782)

A very small race-condition between NODE_FAILREP and LQH_TRANSREQ signals when handling node failure could lead to operations (locks) not being taken over when they should have been, and subsequently becoming stale. This could lead to node restart failures, and applications getting into endless lock-conflicts with operations that were not released until the node was restarted. (Bug#47715)

See also Bug#41297.

configure failed to honor the --with-zlib-dir option when trying to build MySQL Cluster from source. (Bug#47223)

ndbd was not built correctly when compiled using gcc 4.4.0. (The ndbd binary was built, but could not be started.) (Bug#46113)

If a node failed while sending a fragmented long signal, the receiving node did not free long signal assembly resources that it had allocated for the fragments of the long signal that had already been received. (Bug#44607)

When starting a cluster with a great many tables, it was possible for MySQL client connections as well as the slave SQL thread to issue DML statements against MySQL Cluster tables before mysqld had finished connecting to the cluster and making all tables writeable. This resulted in Table ... is read only errors for clients and the Slave SQL thread.

This issue is fixed by introducing the --ndb-wait-setup option for the MySQL server. This provides a configurable maximum amount of time that mysqld waits for all NDB tables to become writeable, before allowing MySQL clients or the slave SQL thread to connect. (Bug#40679)

See also Bug#46955.

When building MySQL Cluster, it was possible to configure the build using --with-ndb-port without supplying a port number. Now in such cases, configure fails with an error. (Bug#38502)

See also Bug#47941.

When the MySQL server SQL mode included STRICT_TRANS_TABLES, storage engine warnings and error codes specific to NDB were returned when errors occurred, instead of the MySQL server errors and error codes expected by some programming APIs (such as Connector/J) and applications. (Bug#35990)

When a copying operation exhausted the available space on a data node while copying large BLOB columns, this could lead to failure of the data node and a Table is full error on the SQL node which was executing the operation. Examples of such operations could include an ALTER TABLE that changed an INT column to a BLOB column, or a bulk insert of BLOB data that failed due to running out of space or to a duplicate key error. (Bug#34583, Bug#48040)

See also Bug#41674, Bug#45768.

Replication: When mysqlbinlog --verbose was used to read a binary log that had been recorded using the row-based format, the output for events that updated some but not all columns of tables was not correct. (Bug#47323)

Disk Data: A local checkpoint of an empty fragment could cause a crash during a system restart which was based on that LCP. (Bug#47832)

See also Bug#41915.

Cluster Replication: When using multiple active replication channels, it was sometimes possible that a node group would fail on the slave cluster, causing the slave cluster to shut down. (Bug#47935)

Cluster Replication: When recording a binary log using the --ndb-log-update-as-write and --ndb-log-updated-only options (both enabled by default) and later attempting to apply that binary log with mysqlbinlog, any operations that were played back from the log but which updated only some (but not all) columns caused any columns that were not updated to be reset to their default values. (Bug#47674)

See also Bug#47323, Bug#46662.

Cluster Replication: mysqlbinlog failed to apply correctly a binary log that had been recorded using --ndb-log-update-as-write=1. (Bug#46662)

See also Bug#47323, Bug#47674.

Cluster API: If an NDB API program reads the same column more than once, it is possible exceed the maximum allowable message size, in which case the operation should be aborted due to NDB error 880 Tried to read too much - too many getValue calls, however due to a change introduced in MySQL Cluster NDB 6.3.18, the check for this was not done correctly, which instead caused a data node crash. (Bug#48266)

Cluster API: The NDB API methods Dictionary::listEvents(), Dictionary::listIndexes(), Dictionary::listObjects(), and NdbOperation::getErrorLine() formerly had both const and non-const variants. The non-const versions of these methods have been removed. In addition, the NdbOperation::getBlobHandle() method has been re-implemented in order to provide consistent internal semantics. (Bug#47798)

Cluster API: A duplicate read of a column caused NDB API applications to crash. (Bug#45282)

Cluster API: The error handling shown in the example file ndbapi_scan.cpp included with the MySQL Cluster distribution was incorrect. (Bug#39573)

Installation of MySQL on Windows would fail to set the correct location for the character set files, which could lead to mysqld and mysql failing to initialize properly. (Bug#17270)