It is no longer a requirement for database autodiscovery that an SQL node already be connected to the cluster at the time that a database is created on another SQL node. It is no longer necessary to issue CREATE DATABASE (or CREATE SCHEMA) statements on an SQL node joining the cluster after a database is created in order for the new SQL node to see the database and any NDCLUSTER tables that it contains. (Bug#39612)

Heavy DDL usage caused the mysqld processes to hang due to a timeout error (NDB error code 266). (Bug#39885)

Executing EXPLAIN SELECT on an NDBCLUSTER table could cause mysqld to crash. (Bug#39872)

Starting the MySQL Server with the --ndbcluster option plus an invalid command-line option (for example, using mysqld --ndbcluster --foobar) caused it to hang while shutting down the binlog thread. (Bug#39635)

Dropping and then re-creating a database on one SQL node caused other SQL nodes to hang. (Bug#39613)

Setting a low value of MaxNoOfLocalScans (< 100) and performing a large number of (certain) scans could cause the Transaction Coordinator to run out of scan fragment records, and then crash. Now when this resource is exhausted, the cluster returns Error 291 (Out of scanfrag records in TC (increase MaxNoOfLocalScans)) instead. (Bug#39549)

Creating a unique index on an NDBCLUSTER table caused a memory leak in the NDB subscription manager (SUMA) which could lead to mysqld hanging, due to the fact that the resource shortage was not reported back to the NDB kernel correctly. (Bug#39518)

See also Bug#39450.

Unique identifiers in tables having no primary key were not cached. This fix has been observed to increase the efficiency of INSERT operations on such tables by as much as 50%. (Bug#39267)

MgmtSrvr::allocNodeId() left a mutex locked following an Ambiguity for node if %d error. (Bug#39158)

An invalid path specification caused mysql-test-run.pl to fail. (Bug#39026)

During transactional coordinator takeover (directly after node failure), the LQH finding an operation in the LOG_COMMIT state sent an LQH_TRANS_CONF signal twice, causing the TC to fail. (Bug#38930)

An invalid memory access caused the management server to crash on Solaris Sparc platforms. (Bug#38628)

A segfault in Logger::Log caused ndbd to hang indefinitely. (Bug#38609)

ndb_mgmd failed to start on older Linux distributions (2.4 kernels) that did not support e-polling. (Bug#38592)

When restarting a data node, an excessively long shutodwn message could cause the node process to crash. (Bug#38580)

ndb_mgmd sometimes performed unnecessary network I/O with the client. This in combination with other factors led to long-running threads that were attempting to write to clients that no longer existed. (Bug#38563)

ndb_restore failed with a floating point exception due to a division by zero error when trying to restore certain data files. (Bug#38520)

A failed connection to the management server could cause a resource leak in ndb_mgmd. (Bug#38424)

Failure to parse configuration parameters could cause a memory leak in the NDB log parser. (Bug#38380)

After a forced shutdown and initial restart of the cluster, it was possible for SQL nodes to retain .frm files corresponding to NDBCLUSTER tables that had been dropped, and thus to be unaware that these tables no longer existed. In such cases, attempting to re-create the tables using CREATE TABLE IF NOT EXISTS could fail with a spurious Table ... doesn't exist error. (Bug#37921)

Renaming an NDBCLUSTER table on one SQL node, caused a trigger on this table to be deleted on another SQL node. (Bug#36658)

Attempting to add a UNIQUE INDEX twice to an NDBCLUSTER table, then deleting rows from the table could cause the MySQL Server to crash. (Bug#35599)

ndb_restore failed when a single table was specified. (Bug#33801)

GCP_COMMIT did not wait for transaction takeover during node failure. This could cause GCP_SAVE_REQ to be executed too early. This could also cause (very rarely) replication to skip rows. (Bug#30780)

Cluster Replication: In some cases, dropping a database on the master could cause table logging to fail on the slave, or, when using a debug build, could cause the slave mysqld to fail completely. (Bug#39404)

Cluster Replication: During a parallel node restart, the starting nodes could (sometimes) incorrectly synchronize subscriptions among themselves. Instead, this synchronization now takes place only among nodes that have actually (completely) started. (Bug#38767)

Cluster Replication: Data was written to the binlog with --log-slave-updates disabled. (Bug#37472)

Cluster API: Passing a value greater than 65535 to NdbInterpretedCode::add_val() and NdbInterpretedCode::sub_val() caused these methods to have no effect. (Bug#39536)

Cluster API: The NdbScanOperation::readTuples() method could be called multiple times without error. (Bug#38717)

Cluster API: Certain Multi-Range Read scans involving IS NULL and IS NOT NULL comparisons failed with an error in the NDB local query handler. (Bug#38204)

Cluster API: Problems with the public headers prevented NDB applications from being built with warnings turned on. (Bug#38177)

Cluster API: Creating an NdbScanFilter object using an NdbScanOperation object that had not yet had its readTuples() method called resulted in a crash when later attempting to use the NdbScanFilter. (Bug#37986)

Cluster API: Executing an NdbRecord interpreted delete created with an ANYVALUE option caused the transaction to abort. (Bug#37672)

Cluster API: Accesing the debug version of libndbclient via dlopen() resulted in a segmentation fault. (Bug#35927)