MySQL NDB Cluster 7.4.9 included a serious regression in performance during restarts, discovered shortly after release, and is replaced by MySQL NDB Cluster 7.4.10. Users of previous MySQL NDB Cluster 7.4 releases are advised to upgrade to MySQL NDB Cluster 7.4.10 or later, by passing NDB 7.4.9.
Obtaining MySQL NDB Cluster 7.4. MySQL NDB Cluster 7.4 source code and binaries can be obtained from https://dev.mysql.com/downloads/cluster/.
For an overview of changes made in MySQL NDB Cluster 7.4, see What is New in NDB Cluster 7.4.
This release also incorporates all bug fixes and changes made in previous NDB Cluster releases, as well as all bug fixes and feature changes which were added in mainline MySQL 5.6 through MySQL 5.6.28 (see Changes in MySQL 5.6.28 (2015-12-07, General Availability)).
Important Change: Previously, the
NDBscheduler always optimized for speed against throughput in a predetermined manner (this was hard coded); this balance can now be set using the
SchedulerResponsivenessdata node configuration parameter. This parameter accepts an integer in the range of 0-10 inclusive, with 5 as the default. Higher values provide better response times relative to throughput. Lower values provide increased throughput, but impose longer response times. (Bug #78531, Bug #21889312)
NDB Replication: Normally,
RESET SLAVEcauses all entries to be deleted from the
mysql.ndb_apply_statustable. This release adds the
ndb_clear_apply_statussystem variable, which makes it possible to override this behavior. This variable is
ONby default; setting it to
RESET SLAVEfrom purging the
ndb_apply_statustable. (Bug #12630403)
tc_time_track_statstable to the
ndbinfoinformation database. This table provides time-tracking information relating to transactions, key operations, and scan operations performed by
NDB. (Bug #78533, Bug #21889652)
Important Change: A fix made in MySQL NDB Cluster 7.3.11 and MySQL NDB Cluster 7.4.8 caused ndb_restore to perform unique key checks even when operating in modes which do not restore data, such as when using the program's
That change in behavior caused existing valid backup routines to fail; to keep this issue from affecting this and future releases, the previous fix has been reverted. This means that the requirement added in those versions that ndb_restore be run
--rebuild-indexeswhen used on tables containing unique indexes is also lifted. (Bug #22345748)
References: See also: Bug #22329365. Reverted patches: Bug #57782, Bug #11764893.
Important Change: Users can now set the number and length of connection timeouts allowed by most
NDBprograms with the
--connect-retry-delaycommand line options introduced for the programs in this release. For ndb_mgm,
--connect-retriessupersedes the existing
--try-reconnectoption. (Bug #57576, Bug #11764714)
NDB Disk Data: A unique index on a column of an
NDBtable is implemented with an associated internal ordered index, used for scanning. While dropping an index, this ordered index was dropped first, followed by the drop of the unique index itself. This meant that, when the drop was rejected due to (for example) a constraint violation, the statement was rejected but the associated ordered index remained deleted, so that any subsequent operation using a scan on this table failed. We fix this problem by causing the unique index to be removed first, before removing the ordered index; removal of the related ordered index is no longer performed when removal of a unique index fails. (Bug #78306, Bug #21777589)
NDB Replication: While the binary log injector thread was handling failure events, it was possible for all
NDBtables to be left indefinitely in read-only mode. This was due to a race condition between the binary log injector thread and the utility thread handling events on the ndb_schema table, and to the fact that, when handling failure events, the binary log injector thread places all
NDBtables in read-only mode until all such events are handled and the thread restarts itself.
When the binary log inject thread receives a group of one or more failure events, it drops all other existing event operations and expects no more events from the utility thread until it has handled all of the failure events and then restarted itself. However, it was possible for the utility thread to continue attempting binary log setup while the injector thread was handling failures and thus attempting to create the schema distribution tables as well as event subscriptions on these tables. If the creation of these tables and event subscriptions occurred during this time, the binary log injector thread's expectation that there were no further event operations was never met; thus, the injector thread never restarted, and
NDBtables remained in read-only as described previously.
To fix this problem, the
Ndbobject that handles schema events is now definitely dropped once the
ndb_schematable drop event is handled, so that the utility thread cannot create any new events until after the injector thread has restarted, at which time, a new
Ndbobject for handling schema events is created. (Bug #17674771, Bug #19537961, Bug #22204186, Bug #22361695)
NDB Cluster APIs: The binary log injector did not work correctly with
TE_INCONSISTENTevent type handling by
Ndb::nextEvent(). (Bug #22135541)
References: See also: Bug #20646496.
NDB Cluster APIs:
pollEvents2()were slow to receive events, being dependent on other client threads or blocks to perform polling of transporters on their behalf. This fix allows a client thread to perform its own transporter polling when it has to wait in either of these methods.
Introduction of transporter polling also revealed a problem with missing mutex protection in the
ndbcluster_binloghandler, which has been added as part of this fix. (Bug #79311, Bug #20957068, Bug #22224571)
NDB Cluster APIs: Garbage collection is performed on several objects in the implementation of
NdbEventOperation, based on which GCIs have been consumed by clients, including those that have been dropped by
Ndb::dropEventOperation(). In this implementation, the assumption was made that the global checkpoint index (GCI) is always monotonically increasing, although this is not the case during an initial restart, when the GCI is reset. This could lead to event objects in the NDB API being released prematurely or not at all, in the latter case causing a resource leak.
To prevent this from happening, the NDB event object's implementation now tracks, internally, both the GCI and the generation of the GCI; the generation is incremented whenever the node process is restarted, and this value is now used to provide a monotonically increasing sequence. (Bug #73781, Bug #21809959)
In debug builds, a
WAIT_EVENTwhile polling caused excessive logging to stdout. (Bug #22203672)
When executing a schema operation such as
CREATE TABLEon a MySQL NDB Cluster with multiple SQL nodes, it was possible for the SQL node on which the operation was performed to time out while waiting for an acknowledgement from the others. This could occur when different SQL nodes had different settings for
--ndb-log-update-as-write, or other mysqld options effecting binary logging by
This happened due to the fact that, in order to distribute schema changes between them, all SQL nodes subscribe to changes in the
ndb_schemasystem table, and that all SQL nodes are made aware of each others subscriptions by subscribing to
TE_UNSUBSCRIBEevents. The names of events to subscribe to are constructed from the table names, adding
REPLF$as a prefix.
REPLF$is used when full binary logging is specified for the table. The issue described previously arose because different values for the options mentioned could lead to different events being subscribed to by different SQL nodes, meaning that all SQL nodes were not necessarily aware of each other, so that the code that handled waiting for schema distribution to complete did not work as designed.
To fix this issue, MySQL NDB Cluster now treats the
ndb_schematable as a special case and enforces full binary logging at all times for this table, independent of any settings for mysqld binary logging options. (Bug #22174287, Bug #79188)
Attempting to create an
NDBtable having greater than the maximum supported combined width for all
BITcolumns (4096) caused data node failure when these columns were defined with
COLUMN_FORMAT DYNAMIC. (Bug #21889267)
Creating a table with the maxmimum supported number of columns (512) all using
COLUMN_FORMAT DYNAMICled to data node failures. (Bug #21863798)
In certain cases, a cluster failure (error 4009) was reported as Unknown error code. (Bug #21837074)
For a timeout in
GET_TABINFOREQwhile executing a
CREATE INDEXstatement, mysqld returned Error 4243 (Index not found) instead of the expected Error 4008 (Receive from NDB failed).
The fix for this bug also fixes similar timeout issues for a number of other signals that are sent the
DBDICTkernel block as part of DDL operations, including
LIST_TABLES_REQ, as well as several internal functions used in handling
NDBschema operations. (Bug #21277472)
References: See also: Bug #20617891, Bug #20368354, Bug #19821115.
STOP -fto force a node shutdown even when it triggered a complete shutdown of the cluster, it was possible to lose data when a sufficient number of nodes were shut down, triggering a cluster shutodwn, and the timing was such that
SUMAhandovers had been made to nodes already in the process of shutting down. (Bug #17772138)
NdbEventBuffer::set_total_buckets()method calculated the number of remaining buckets incorrectly. This caused any incomplete epoch to be prematurely completed when the
SUB_START_CONFsignal arrived out of order. Any events belonging to this epoch arriving later were then ignored, and so effectively lost, which resulted in schema changes not being distributed correctly among SQL nodes. (Bug #79635, Bug #22363510)
Compilation of MySQL NDB Cluster failed on SUSE Linux Enterprise Server 12. (Bug #79429, Bug #22292329)
Schema events were appended to the binary log out of order relative to non-schema events. This was caused by the fact that the binary log injector did not properly handle the case where schema events and non-schema events were from different epochs.
This fix modifies the handling of events from the two schema and non-schema event streams such that events are now always handled one epoch at a time, starting with events from the oldest available epoch, without regard to the event stream in which they occur. (Bug #79077, Bug #22135584, Bug #20456664)
When executed on an
ALTER TABLE ... DROP INDEXmade changes to an internal array referencing the indexes before the index was actually dropped, and did not revert these changes in the event that the drop was not completed. One effect of this was that, after attempting to drop an index on which there was a foreign key dependency, the expected error referred to the wrong index, and subsequent attempts using SQL to modify indexes of this table failed. (Bug #78980, Bug #22104597)
NDBfailed during a node restart due to the status of the current local checkpoint being set but not as active, even though it could have other states under such conditions. (Bug #78780, Bug #21973758)
ndbmtd checked for signals being sent only after a full cycle in
run_job_buffers, which is performed for all job buffer inputs. Now this is done as part of
run_job_buffersitself, which avoids executing for extended periods of time without sending to other nodes or flushing signals to other threads. (Bug #78530, Bug #21889088)
The value set for
ThreadConfigparameter was not calculated correctly, causing the spin to continue for longer than actually specified. (Bug #78525, Bug #21886476)
NDBFScompleted file operations, the method it employed for waking up the main thread worked effectively on Linux/x86 platforms, but not on some others, including OS X, which could lead to unnecessary slowdowns on those platforms. (Bug #78524, Bug #21886157)