[This is part 3 of the announcement]
* Cluster API: The binlog injector did not work correctly
with TE_INCONSISTENT event type handling by Ndb::nextEvent()
(http://dev.mysql.com/doc/ndbapi/en/ndb-ndb-methods.html#
ndb-ndb-nextevent). (Bug #22135541) References: See also Bug
#20646496.
* Cluster API: While executing dropEvent()
(http://dev.mysql.com/doc/ndbapi/en/ndb-dictionary-method
s.html#ndb-dictionary-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()
(http://dev.mysql.com/doc/ndbapi/en/ndb-dictionary-method
s.html#ndb-dictionary-dropevent) with a nonzero force argument.
Now in such cases, error 1419 is ignored, and DBDICT deletes the
event from the table. (Bug #21554676)
* Cluster API: Ndb::pollEvents()
(http://dev.mysql.com/doc/ndbapi/en/ndb-ndb-methods.html#
ndb-ndb-pollevents) and pollEvents2()
(http://dev.mysql.com/doc/ndbapi/en/ndb-ndb-methods.html#
ndb-ndb-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 #20957068, Bug #22224571, Bug #79311)
* Cluster API: The pollEvents2()
(http://dev.mysql.com/doc/ndbapi/en/ndb-ndb-methods.html#
ndb-ndb-pollevents2) method now waits indefinitely for events
when a negative value is used for the time argument. (Bug
#20762291)
* Cluster API: Creation and destruction of
Ndb_cluster_connection
(http://dev.mysql.com/doc/ndbapi/en/ndb-ndb-cluster-conne
ction.html) objects by multiple threads could make use of the
same application lock, which in some cases led to failures in the
global dictionary cache. To alleviate this problem, the creation
and destruction of several internal NDB API objects have been
serialized. (Bug #20636124)
* Cluster API: When an Ndb
(http://dev.mysql.com/doc/ndbapi/en/ndb-ndb.html) object created
prior to a failure of the cluster was reused, the event queue of
this object could still contain data node events originating from
before the failure. These events could reference "old" epochs
(from before the failure occurred), which in turn could violate
the assumption made by the nextEvent()
(http://dev.mysql.com/doc/ndbapi/en/ndb-ndb-methods.html#
ndb-ndb-nextevent) method that epoch numbers always increase.
This issue is addressed by explicitly clearing the event queue in
such cases. (Bug #18411034) References: See also Bug #20888668.
* Cluster API: After the initial restart of a node
following a cluster failure, the cluster failure event added as
part of the restart process was deleted when an event that
existed prior to the restart was later deleted. This meant that,
in such cases, an Event API client had no way of knowing that
failure handling was needed. In addition, the GCI used for the
final cleanup of deleted event operations, performed by
pollEvents()
(http://dev.mysql.com/doc/ndbapi/en/ndb-ndb-methods.html#
ndb-ndb-pollevents) and nextEvent()
(http://dev.mysql.com/doc/ndbapi/en/ndb-ndb-methods.html#
ndb-ndb-nextevent) when these methods have consumed all available
events, was lost. (Bug #78143, Bug #21660947)
On behalf of the MySQL Release Team,
Balasubramanian Kandasamy
↧
MySQL Cluster 7.5.0 has been released (part 3/3) (no replies)
↧