MySQL NDB Cluster 7.2 Release Notes
NDB Cluster APIs:
The binary log injector did not work correctly with
TE_INCONSISTENT
event type handling by
Ndb::nextEvent()
.
(Bug #22135541)
References: See also: Bug #20646496.
NDB Cluster APIs:
Ndb::pollEvents()
and
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_binlog
handler, which has been
added as part of this fix.
(Bug #79311, Bug #20957068, Bug #22224571)
In debug builds, a WAIT_EVENT
while polling
caused excessive logging to stdout.
(Bug #22203672)
When executing a schema operation such as
CREATE TABLE
on 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-updated-only
,
--ndb-log-update-as-write
, or
other mysqld options effecting binary logging
by NDB
.
This happened due to the fact that, in order to distribute
schema changes between them, all SQL nodes subscribe to changes
in the ndb_schema
system table, and that all
SQL nodes are made aware of each others subscriptions by
subscribing to TE_SUBSCRIBE
and
TE_UNSUBSCRIBE
events. The names of events to
subscribe to are constructed from the table names, adding
REPL$
or 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_schema
table 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)
Using ndb_mgm STOP -f
to
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 SUMA
handovers
had been made to nodes already in the process of shutting down.
(Bug #17772138)
The internal
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_CONF
signal 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)
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)
NDB
failed 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)
The value set for spintime
by the
ThreadConfig
parameter
was not calculated correctly, causing the spin to continue for
longer than actually specified.
(Bug #78525, Bug #21886476)