MySQL NDB Cluster 7.3 Release Notes
Important Change:
When ndb_restore was run without
--disable-indexes
or
--rebuild-indexes
on a table
having a unique index, it was possible for rows to be restored
in an order that resulted in duplicate values, causing it to
fail with duplicate key errors. Running
ndb_restore
on such a table now requires using
at least one of these options; failing to do so now results in
an error.
(Bug #57782, Bug #11764893)
References: See also: Bug #22329365, Bug #22345748.
NDB Cluster APIs:
While executing
dropEvent()
, if the
coordinator DBDICT
failed after the
subscription manager (SUMA
block) had removed
all subscriptions but before the coordinator had deleted the
event from the system table, the dropped event remained in the
table, causing any subsequent drop or create event with the same
name to fail with NDB
error 1419
Subscription already dropped or error 746
Event name already exists. This occurred
even when calling
dropEvent()
with a
nonzero force argument.
Now in such cases, error 1419 is ignored, and
DBDICT
deletes the event from the table.
(Bug #21554676)
NDB Cluster APIs:
The internal value representing the latest global checkpoint was
not always updated when a completed epoch of event buffers was
inserted into the event queue. This caused subsequent calls to
Ndb::pollEvents()
and
pollEvents2()
to fail when
trying to obtain the correct GCI for the events available in the
event buffers. This could also result in later calls to
nextEvent()
or
nextEvent2()
seeing events
that had not yet been discovered.
(Bug #78129, Bug #21651536)
Backup block states were reported incorrectly during backups. (Bug #21360188)
References: See also: Bug #20204854, Bug #21372136.
When a data node is known to have been alive by other nodes in
the cluster at a given global checkpoint, but its
sysfile
reports a lower GCI, the higher GCI
is used to determine which global checkpoint the data node can
recreate. This caused problems when the data node being started
had a clean file system (GCI = 0), or when it was more than more
global checkpoint behind the other nodes.
Now in such cases a higher GCI known by other nodes is used only when it is at most one GCI ahead. (Bug #19633824)
References: See also: Bug #20334650, Bug #21899993. This issue is a regression of: Bug #29167.
When restoring a specific database or databases with the
--include-databases
or
--exclude-databases
option,
ndb_restore attempted to apply foreign keys
on tables in databases which were not among those being
restored.
(Bug #18560951)
After restoring the database schema from backup using ndb_restore, auto-discovery of restored tables in transactions having multiple statements did not work correctly, resulting in Deadlock found when trying to get lock; try restarting transaction errors.
This issue was encountered both in the mysql client, as well as when such transactions were executed by application programs using Connector/J and possibly other MySQL APIs.
Prior to upgrading, this issue can be worked around by executing
SELECT TABLE_NAME, TABLE_SCHEMA FROM
INFORMATION_SCHEMA.TABLES WHERE ENGINE = 'NDBCLUSTER'
on all SQL nodes following the restore operation, before
executing any other statements.
(Bug #18075170)
ndb_desc used with the
--extra-partition-info
and
--blob-info
options failed when
run against a table containing one or more
TINYBLOB
. columns.
(Bug #14695968)
Trying to create an NDB
table with a
composite foreign key referencing a composite primary key of the
parent table failed when one of the columns in the composite
foreign key was the table's primary key and in addition this
column also had a unique key.
(Bug #78150, Bug #21664899)
When attempting to enable index statistics, creation of the required system tables, events and event subscriptions often fails when multiple mysqld processes using index statistics are started concurrently in conjunction with starting, restarting, or stopping the cluster, or with node failure handling. This is normally recoverable, since the affected mysqld process or processes can (and do) retry these operations shortly thereafter. For this reason, such failures are no longer logged as warnings, but merely as informational events. (Bug #77760, Bug #21462846)
Adding a unique key to an NDB
table failed
when the table already had a foreign key. Prior to upgrading,
you can work around this issue by creating the unique key first,
then adding the foreign key afterwards, using a separate
ALTER TABLE
statement.
(Bug #77457, Bug #20309828)