MySQL Lists are EOL. Please join:

List:Packagers« 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

   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.6 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.6/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.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
    https://dev.mysql.com/downloads/cluster/.

    For an overview of changes made in NDB Cluster 7.6, see What
    is New in NDB Cluster 7.6
(http://dev.mysql.com/doc/refman/5.7/en/mysql-cluster-what-is-new-7-6.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.26 (see Changes in MySQL 5.7.26 (2019-04-25, 
General Availability)
(http://dev.mysql.com/doc/relnotes/mysql/5.7/en/news-5-7-26.html)).

Bugs Fixed


      * NDB Disk Data: The error message returned when validation
        of MaxNoOfOpenFiles in relation to
InitialNoOfOpenFiles
        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
manually,
        unable to restart. (Bug #22605467)

      * NDB Cluster APIs: NDB now identifies short-lived
        transactions not needing the reduction of lock
contention
        provided by NdbBlob::close() and no longer invokes
this
        method in cases (such as when autocommit is enabled)
in
        which unlocking merely causes extra work and round
trips
        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
NdbTransaction
        became invalid and when accessed led to failure of
the
        NDB API application. (Bug #29275244)

      * When a pushed join executing in the DBSPJ block had to
        store correlation IDs during query execution, memory
for
        these was allocated for the lifetime of the entire
query
        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
the
        query took sufficiently long to complete, this led
to
        exhaustion of query memory (error 20008). Now in
such
        cases, memory is allocated only for the lifetime of
the
        current result batch, and is freed and made
available for
        re-use following completion of the batch. (Bug
#29336777)
        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
possible
        upgrade paths. Now NDB 7.6 and later are less strict
        about having all new parameters specified explicitly
in
        the configuration which they are served, and use
        hard-coded default values in such cases. (Bug
#28993400)

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

      * 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
potential
        data node failures. To solve this issue, DBACC and
DBLQH
        now check that all dependencies are still valid
before
        attempting to prepare an operation.
        Note
        This fix also supersedes a previous one made for a
        related issue which was originally reported as Bug
        #28500861.
        (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.
(Bug
        #28871889)

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

      * In some cases, one and sometimes more data nodes
        underwent an unplanned shutdown while running
        ndb_restore. This occurred most often, but was not
always
        restircted to, when restoring to a cluster having a
        different number of data nodes from the cluster on
which
        the original backup had been taken.
        The root cause of this issue was exhaustion of the
pool
        of SafeCounter objects, used by the DBDICT kernel
block
        as part of executing schema transactions, and taken
from
        a per-block-instance pool shared with protocols used
for
        NDB event setup and subscription processing. The
        concurrency of event setup and subscription
processing is
        such that the SafeCounter pool can be exhausted;
event
        and subscription processing can handle pool
exhaustion,
        but schema transaction processing could not, which
could
        result in the node shutdown experienced during
        restoration.
        This problem is solved by giving DBDICT schema
        transactions an isolated pool of reserved
SafeCounters
        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
table
        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
be
        applied directly based on the table ID, which could
        ovewrite the autoincrement values stored in SYSTAB_0
for
        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
could
        yield incorrect autoincrement values being restored
when
        multiple instances of ndb_restore were used in
parallel.
        (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
DDL
        statements or queries against INFORMATION_SCHEMA
tables
        while an NDB global schema lock was in effect. (Bug
        #27538139)

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

      * When query memory was exhausted in the DBSPJ kernel block
        while storing correlation IDs for deferred
operations,
        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
NDB
        event API subscribers; when epoch acjknowledgements
from
        one or more subscribers lag by this number of
epochs, an
        asynchronous disconnection is triggered, allowing
the
        data node to release the buffer space used for
        subscriptions. Since this disconnection is
asynchronous,
        it may be the case that it has not completed before
        additional new epochs are completed on the data
node,
        resulting in new epochs not being able to seize GCP
        completion records, generating warnings such as
those
        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
MaxBufferedEpochs
             warning to avoid the
contradictory phrase "100 >
             100".
        (Bug #20344149)

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


Thread
MySQL Cluster 7.6.10 has been releasedLars Tangvald27 Apr 2019