MySQL Cluster 7.4.14 has been released

[Sreedhar Sreedhargadda]

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.14, 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.14 (5.6.35-ndb-7.4.14) (2017-01-17
, General Availability)

   MySQL NDB Cluster 7.4.14 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-new-7-4.html).

   This release also incorporates all bugfixes and changes made
   in previous NDB Cluster releases, as well as all bugfixes and
   feature changes which were added in mainline MySQL 5.6
   through MySQL 5.6.35 (see Changes in MySQL 5.6.35
   (2016-12-12, General Availability)
   (http://dev.mysql.com/doc/relnotes/mysql/5.6/en/news
    -5-6-35.html)).

   Bugs Fixed

     * ndb_restore did not restore tables having more than 341
       columns correctly. This was due to the fact that the
       buffer used to hold table metadata read from .ctl files
       was of insufficient size, so that only part of the table
       descriptor could be read from it in such cases. This
       issue is fixed by increasing the size of the buffer used
       by ndb_restore for file reads. (Bug #25182956)

     * Queries against the ndbinfo.memory_per_fragment table
       when running with a large number of data nodes could
       produce unexpected results for the highest-numbered
       nodes. (Bug #25176404)

     * The rand() function was used to produce a unique table ID
       and table version needed to identify a schema operation
       distributed between multiple SQL nodes, relying on the
       assumption that rand() would never produce the same
       numbers on two different instances of mysqld. It was
       later determined that this is not the case, and that in
       fact it is very likely for the same random numbers to be
       produced on all SQL nodes.
       This fix removes the usage of rand() for producing a
       unique table ID or version, and instead uses a sequence
       in combination with the node ID of the coordinator. This
       guarantees uniqueness until the counter for the sequence
       wraps, which should be sufficient for this purpose.
       The effects of this duplication could be observed as
       timeouts in the log (for example NDB create db: waiting
       max 119 sec for distributing) when restarting multiple
       mysqld processes simultaneously or nearly so, or when
       issuing the same CREATE DATABASE or DROP DATABASE
       statement on multiple SQL nodes. (Bug #24926009)

     * The ndb_show_tables utility did not display type
       information for hash maps or fully replicated triggers.
       (Bug #24383742)

     * Long message buffer exhaustion when firing immediate
       triggers could result in row ID leaks; this could later
       result in persistent RowId already allocated errors (NDB
       Error 899). (Bug #23723110)
       References: See also: Bug #19506859, Bug #13927679.

     * when a parent NDB table in a foreign key relationship was
       updated, the update cascaded to a child table as
       expected, but the change was not cascaded to a child
       table of this child table (that is, to a grandchild of
       the original parent). This can be illustrated using the
       tables generated by the following CREATE TABLE
       statements:
       CREATE TABLE parent(
       id INT PRIMARY KEY AUTO_INCREMENT,
       col1 INT UNIQUE, col2 INT
       ) ENGINE NDB;

       CREATE TABLE child( ref1 INT UNIQUE,
       FOREIGN KEY fk1(ref1)
       REFERENCES parent(col1) ON UPDATE CASCADE
       ) ENGINE NDB;

       CREATE TABLE grandchild( ref2 INT,
       FOREIGN KEY fk2(ref2)
       REFERENCES child(ref1) ON UPDATE CASCADE
       ) ENGINE NDB;

       Table child is a child of table parent; table grandchild
       is a child of table child, and a grandchild of parent. In
       this scenario, a change to column col1 of parent cascaded
       to ref1 in table child, but it was not always propagated
       in turn to ref2 in table grandchild. (Bug #83743, Bug
       #25063506)

     * When a data node running with StopOnError set to 0
       underwent an unplanned shutdown, the automatic restart
       performed the same type of start as the previous one. In
       the case where the data node had previously been started
       with the --initial option, this meant that an initial
       start was performed, which in cases of multiple data node
       failures could lead to loss of data. This issue also
       occurred whenever a data node shutdown led to generation
       of a core dump. A check is now performed to catch all
       such cases, and to perform a normal restart instead.
       In addition, in cases where a failed data node was unable
       prior to shutting down to send start phase information to
       the angel process, the shutdown was always treated as a
       startup failure, also leading to an initial restart. This
       issue is fixed by adding a check to execute startup
       failure handling only if a valid start phase was received
       from the client. (Bug #83510, Bug #24945638)

On behalf of the MySQL Release Team
-Sreedhar S