The client receive thread was enabled only when under high load, where the criterion for determining “high load” was that the number of clients waiting in the poll queue (the receive queue) was greater than min_active_clients_recv_thread (default: 8).

This was a poor metric for determining high load, since a single client, such as the binary log injector thread handling incoming replication events, could experience high load on its own as well. The same was true of a pushed join query (in which very large batches of incoming TRANSID_AI signals are received).

We change the receive thread such that it now sleeps in the poll queue rather than being deactivated completely, so that it is now always available for handling incoming signals, even when the client is not under high load. (Bug #33752914)

Important Change: The maximum value supported for the --ndb-batch-size server option has been increased from 31536000 to 2147483648 (2 GB). (Bug #21040523)

Performance: When inserting a great many rows into an empty or small table in the same transaction, the rate at which rows were inserted quickly declined to less than 50% of the initial rate; subsequently, it was found that roughly 50% of all CPU time was spent in Dbacc::getElement(), and the root cause identified to be the timing of resizing the structures used for storing elements by DBACC, growing with the insertion of more rows in the same transaction, and shrinking following a commit.

We fix this issue by checking for a need to resize immediately following the insertion or deletion of an element. This also handles the subsequent rejection of an insert. (Bug #33803487)

References: See also: Bug #33803541.

Performance: The internal function computeXorChecksum() was implemented such that great care was taken to aid the compiler in generating optimal code, but it was found that it consumed excessive CPU resources, and did not perform as well as a simpler implementation. This function is now reimplemented with a loop summing up XOR results over an array, which appears to result in better optimization with both GCC and Clang compilers. (Bug #33757412)

In some cases, NDB did not validate all node IDs of data nodes correctly. (Bug #33896409)

In some cases, array indexes were not handled correctly. (Bug #33896389, Bug #33896399, Bug #33916134)

NdbEventBuffer hash key generation for non-character data reused the same 256 hash keys; in addition, strings of zero length were ignored when calculating hash keys. (Bug #33783274)

The collection of NDB API statistics based on the EventBytesRecvdCount event counter incurred excessive overhead. Now this counter is updated using a value which is aggregated as the event buffer is filled, rather than traversing all of the event buffer data in a separate function call.

For more information, see NDB API Statistics Counters and Variables. (Bug #33778923)

The deprecated -r option for ndbd has been removed. In addition, this change also removes extraneous text from the output of ndbd --help. (Bug #33362935)

References: See also: Bug #31565810.

When a node failure is detected, surviving nodes in the same nodegroup as this node attempt to resend any buffered change data to event subscribers. In cases in which there were no outstanding epoch deliveries, that is, the list of unacknowledged GCIs was empty, the surviving nodes made the incorrect assumption that this list would never be empty. (Bug #30509416)