MySQL Cluster 7.5.5 has been released

[Jocelyn Ramilison]

Dear MySQL Users,

MySQL Cluster 7.5.5 (GA) is a GA release for MySQL Cluster 7.5.

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

  - In-Memory storage - Real-time performance (with optional
    checkpointing to disk)
  - 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.5.5, 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.5/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.5.5 (5.7.17-ndb-7.5.5) (2017-01-17)

   MySQL Cluster NDB 7.5.5 is a new release of MySQL Cluster NDB
   7.5, based on MySQL Server 5.7 and including features in
   version 7.5 of the NDB
   (http://dev.mysql.com/doc/refman/5.7/en/mysql-cluster.html)
   storage engine, as well as fixing recently discovered bugs in
   previous MySQL Cluster releases.

   Obtaining MySQL Cluster NDB 7.5.  MySQL Cluster NDB 7.5
   source code and binaries can be obtained from
   http://dev.mysql.com/downloads/cluster/.

   For an overview of changes made in MySQL Cluster NDB 7.5, see
   What is New in MySQL NDB Cluster 7.5
   (http://dev.mysql.com/doc/refman/5.7/en/mysql-cluster-what-is-new.html).

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

   Bugs Fixed

     * Packaging: The RPM installer for the MySQL Cluster
       auto-installer package had a dependency on python2-crypt
       instead of python-crypt. (Bug #24924607)

     * Microsoft Windows: Installation failed when the
       Auto-Installer (ndb_setup.py) was run on a Windows host
       that used Swedish as the system language. This was due to
       system messages being issued using the cp1252 character
       set; when these messages contained characters that did
       not map directly to 7-bit ASCII (such as the ä character
       in Tjänsten ... startar), conversion to UTF-8---as
       expected by the Auto-Installer web client---failed.
       This fix has been tested only with Swedish as the system
       language, but should work for Windows systems set to
       other European languages that use the cp1252 character
       set. (Bug #83870, Bug #25111830)

     * No traces were written when ndbmtd received a signal in
       any thread other than the main thread, due to the fact
       that all signals were blocked for other threads. This
       issue is fixed by the removal of SIGBUS, SIGFPE, SIGILL,
       and SIGSEGV signals from the list of signals being
       blocked. (Bug #25103068)

     * 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
       (http://dev.mysql.com/doc/refman/5.7/en/create-database.html)
       or DROP DATABASE
       (http://dev.mysql.com/doc/refman/5.7/en/drop-database.html)
       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
       (http://dev.mysql.com/doc/refman/5.7/en/mysql-cluster.html)
       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
       (http://dev.mysql.com/doc/refman/5.7/en/create-table.html)
       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)

     * The NDB binlog injector thread used an injector mutex to
       perform two important tasks:

         1. Protect against client threads creating or dropping
            events whenever the injector thread waited for
            pollEvents().

         2. Maintain access to data shared by the injector
            thread with client threads.
       The first of these could hold the mutex for long periods
       of time (on the order of 10ms), while locking it again
       extremely quickly. This could keep it from obtaining the
       lock for data access ("starved") for unnecessarily great
       lengths of time.
       To address these problems, the injector mutex has been
       refactored into two---one to handle each of the two tasks
       just listed.
       It was also found that initialization of the binlog
       injector thread held the injector mutex in several places
       unnecessarily, when only local thread data was being
       initialized and sent signals with condition information
       when nothing being waited for was updated. These unneeded
       actions have been removed, along with numerous previous
       temporary fixes for related injector mutex starvation
       issues. (Bug #83676, Bug #83127, Bug #25042101, Bug
       #24715897)
       References: See also: Bug #82680, Bug #20957068, Bug
       #24496910.

     * When ndbmtd was built on Solaris/SPARC with version 5.3
       of the GNU tools, data nodes using the resulting binary
       failed during startup. (Bug #83500, Bug #24941880)
       References: See also: Bug #83517, Bug #24947597.

     * MySQL Cluster failed to compile using GCC 6. (Bug #83308,
       Bug #24822203)

     * When a data node was restarted, the node was first
       stopped, and then, after a fixed wait, the management
       server assumed that the node had entered the NOT_STARTED
       state, at which point, the node was sent a start signal.
       If the node was not ready because it had not yet
       completed stopping (and was therefore not actually in
       NOT_STARTED), the signal was silently ignored.
       To fix this issue, the management server now checks to
       see whether the data node has in fact reached the
       NOT_STARTED state before sending the start signal. The
       wait for the node to reach this state is split into two
       separate checks:

          + Wait for data nodes to start shutting down (maximum
            12 seconds)

          + Wait for data nodes to complete shutting down and
            reach NOT_STARTED state (maximum 120 seconds)
       If either of these cases times out, the restart is
       considered failed, and an appropriate error is returned.
       (Bug #49464, Bug #11757421)

     * CMake now avoids configuring the
       -fexpensive-optimizations option for GCC versions for
       which the option triggers faulty shift-or optimizations.
       (Bug #24947597, Bug #83517)

On Behalf of the MySQL/ORACLE RE Team
Hery Ramilison