Cluster API: It is now possible to determine, using the ndb_desc utility or the NDB API, which data nodes contain replicas of which partitions. For ndb_desc, a new --extra-node-info option is added to cause this information to be included in its output. A new method NdbDictionary::Object::Table::getFragmentNodes() is added to the NDB API for obtaining this information programmatically. (Bug#51184)

Numeric codes used in management server status update messages in the cluster logs have been replaced with text descriptions. (Bug#49627)

See also Bug#44248.

A new configuration parameter HeartbeatThreadPriority makes it possible to select between a first-in, first-out or round-round scheduling policy for management node and API node heartbeat threads, as well as to set the priority of these threads. See Section 17.3.2.5, “Defining a MySQL Cluster Management Server”, or Section 17.3.2.7, “Defining SQL and Other API Nodes in a MySQL Cluster”, for more information. (Bug#49617)

Start phases are now written to the data node logs. (Bug#49158)

Formerly, the REPORT and DUMP commands returned output to all ndb_mgm clients connected to the same MySQL Cluster. Now, these commands return their output only to the ndb_mgm client that actually issued the command. (Bug#40865)

Disk Data: The ndb_desc utility can now show the extent space and free extent space for subordinate BLOB and TEXT columns (stored in hidden BLOB tables by NDB). A --blob-info option has been added for this program that causes ndb_desc to generate a report for each subordinate BLOB table. For more information, see Section 17.4.9, “ndb_desc — Describe NDB Tables”. (Bug#50599)

Important Change: The DATA_MEMORY column of the ndbinfo.memoryusage table was renamed to memory_type. (Bug#50926)

When deciding how to divide the REDO log, the DBDIH kernel block saved more than was needed to restore the previous local checkpoint, which could cause REDO log space to be exhausted prematurely (NDB error 410). (Bug#51547)

DML operations can fail with NDB error 1220 (REDO log files overloaded...) if the opening and closing of REDO log files takes too much time. If this occurred as a GCI marker was being written in the REDO log while REDO log file 0 was being opened or closed, the error could persist until a GCP stop was encountered. This issue could be triggered when there was insufficient REDO log space (for example, with configuration parameter settings NoOfFragmentLogFiles = 6 and FragmentLogFileSize = 6M) with a load including a very high number of updates. (Bug#51512)

See also Bug#20904.

An attempted online upgrade from a MySQL Cluster NDB 6.3 or 7.0 release to a MySQL Cluster NDB 7.1 release failed, as the first upgraded data node rejected the remaining data nodes as using incompatible versions. (Bug#51429)

A side effect of the ndb_restore --disable-indexes and --rebuild-indexes options is to change the schema versions of indexes. When a mysqld later tried to drop a table that had been restored from backup using one or both of these options, the server failed to detect these changed indexes. This caused the table to be dropped, but the indexes to be left behind, leading to problems with subsequent backup and restore operations. (Bug#51374)

The output of the ndb_mgm client REPORT BACKUPSTATUS command could sometimes contain errors due to uninitialized data. (Bug#51316)

Setting IndexMemory greater than 2GB could cause data nodes to crash while starting. (Bug#51256)

ndb_restore crashed while trying to restore a corrupted backup, due to missing error handling. (Bug#51223)

The ndb_restore message Successfully created index `PRIMARY`... was directed to stderr instead of stdout. (Bug#51037)

An initial restart of a data node configured with a large amount of memory could fail with a Pointer too large error. (Bug#51027)

This regression was introduced by Bug#47818.

When using NoOfReplicas equal to 1 or 2, if data nodes from one node group were restarted 256 times and applications were running traffic such that it would encounter NDB error 1204 (Temporary failure, distribution changed), the live node in the node group would crash, causing the cluster to crash as well. The crash occurred only when the error was encountered on the 256th restart; having the error on any previous or subsequent restart did not cause any problems. (Bug#50930)

A GROUP BY query against NDB tables sometimes did not use any indexes unless the query included a FORCE INDEX option. With this fix, indexes are used by such queries (where otherwise possible) even when FORCE INDEX is not specified. (Bug#50736)

ndbmtd started on a single-core machine could sometimes fail with a Job Buffer Full error when MaxNoOfExecutionThreads was set greater than LockExecuteThreadToCPU. Now a warning is logged when this occurs. (Bug#50582)

The following issues were fixed in the ndb_mgm client REPORT MEMORYUSAGE command:

(Bug#50196)

Issuing a command in the ndb_mgm client after it had lost its connection to the management server could cause the client to crash. (Bug#49219)

Replication of a MySQL Cluster using multi-threaded data nodes could fail with forced shutdown of some data nodes due to the fact that ndbmtd exhausted LongMessageBuffer much more quickly than ndbd. After this fix, passing of replication data between the DBTUP and SUMA NDB kernel blocks is done using DataMemory rather than LongMessageBuffer.

Until you can upgrade, you may be able to work around this issue by increasing the LongMessageBuffer setting; doubling the default should be sufficient in most cases. (Bug#46914)

Information about several management client commands was missing from (that is, truncated in) the output of the HELP command. (Bug#46114)

A SELECT requiring a sort could fail with the error Can't find record in 'table' when run concurrently with a DELETE from the same table. (Bug#45687)

When the MemReportFrequency configuration parameter was set in config.ini, the ndb_mgm client REPORT MEMORYUSAGE command printed its output multiple times. (Bug#37632)

ndb_mgm -e "... REPORT ..." did not write any output to stdout.

The fix for this issue also prevents the cluster log from being flooded with INFO messages when DataMemory usage reaches 100%, and insures that when when the usage is decreased, an appropriate message is written to the cluster log. (Bug#31542, Bug#44183, Bug#49782)

Disk Data: The error message returned after atttempting to execute ALTER LOGFILE GROUP on an nonexistent logfile group did not indicate the reason for the failure. (Bug#51111)

Cluster API: An issue internal to ndb_mgm could cause problems when trying to start a large number of data nodes at the same time. (Bug#51273)

Cluster API: When reading blob data with lock mode LM_SimpleRead, the lock was not upgraded as expected. (Bug#51034)