In some critical situations such as data node failure, it was possible for the volume of log messages produced to cause file system and other issues, which compounded the problem, due to the fact that these messages were logged synchronously using
stdout. To keep this from happening, log messages from worker threads now use a log buffer instead, which is nonblocking, and thus much less likely to cause interference with other processes under such conditions. (Bug #24748843)
Added the ndb_top program on unix-based platforms. This utility shows CPU load and usage information for an
NDBdata node, with periodic updates (each second, by default). The display is in text or color ASCII graph format; both formats can be displayed at the same time. It is also possible to disable color output for the graph.
ndb_top is not currently available for Windows platforms.
For more information, see ndb_top — View CPU usage information for NDB threads. (WL #9788)
Packaging: Two missing dependencies were added to the
The data node package requires
The auto-installer requires
(Bug #85679, Bug #25799465)
NDB Disk Data: If the tablespace for a disk table had been fully consumed when a node failed, and table rows were deleted and inserted—or updated with shrinking or expanding disk column values—while the node was unavailable, a subsequent restart could fail with error 1601 Out of extents, tablespace full. We prevent this from happening by reserving 4 percent of the tablespace for use during node starts. (Bug #25923125)
NDB Cluster APIs: The implementation method
NdbDictionary::NdbTableImpl::getColumn(), used from many places in the NDB API where a column is referenced by name, has been made more efficient. This method used a linear search of an array of columns to find the correct column object, which could be inefficient for tables with many columns, and was detected as a significant use of CPU in customer applications. (Ideally, users should perform name-to-column object mapping, and then use column IDs or objects in method calls, but in practice this is not always done.) A less costly hash index implementation, used previously for the name lookup, is reinstated for tables having relatively many columns. (A linear search continues to be used for tables having fewer columns, where the difference in performance is neglible.) (Bug #24829435)
NDB Cluster APIs: NDB error 631 is reclassified as the (temporary) node recovery error Scan take over error, restart scan transaction. This was previously exposed to applications as an internal (and permanent) error which provided no description. (Bug #86401, Bug #26116231)
.logfiles contained log entries for one or more extra fragments, due to an issue with filtering out changes logged by other nodes in the same node group. This resulted in a larger
.logfile and thus use of more resources than necessary; it could also cause problems when restoring, since backups from different nodes could interfere with one another while the log was being applied. (Bug #25891014)
Memory exhaustion during fragment creation led to an unplanned shutdown of the cluster. This issue could be triggered by the addition of unique keys to a large number of columns at the same time. (Bug #25851801)
When making the final write to a redo log file, it is expected that the next log file is already opened for writes, but this was not always the case with a slow disk, leading to node failure. Now in such cases
NDBwaits for the next file to be opened properly before attempting to write to it. (Bug #25806659)
Data node threads can be bound to a single CPU or a set of CPUs, a set of CPUs being represented internally by
SparseBitmask. When attempting to lock to a set of CPUs, CPU usage was excessive due to the fact that the routine performing the locks used the
mt_thr_config.cpp::do_bind()method, which looks for bits that are set over the entire theoretical range of the
SparseBitmask(232-2, or 4294967294). This is fixed by using
SparseBitmask::getBitNo(), which can be used to iterate over only those bits that are actually set, instead. (Bug #25799506)
NoOfFragmentLogPartssuch that there were more than 4 redo log parts per local data manager led to resource exhaustion and subsequent multiple data node failures. Since this is an invalid configuration, a check has been added to detect a configuration with more than 4 redo log parts per LDM, and reject it as invalid. (Bug #25333414)
In certain cases, a failed
ALTER TABLE ... ADD UNIQUE KEYstatement could lead to SQL node failure. (Bug #24444878)
References: This issue is a regression of: Bug #23089566.
Error 240 is raised when there is a mismatch between foreign key trigger columns and the values supplied to them during trigger execution, but had no error message indicating the source of the problem. (Bug #23141739)
References: See also: Bug #23068914, Bug #85857.
If the number of LDM blocks was not evenly divisible by the number of TC/SPJ blocks, SPJ requests were not equally distributed over the available SPJ instances. Now a round-robin distribution is used to distribute SPJ requests across all available SPJ instances more effectively.
As part of this work, a number of unused member variables have been removed from the class
Dbtc. (Bug #22627519)
ALTER TABLE .. MAX_ROWS=0can now be performed only by using a copying
ALTER TABLEstatement. Resetting
MAX_ROWSto 0 can no longer be performed using
ALGORITHM=INPLACE. (Bug #21960004)
During a system restart, when a node failed due to having missed sending heartbeats, all other nodes reported only that another node had failed without any additional information. Now in such cases, the fact that heartbeats were missed and the ID of the node that failed to send heartbeats is reported in both the error log and the data node log. (Bug #21576576)
Due to a previous issue with unclear separation between the optimize and execute phases when a query involved a
GROUP BY, the join-pushable evaluator was not sure whether its optimized query execution plan was in fact pushable. For this reason, such grouped joins were always considered not pushable. It has been determined that the separation issue has been resolved by work already done in MySQL 5.6, and so we now remove this limitation. (Bug #86623, Bug #26239591)
When deleting all rows from a table immediately followed by
DROP TABLE, it was possible that the shrinking of the
DBACChash index was not ready prior to the drop. This shrinking is a per-fragment operation that does not check the state of the table. When a table is dropped,
DBACCreleases resources, during which the description of the fragment size and page directory is not consistent; this could lead to reads of stale pages, and undefined behavior.
Inserting a great many rows followed by dropping the table should also have had such effects due to expansion of the hash index.
To fix this problem we make sure, when a fragment is about to be released, that there are no pending expansion or shrinkage operations on this fragment. (Bug #86449, Bug #26138592)
Some error messages still referred to
IndexMemory, although that parameter has been deprecated. (Bug #86385, Bug #26107514)
The internal function
mt.cppread three section pointers from the signal even when none was passed to it. This was mostly harmless, although unneeded. When the signal read was the last one on the last page in the job buffer, and the next page in memory was not mapped or otherwise accessible, ndbmtd failed with an error. To keep this from occurring, this function now only reads section pointers that are actually passed to it. (Bug #86354, Bug #26092639)
There was at most one attempt in Dbacc to remove hash index pages freed when a table was dropped. This meant that, for large partitions (32 pages or more) there were always some pages lost. Now all hash index pages are freed when table using them is dropped. (Bug #86247, Bug #26030894)
When a query on an
NDBtable failed due to a foreign key constraint violation, no useful information about the foreign key was shown in the error message, which contained only the text Unknown error code. (Bug #86241, Bug #26029485, Bug #16371292)
References: See also: Bug #16275684.
The ndb_show_tables program
--unqualifiedoption did not work correctly when set to 0 (false); this should disable the option and so cause fully qualified table and index names to be printed in the output. (Bug #86017, Bug #25923164)
NDBtable with foreign key constraints is created, its indexes are created first, and then, during foreign key creation, these indexes are loaded into the
NDBdictionary cache. When a
CREATE TABLEstatement failed due to an issue relating to foreign keys, the indexes already in the cache were not invalidated. This meant that any subsequent
CREATE TABLEwith any indexes having the same names as those in the failed statement produced inconsistent results. Now, in such cases, any indexes named in the failed
CREATE TABLEare immediately invalidated from the cache. (Bug #85917, Bug #25882950)
During a local checkpoint, the record size is obtained from the
DBTUPkernel block. This record size remained in use until the LCP scan was completed, which made it possible for
DBTUPto update the maximum record size on commit of an
ALTER TABLEthat added a column to the table, and which could lead to node failure during the LCP. Now the record size is fetched at a point where updating it does not lead to this condition. (Bug #85858, Bug #25860002)
Attempting to execute
ALTER TABLE ... ADD FOREIGN KEYwhen the key to be added had the name of an existing foreign key on the same table failed with the wrong error message. (Bug #85857, Bug #23068914)
The node internal scheduler (in
mt.cpp) collects statistics about its own progress and any outstanding work it is performing. One such statistic is the number of outstanding send bytes, collected in
send_buffer::m_node_total_send_buffer_size. This information may later be used by the send thread scheduler, which uses it as a metric to tune its own send performance versus latency.
In order to reduce lock contention on the internal send buffers, they are split into two
m_sending, each protected by its own mutex, and their combined size repesented by
Investigation of the code revealed that there was no consistency as to which mutex was used to update
m_node_total_send_buffer_size, with the result that there was no consurrency protection for this value. To avoid this,
m_node_total_send_buffer_sizeis replaced with two values,
m_sending_size, which keep separate track of the sizes of the two buffers. These counters are updated under the protection of two different mutexes protecting each buffer individually, and are now added together to obtain the total size.
With concurrency control established, updates of the partial counts should now be correct, so that their combined value no longer accumulates errors over time. (Bug #85687, Bug #25800933)
Enabled the use of short or packed short
TRANSID_AIsignals for sending results from
DBSPJback to the client API. (Bug #85545, Bug #25750355)
References: See also: Bug #85525, Bug #25741170.
BatchByteSizeas sent in
SCANREQsignals was not always set correctly to reflect a limited byte size available in the client result buffers. The result buffer size calculation has been modified such that the effective batch byte size accurately reflects the maximum that may be returned by data nodes to prevent a possible overflow of the result buffers. (Bug #85411, Bug #25703113)
When compiling the NDB kernel with gcc version 6.0.0 or later, it is now built using
-flifetime-dse=1. (Bug #85381, Bug #25690926)