MySQL Cluster 7.5.11 has been released

[Lars Tangvald]

Dear MySQL Users,

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.11, 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.

MySQL Cluster 7.5 is also available from our repository for Linux
platforms, go here for details:

  http://dev.mysql.com/downloads/repo/

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.11 (5.7.23-ndb-7.5.11) (2018-07-27, General Availability)

   MySQL NDB Cluster 7.5.11 is a new release of MySQL NDB
   Cluster 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 NDB Cluster releases.

   Obtaining MySQL NDB Cluster 7.5.  MySQL NDB Cluster 7.5
   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.5, see
   What is New in NDB Cluster 7.5
(http://dev.mysql.com/doc/refman/5.7/en/mysql-cluster-what-is-new-7-5.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.7
   through MySQL 5.7.23 (see Changes in MySQL 5.7.23 (2018-07-27, General Availability)
(http://dev.mysql.com/doc/relnotes/mysql/5.7/en/news-5-7-23.html)).

Bugs Fixed


     * ndbinfo Information Database: It was possible following a
       restart for (sometimes incomplete) fallback data to be
       used in populating the ndbinfo.processes
(http://dev.mysql.com/doc/refman/5.7/en/mysql-cluster-ndbinfo-processes.html)
       table, which could lead to rows in
       this table with empty process_name values. Such fallback
       data is no longer used for this purpose. (Bug #27985339)

     * MySQL NDB ClusterJ: ClusterJ could not be built from
       source using JDK 9. (Bug #27977985)

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

     * An NDB
       (http://dev.mysql.com/doc/refman/5.7/en/mysql-cluster.html)
       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 (http://dev.mysql.com/doc/refman/5.7/en/blob.html)
       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.

     * For NDB tables, when a foreign key was added or dropped
       as a part of a DDL statement, the foreign key metatdata
       for all parent tables referenced should be reloaded in
       the handler on all SQL nodes connected to the cluster,
       but this was done only on the mysqld on which the
       statement was executed. Due to this, any subsequent
       queries relying on foreign key metadata from the
       corresponding parent tables could return inconsistent
       results. (Bug #27439587)
       References: See also: Bug #82989, Bug #24666177.

     * The internal function BitmaskImpl::setRange() set one bit
       fewer than specified. (Bug #90648, Bug #27931995)

     * It was not possible to create an NDB
       (http://dev.mysql.com/doc/refman/5.7/en/mysql-cluster.html)
       table using PARTITION_BALANCE set to
       FOR_RA_BY_LDM_X_2, FOR_RA_BY_LDM_X_3, or
       FOR_RA_BY_LDM_X_4. (Bug #89811, Bug #27602352)
       References: This issue is a regression of: Bug #81759,
       Bug #23544301.

     * When the internal function
       ha_ndbcluster::copy_fk_for_offline_alter() checked
       dependent objects on a table from which it was supposed
       to drop a foreign key, it did not perform any filtering
       for foreign keys, making it possible for it to attempt
       retrieval of an index or trigger instead, leading to a
       spurious Error 723 (No such table).

     * During the execution of CREATE TABLE ... IF NOT EXISTS
       (http://dev.mysql.com/doc/refman/5.7/en/create-table.html),
       the internal open_table() function calls
       ha_ndbcluster::get_default_num_partitions() implicitly
       whenever open_table() finds out that the requested table
       already exists. In certain cases,
       get_default_num_partitions() was called without the
       associated thd_ndb object being initialized, leading to
       failure of the statement with MySQL error 157 Could not
       connect to storage engine. Now
       get_default_num_partitions() always checks for the
       existence of this thd_ndb object, and initializes it if
       necessary.