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
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_AIsignals 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-sizeserver option has been increased from
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
XORresults over an array, which appears to result in better optimization with both GCC and Clang compilers. (Bug #33757412)
In some cases,
NDBdid 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)
NdbEventBufferhash 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
EventBytesRecvdCountevent 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 receiver thread ID was hard-coded in the internal method
TransporterFacade::raise_thread_prio()such that it always acted to raise the priority of the receiver thread, even when called from the send thread. (Bug #33752983)
-roption 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.
The ndb_import tool handled only the hidden primary key which is defined by
NDBwhen a table does not have an explicit primary key. This caused an error when inserting a row containing
NULLfor an auto-increment primary key column, even though the same row was accepted by
LOAD DATA INFILE.
We fix this by adding support for importing a table with one or more instances of
NULLin an auto-increment primary key column. This includes a check that a table has no more than one auto-increment column; if this column is nullable, it is redefined by ndb_import as
NOT NULL, and any occurrence of
NULLin this column is replaced by a generated auto-increment value before inserting the row into
NDB. (Bug #30799495)
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)