MySQL Cluster 7.4.14 has been released

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 
<http://dev.mysql.com/doc/refman/5.6/en/mysql-cluster-what-is-new-7-4.html>
-is-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 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 
<http://dev.mysql.com/doc/relnotes/mysql/5.6/en/news-5-6-35.html>
-5-6-35.html 
<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