MySQL Cluster 7.4.15 has been released

[Sreedhar S]

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.15, 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.15 (5.6.36-ndb-7.4.15) (2017-04-10,
General Availability)


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

   Bugs Fixed

     * Partitioning: The output of EXPLAIN PARTITIONS displayed
       incorrect values in the partitions column when run on an
       explicitly partitioned NDB table having a large number of
       partitions.
       This was due to the fact that, when processing an EXPLAIN
       statement, mysqld calculates the partition ID for a hash
       value as (hash_value % number_of_partitions), which is
       correct only when the table is partitioned by HASH, since
       other partitioning types use different methods of mapping
       hash values to partition IDs. This fix replaces the
       partition ID calculation performed by mysqld with an
       internal NDB function which calculates the partition ID
       correctly, based on the table's partitioning type. (Bug
       #21068548)
       References: See also: Bug #25501895, Bug #14672885.

     * CPU usage of the data node's main thread by the DBDIH
       master block as the end of a local checkpoint could
       approach 100% in certain cases where the database had a
       very large number of fragment replicas. This is fixed by
       reducing the frequency and range of fragment queue
       checking during an LCP. (Bug #25443080)

     * The ndb_print_backup_file utility failed when attempting
       to read from a backup file when the backup included a
       table having more than 500 columns. (Bug #25302901)
       References: See also: Bug #25182956.

     * Multiple data node failures during a partial restart of
       the cluster could cause API nodes to fail. This was due
       to expansion of an internal object ID map by one thread,
       thus changing its location in memory, while another
       thread was still accessing the old location, leading to a
       segmentation fault in the latter thread.
       The internal map() and unmap() functions in which this
       issue arose have now been made thread-safe. (Bug
       #25092498)
       References: See also: Bug #25306089.

     * There existed the possibility of a race condition between
       schema operations on the same database object originating
       from different SQL nodes; this could occur when one of
       the SQL nodes was late in releasing its metadata lock on
       the affected schema object or objects in such a fashion
       as to appear to the schema distribution coordinator that
       the lock release was acknowledged for the wrong schema
       change. This could result in incorrect application of the
       schema changes on some or all of the SQL nodes or a
       timeout with repeated waiting max ### sec for
       distributing... messages in the node logs due to failure
       of the distribution protocol. (Bug #85010, Bug #25557263)
       References: See also: Bug #24926009.

     * When a foreign key was added to or dropped from an NDB
       table using an ALTER TABLE statement, the parent table's
       metadata was not updated, which made it possible to
       execute invalid alter operations on the parent
       afterwards.
       Until you can upgrade to this release, you can work
       around this problem by running SHOW CREATE TABLE on the
       parent immediately after adding or dropping the foreign
       key; this statement causes the table's metadata to be
       reloaded. (Bug #82989, Bug #24666177)

     * Transactions on NDB tables with cascading foreign keys
       returned inconsistent results when the query cache was
       also enabled, due to the fact that mysqld was not aware
       of child table updates. This meant that results for a
       later SELECT from the child table were fetched from the
       query cache, which at that point contained stale data.
       This is fixed in such cases by adding all children of the
       parent table to an internal list to be checked by NDB for
       updates whenever the parent is updated, so that mysqld is
       now properly informed of any updated child tables that
       should be invalidated from the query cache. (Bug #81776,
       Bug #23553507)

     * NDB Disk Data: Stale data from NDB Disk Data tables that
       had been dropped could potentially be included in backups
       due to the fact that disk scans were enabled for these.
       To prevent this possibility, disk scans are now
       disabled---as are other types of scans---when taking a
       backup. (Bug #84422, Bug #25353234)

     * NDB Disk Data: In some cases, setting dynamic in-memory
       columns of an NDB Disk Data table to NULL was not handled
       correctly. (Bug #79253, Bug #22195588)

On Behalf of MySQL Release Engineering Team,
-Sreedhar S