Cluster Replication: If data node failed during an event creation operation, there was a slight risk that a surviving data node could send an invalid table reference back to NDB, causing the operation to fail with a false Error 723 (No such table). This could take place when a data node failed as a mysqld process was setting up MySQL Cluster Replication. (Bug #43754)

Cluster API: Partition pruning did not work correctly for queries involving multiple range scans.

As part of the fix for this issue, several improvements have been made in the NDB API, including the addition of a new NdbScanOperation::getPruned() method, a new variant of NdbIndexScanOperation::setBound(), and a new PartitionSpec data structure. (Bug #37934)

TransactionDeadlockDetectionTimeout values less than 100 were treated as 100. This could cause scans to time out unexpectedly. (Bug #44099)

ndb_restore crashed when trying to restore a backup made to a MySQL Cluster running on a platform having different endianness from that on which the original backup was taken. (Bug #39540)

A race condition could occur when a data node failed to restart just before being included in the next global checkpoint. This could cause other data nodes to fail. (Bug #43888)

When a data node process had been killed after allocating a node ID, but before making contact with any other data node processes, it was not possible to restart it due to a node ID allocation failure.

This issue could effect either ndbd or ndbmtd processes. (Bug #43224)

References: This bug was introduced by Bug #42973.

Some queries using combinations of logical and comparison operators on an indexed column in the WHERE clause could fail with the error Got error 4541 'IndexBound has no bound information' from NDBCLUSTER. (Bug #42857)

TimeBetweenLocalCheckpoints was measured from the end of one local checkpoint to the beginning of the next, rather than from the beginning of one LCP to the beginning of the next. This meant that the time spent performing the LCP was not taken into account when determining the TimeBetweenLocalCheckpoints interval, so that LCPs were not started often enough, possibly causing data nodes to run out of redo log space prematurely. (Bug #43567)

Using indexes containing variable-sized columns could lead to internal errors when the indexes were being built. (Bug #43226)

When aborting an operation involving both an insert and a delete, the insert and delete were aborted separately. This was because the transaction coordinator did not know that the operations affected on same row, and, in the case of a committed-read (tuple or index) scan, the abort of the insert was performed first, then the row was examined after the insert was aborted but before the delete was aborted. In some cases, this would leave the row in a inconsistent state. This could occur when a local checkpoint was performed during a backup. This issue did not affect primary ley operations or scans that used locks (these are serialized).

After this fix, for ordered indexes, all operations that follow the operation to be aborted are now also aborted.

Disk Data: When a log file group had an undo log file whose size was too small, restarting data nodes failed with Read underflow errors.

As a result of this fix, the minimum permitted INTIAL_SIZE for an undo log file is now 1M (1 megabyte). (Bug #29574)

Cluster Replication: When creating or altering a table an NdbEventOperation is created by the mysqld process to monitor the table for subsequent logging in the binlog. If this happened during a node restart there was a chance that the reference count on this event operation object could be incorrect, which could lead to an assert in debug MySQL Cluster builds. (Bug #43752)

Cluster API: BIT columns created using the native NDB API format that were not created as nullable could still sometimes be overwritten, or cause other columns to be overwritten.

This issue did not effect tables having BIT columns created using the mysqld format (always used by MySQL Cluster SQL nodes). (Bug #43802)

Cluster API: If the largest offset of a RecordSpecification used for an NdbRecord object was for the NULL bits (and thus not a column), this offset was not taken into account when calculating the size used for the RecordSpecification. This meant that the space for the NULL bits could be overwritten by key or other information. (Bug #43891)

Cluster API: Ordered index scans using NdbRecord formerly expressed a BoundEQ range as separate lower and upper bounds, resulting in 2 copies of the column values being sent to the NDB kernel.

Now, when a range is specified by NdbScanOperation::setBound(), the passed pointers, key lengths, and inclusive bits are compared, and only one copy of the equal key columns is sent to the kernel. This makes such operations more efficient, as half the amount of KeyInfo is now sent for a BoundEQ range as before. (Bug #38793)

Cluster API: When performing insert or write operations, NdbRecord permits key columns to be specified in both the key record and in the attribute record. Only one key column value for each key column should be sent to the NDB kernel, but this was not guaranteed. This is now ensured as follows: For insert and write operations, key column values are taken from the key record; for scan takeover update operations, key column values are taken from the attribute record. (Bug #42238)

Cluster API: The default NdbRecord structures created by NdbDictionary could have overlapping null bits and data fields. (Bug #43590)