NdbScanOperationerrors are returned asynchronously to the client, possibly while the client is engaged in other processing. A successful call to
NdbTransaction::execute()guarantees only that the scan request has been assembled and sent to the transaction coordinator without any errors; it does not wait for any sort of
REFsignal to be returned from the data nodes. In this particular case, the expected
TAB_SCANREFsignal was returned asynchronously into the client space, possibly while the client was still performing other operations.
We make this behavior more deterministic by not setting the
NdbTransactionerror code when a
TAB_SCANREFerror is received. (Bug #34348706)
The combination of batching with multiple in-flight operations per key, use of
IgnoreError, and transient errors occurring on non-primary replicas led in some cases to inconsistencies within
DBTUPresulting in replica misalignment and other issues. We now prevent this from happening by detecting when operations are failing on non-primary replicas, and forcing
AbortOnErrorhandling (rollback) in such cases for the containing transaction. (Bug #34013385)
When the rate of changes was high, event subscribers were slow to acknowledge receipt, or both, it was possible for the
SUMAblock to run out of space for buffering events. (Bug #30467140)
ALTER TABLE ... COMMENT="NDB_TABLE=READ_BACKUP=1"or
ALTER TABLE..COMMENT="NDB_TABLE=READ_BACKUP=0"performs a non-copying (online)
ALTERoperation on a table to add or remove its
READ_BACKUPproperty (see NDB_TABLE Options), which increments the index version of all indexes on the table. Existing statistics, stored using the previous index version, were orphaned and never deleted; this led to wasted memory and inefficient searches when collecting index statistics.
We address these issues by cleaning up the index samples; we delete any samples whose sample version is greater than or less than the current sample version. In addition, when no existing statistics are found by index ID and version, and when indexes are dropped. In this last case, we relax the bounds for the delete operation and remove all entries corresponding to the index ID in question, as opposed to both index ID and index version.
This fix cleans up the sample table which stores the bulk of index statistics data. The head table, which consists of index metadata rather than actual statistics, still contains orphaned rows, but since these occupy an insignificant amount of memory, they do not adversely affect statistics search efficiency, and stale entries are cleaned up when index IDs and versions are reused.
See also NDB API Statistics Counters and Variables. (Bug #29611297)