MySQL Cluster 7.5.11 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 (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.



-- 
MySQL Announce Mailing List
For list archives: http://lists.mysql.com/announce
To unsubscribe:    http://lists.mysql.com/announce