MySQL Lists are EOL. Please join:

List:General Discussion« Previous MessageNext Message »
From:Lars Tangvald Date:April 27 2019 9:23am
Subject:MySQL Cluster 7.6.10 has been released
View as plain text  
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.6.10 has been released and can be downloaded from

where you will also find Quick Start guides to help you get your
first MySQL Cluster database up and running.

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

The release notes are available from

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

Enjoy !

Changes in MySQL NDB Cluster 7.6.10 (5.7.26-ndb-7.6.10) (2019-04-26, 
General Availability)

    MySQL NDB Cluster 7.6.10 is a new release of NDB 7.6, based
    on MySQL Server 5.7 and including features in version 7.6 of
    the NDB storage engine, as well as fixing recently discovered
    bugs in previous NDB Cluster releases.

    Obtaining NDB Cluster 7.6.  NDB Cluster 7.6 source code and
    binaries can be obtained from

    For an overview of changes made in NDB Cluster 7.6, see What
    is New in NDB Cluster 7.6

    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.26 (see Changes in MySQL 5.7.26 (2019-04-25, 
General Availability)

Bugs Fixed

      * NDB Disk Data: The error message returned when validation
        of MaxNoOfOpenFiles in relation to
        failed has been improved to make the nature of the
        problem clearer to users. (Bug #28943749)

      * NDB Disk Data: Repeated execution of ALTER TABLESPACE ...
        ADD DATAFILE against the same tablespace caused data
        nodes to hang and left them, after being killed
        unable to restart. (Bug #22605467)

      * NDB Cluster APIs: NDB now identifies short-lived
        transactions not needing the reduction of lock
        provided by NdbBlob::close() and no longer invokes
        method in cases (such as when autocommit is enabled)
        which unlocking merely causes extra work and round
        to be performed prior to committing or aborting the
        transaction. (Bug #29305592)
        References: See also: Bug #49190, Bug #11757181.

      * NDB Cluster APIs: When the most recently failed operation
        was released, the pointer to it held by
        became invalid and when accessed led to failure of
        NDB API application. (Bug #29275244)

      * When a pushed join executing in the DBSPJ block had to
        store correlation IDs during query execution, memory
        these was allocated for the lifetime of the entire
        execution, even though these specific correlation
IDs are
        required only when producing the most recent batch
in the
        result set. Subsequent batches require additional
        correlation IDs to be stored and allocated; thus, if
        query took sufficiently long to complete, this led
        exhaustion of query memory (error 20008). Now in
        cases, memory is allocated only for the lifetime of
        current result batch, and is freed and made
available for
        re-use following completion of the batch. (Bug
        References: See also: Bug #26995027.

      * API and data nodes running NDB 7.6 and later could not
        use an existing parsed configuration from an earlier
        release series due to being overly strict with
regard to
        having values defined for configuration parameters
new to
        the later release, which placed a restriction on
        upgrade paths. Now NDB 7.6 and later are less strict
        about having all new parameters specified explicitly
        the configuration which they are served, and use
        hard-coded default values in such cases. (Bug

      * Added DUMP 406 (NdbfsDumpRequests) to provide NDB file
        system information to global checkpoint and local
        checkpoint stall reports in the node logs. (Bug

      * A race condition between the DBACC and DBLQH kernel
        blocks occurred when different operations in a
        transaction on the same row were concurrently being
        prepared and aborted. This could result in DBTUP
        attempting to prepare an operation when a preceding
        operation had been aborted, which was unexpected and
        could thus lead to undefined behavior including
        data node failures. To solve this issue, DBACC and
        now check that all dependencies are still valid
        attempting to prepare an operation.
        This fix also supersedes a previous one made for a
        related issue which was originally reported as Bug
        (Bug #28893633)

      * The ndbinfo.cpustat table reported inaccurate information
        regarding send threads. (Bug #28884157)

      * Execution of an LCP_COMPLETE_REP signal from the master
        while the LCP status was IDLE led to an assertion.

      * Issuing a STOP command in the ndb_mgm client caused
        ndbmtd processes which had recently been added to
        cluster to hang in Phase 4 during shutdown. (Bug

      * In some cases, one and sometimes more data nodes
        underwent an unplanned shutdown while running
        ndb_restore. This occurred most often, but was not
        restircted to, when restoring to a cluster having a
        different number of data nodes from the cluster on
        the original backup had been taken.
        The root cause of this issue was exhaustion of the
        of SafeCounter objects, used by the DBDICT kernel
        as part of executing schema transactions, and taken
        a per-block-instance pool shared with protocols used
        NDB event setup and subscription processing. The
        concurrency of event setup and subscription
processing is
        such that the SafeCounter pool can be exhausted;
        and subscription processing can handle pool
        but schema transaction processing could not, which
        result in the node shutdown experienced during
        This problem is solved by giving DBDICT schema
        transactions an isolated pool of reserved
        which cannot be exhausted by concurrent NDB event
        activity. (Bug #28595915)

      * After a commit failed due to an error, mysqld shut down
        unexpectedly while trying to get the name of the
        involved. This was due to an issue in the internal
        function ndbcluster_print_error(). (Bug #28435082)

      * ndb_restore did not restore autoincrement values
        correctly when one or more staging tables were in
use. As
        part of this fix, we also in such cases block
applying of
        the SYSTAB_0 backup log, whose content continued to
        applied directly based on the table ID, which could
        ovewrite the autoincrement values stored in SYSTAB_0
        unrelated tables. (Bug #27917769, Bug #27831990)
        References: See also: Bug #27832033.

      * ndb_restore employed a mechanism for restoring
        autoincrement values which was not atomic, and thus
        yield incorrect autoincrement values being restored
        multiple instances of ndb_restore were used in
        (Bug #27832033)
        References: See also: Bug #27917769, Bug #27831990.

      * Neither the MAX_EXECUTION_TIME optimizer hint nor the
        max_execution_time system variable was respected for
        statements or queries against INFORMATION_SCHEMA
        while an NDB global schema lock was in effect. (Bug

      * An NDB table having both a foreign key on another NDB
        table using ON DELETE CASCADE and one or more TEXT
        BLOB columns leaked memory. (Bug #27484882)

      * When query memory was exhausted in the DBSPJ kernel block
        while storing correlation IDs for deferred
        the query was aborted with error status 20000 Query
        aborted due to out of query memory. (Bug #26995027)
        References: See also: Bug #86537.

      * MaxBufferedEpochs is used on data nodes to avoid
        excessive buffering of row changes due to lagging
        event API subscribers; when epoch acjknowledgements
        one or more subscribers lag by this number of
epochs, an
        asynchronous disconnection is triggered, allowing
        data node to release the buffer space used for
        subscriptions. Since this disconnection is
        it may be the case that it has not completed before
        additional new epochs are completed on the data
        resulting in new epochs not being able to seize GCP
        completion records, generating warnings such as
        shown here:
     [ndbd] ERROR    -- c_gcp_list.seize() failed...


     [ndbd] WARNING  -- ACK wo/ gcp record...

        And leading to the following warning:
     Disconnecting node %u because it has exceeded MaxBufferedEpochs
     (100 > 100), epoch ....

        This fix performs the following modifications:

           + Modifies the size of the GCP
completion record pool
             to ensure that there
is always some extra headroom
             to account for the
asynchronous nature of the
             disconnect processing
previously described, thus
             avoiding c_gcp_list
seize failures.

           + Modifies the wording of the
             warning to avoid the
contradictory phrase "100 >
        (Bug #20344149)

      * When executing the redo log in debug mode it was possible
        for a data node to fail when deallocating a row.
        #93273, Bug #28955797)

MySQL Cluster 7.6.10 has been releasedLars Tangvald27 Apr