NdbScanOperation errors 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 CONF or REF signal to be returned from the data nodes. In this particular case, the expected TAB_SCANREF signal 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 NdbTransaction error code when a TAB_SCANREF error 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 DBTUP resulting in replica misalignment and other issues. We now prevent this from happening by detecting when operations are failing on non-primary replicas, and forcing AbortOnError handling (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 SUMA block 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) ALTER operation on a table to add or remove its READ_BACKUP property (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)