Dear MySQL Users,

MySQL Cluster is the distributed, shared-nothing variant of MySQL.  This
storage engine provides:

  - In-Memory storage - Real-time performance
  - Transparent Auto-Sharding - Read & write scalability
  - Active-Active/Multi-Master geographic replication
  - 99.999% High Availability with no single point of failure and
    on-line maintenance
  - NoSQL and SQL APIs (including C++, Java, http, Memcached and
    JavaScript/Node.js)

MySQL Cluster 7.4 makes significant advances in performance; operational
efficiency (such as enhanced reporting and faster restarts and upgrades)
and conflict detection and resolution for active-active replication
between MySQL Clusters.

MySQL Cluster 7.4.21, has been released and can be downloaded from

http://www.mysql.com/downloads/cluster/

where you will also find Quick Start guides to help you get your first
MySQL Cluster database up and running.

The release notes are available from

http://dev.mysql.com/doc/relnotes/mysql-cluster/7.4/en/index.html

MySQL Cluster enables users to meet the database challenges of next
generation web, cloud, and communications services with uncompromising
scalability, uptime and agility.

More details can be found at

http://www.mysql.com/products/cluster/

Enjoy !

Changes in MySQL NDB Cluster 7.4.21 (5.6.41-ndb-7.4.21) (2018-07-27,
General Availability)

   MySQL NDB Cluster 7.4.21 is a new release of MySQL NDB Cluster 7.4,
   based on MySQL Server 5.6 and including features in version 7.4 of
   the NDB storage engine, as well as fixing recently discovered bugs in
   previous NDB Cluster releases.

   Obtaining MySQL NDB Cluster 7.4.  MySQL NDB Cluster 7.4 source code
   and binaries can be obtained from
http://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
   (http://dev.mysql.com/doc/refman/5.6/en/mysql-cluster-what-is
<http://dev.mysql.com/doc/refman/5.6/en/mysql-cluster-what-is-new-7-4.html>-new-7-4.html
<http://dev.mysql.com/doc/refman/5.6/en/mysql-cluster-what-is-new-7-4.html>).

   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.41
   (see Changes in MySQL 5.6.41 (Not yet released, General Availability)
   (http://dev.mysql.com/doc/relnotes/mysql/5.6/en/news-5-6-41.html)).

Bugs Fixed


     * NDB Cluster APIs: When Ndb::dropEventOperation() tried to
       clean up a pending event, it failed to clear a pointer to the
       list of GCI operations being deleted and discarded (Gci_ops
       object), so that this pointer referred to a deleted object. GCI
       operations arriving after this could then be inserted as part of
       the next such list belonging to the now-deleted object, leading
       to memory corruption and other issues. (Bug #90011, Bug
       #27675005)

     * NDB attempted to drop subscriptions which had already
       been dropped, leading to a data node shutdown with Error 2341.
       (Bug #27622643)

     * An NDB online backup consists of data, which is fuzzy,
       and a redo and undo log. To restore to a consistent state it is
       necessary to ensure that the log contains all of the changes
       spanning the capture of the fuzzy data portion and beyond to a
       consistent snapshot point. This is achieved by waiting for a GCI
       boundary to be passed after the capture of data is complete, but
       before stopping change logging and recording the stop GCI in the
       backup's metadata.  At restore time, the log is replayed up to
       the stop GCI, restoring the system to the state it had at the
       consistent stop GCI. A problem arose when, under load, it was
       possible to select a GCI boundary which occurred too early and
       did not span all the data captured. This could lead to
       inconsistencies when restoring the backup; these could be be
       noticed as broken constraints or corrupted BLOB entries.  Now the
       stop GCI is chosen is so that it spans the entire duration of the
       fuzzy data capture process, so that the backup log always
       contains all data within a given stop GCI. (Bug #27497461)
       References: See also: Bug #27566346.


On Behalf of MySQL Release Engineering team,
Surabhi Bhat