MySQL Lists are EOL. Please join:

List:General Discussion« Previous MessageNext Message »
From:Hery Ramilison Date:October 17 2015 7:36am
Subject:MySQL Cluster 7.4.8 has been released
View as plain text  
Dear MySQL Users,

MySQL Cluster 7.4.8 (Milestone Release) is a public milestone
release for MySQL Cluster 7.4.

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.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.8 DMR can be downloaded from the "Development
Releases" tab at

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

MySQL Cluster enables users to meet the database challenges of next
generation web, cloud, and communications services with uncompromising
scalability, uptime and agility.

As with any other pre-production release, caution should be taken when
installing on production level systems or systems with critical data.
More information on the Development Milestone Release process can be
found at

More details can be found at

Enjoy !

Changes in MySQL Cluster NDB 7.4.8 (5.6.27-ndb-7.4.8 2015-10-16)

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

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

    For an overview of changes made in MySQL Cluster NDB 7.4, see
    MySQL Cluster Development in MySQL Cluster NDB 7.4

    This release also incorporates all bugfixes and changes made
    in previous MySQL Cluster releases, as well as all bugfixes
    and feature changes which were added in mainline MySQL 5.6
    through MySQL 5.6.27 (see Changes in MySQL 5.6.27

    Functionality Added or Changed

      * Important Change; Cluster Replication: Added the
        create_old_temporals server system variable to compliment
        the system variables avoid_temporal_upgrade and
        show_old_temporals introduced in MySQL 5.6.24 and
        available in MySQL Cluster beginning with NDB 7.3.9 and
        NDB 7.4.6. Enabling create_old_temporals causes mysqld to
        use the storage format employed prior to MySQL 5.6.4 when
        creating any DATE, DATETIME, or TIMESTAMP column---that
        is, the column is created without any support for
        fractional seconds. create_old_temporals is disabled by
        default. The system variable is read-only; to enable the
        use of pre-5.6.4 temporal types, set the equivalent
        option (--create-old-temporals) on the command line, or
        in an option file read by the MySQL server.
        create_old_temporals is available only in MySQL Cluster;
        it is not supported in the standard MySQL 5.6 server. It
        is intended to facilitate upgrades from MySQL Cluster NDB
        7.2 to MySQL Cluster NDB 7.3 and 7.4, after which table
        columns of the affected types can be upgraded to the new
        storage format. create_old_temporals is deprecated and
        scheduled for removal in a future version of MySQL
        avoid_temporal_upgrade must also be enabled for this
        feature to work properly. You should also enable
        show_old_temporals as well. For more information, see the
        descriptions of these variables. For more about the
        changes in MySQL's temporal types, see Storage
        Requirements for Date and Time Types
        nts.html#data-types-storage-reqs-date-time). (Bug
        References: See also Bug #21492598, Bug #72997, Bug

      * When the --database option has not been specified for
        ndb_show_tables, and no tables are found in the TEST_DB
        database, an appropriate warning message is now issued.
        (Bug #78379, Bug #11758430)

    Bugs Fixed

      * Important Change: When ndb_restore was run without
        --disable-indexes or --rebuild-indexes on a table having
        a unique index, it was possible for rows to be restored
        in an order that resulted in duplicate values, causing it
        to fail with duplicate key errors. Running ndb_restore on
        such a table now requires using at least one of these
        options; failing to do so now results in an error. (Bug
        #57782, Bug #11764893)

      * Important Change; Cluster API: The MGM API error-handling
        functions ndb_mgm_get_latest_error(),
        ndb_mgm_get_latest_error_msg(), and
        ndb_mgm_get_latest_error_desc() each failed when used
        with a NULL handle. You should note that, although these
        functions are now null-safe, values returned in this case
        are arbitrary and not meaningful. (Bug #78130, Bug

      * mysql_upgrade failed when performing an upgrade from
        MySQL Cluster NDB 7.2 to MySQL Cluster NDB 7.4. The root
        cause of this issue was an accidental duplication of code
        in mysql_fix_privilege_tables.sql that caused
        ndbinfo_offline mode to be turned off too early, which in
        turn led a subsequent CREATE VIEW statement to fail. (Bug

      * ClusterMgr is a internal component of NDB API and
        ndb_mgmd processes, part of TransporterFacade---which in
        turn is a wrapper around the transporter registry---and
        shared with data nodes. This component is responsible for
        a number of tasks including connection setup requests;
        sending and monitoring of heartbeats; provision of node
        state information; handling of cluster disconnects and
        reconnects; and forwarding of cluster state indicators.
        ClusterMgr maintains a count of live nodes which is
        incremented on receiving a report of a node having
        connected (reportConnected() method call), and
        decremented on receiving a report that a node has
        disconnected (reportDisconnected()) from
        TransporterRegistry. This count is checked within
        reportDisconnected() to verify that is it greater than
        The issue addressed here arose when node connections were
        very brief due to send buffer exhaustion (among other
        potential causes) and the check just described failed.
        This occurred because, when a node did not fully connect,
        it was still possible for the connection attempt to
        trigger a reportDisconnected() call in spite of the fact
        that the connection had not yet been reported to
        ClusterMgr; thus, the pairing of reportConnected() and
        reportDisconnected() calls was not guaranteed, which
        could cause the count of connected nodes to be set to
        zero even though there remained nodes that were still in
        fact connected, causing node crashes with debug builds of
        MySQL Cluster, and potential errors or other adverse
        effects with release builds.
        To fix this issue, ClusterMgr::reportDisconnected() now
        verifies that a disconnected node had actually finished
        connecting completely before checking and decrementing
        the number of connected nodes. (Bug #21683144)
        References: See also Bug #21664515, Bug #21651400.

      * To reduce the possibility that a node's loopback
        transporter becomes disconnected from the transporter
        registry by reportError() due to send buffer exhaustion
        (implemented by the fix for Bug #21651400), a portion of
        the send buffer is now reserved for the use of this
        transporter. (Bug #21664515)
        References: See also Bug #21683144.

      * The loopback transporter is similar to the TCP
        transporter, but is used by a node to send signals to
        itself as part of many internal operations. Like the TCP
        transporter, it could be disconnected due to certain
        conditions including send buffer exhaustion, but this
        could result in blocking of TransporterFacade and so
        cause multiple issues within an ndb_mgmd or API node
        process. To prevent this, a node whose loopback
        transporter becomes disconnected is now simply shut down,
        rather than allowing the node process to hang. (Bug
        References: See also Bug #21683144, Bug #21664515.

      * The internal NdbEventBuffer object's active subscriptions
        count (m_active_op_count) could be decremented more than
        once when stopping a subscription when this action
        failed, for example, due to a busy server and was
        retried. Decrementing of this count could also fail when
        communication with the data node failed, such as when a
        timeout occurred. (Bug #21616263)
        References: This bug is a regression of Bug #20575424,
        Bug #20561446.

      * In some cases, the management server daemon failed on
        startup without reporting the reason. Now when ndb_mgmd
        fails to start due to an error, the error message is
        printed to stderr. (Bug #21571055)

      * In a MySQL Cluster with multiple LDM instances, all
        instances wrote to the node log, even inactive instances
        on other nodes. During restarts, this caused the log to
        be filled with messages from other nodes, such as the
        messages shown here:
        2015-06-24 00:20:16 [ndbd] INFO     -- We are adjusting Max Disk 
Write Speed,
        a restart is ongoing now
        2015-06-24 01:08:02 [ndbd] INFO     -- We are adjusting Max Disk 
Write Speed,
        no restarts ongoing anymore

        Now this logging is performed only by the active LDM
        instance. (Bug #21362380)

      * Backup block states were reported incorrectly during
        backups. (Bug #21360188)
        References: See also Bug #20204854, Bug #21372136.

      * Added the BackupDiskWriteSpeedPct data node parameter.
        Setting this parameter causes the data node to reserve a
        percentage of its maximum write speed (as determined by
        the value of MaxDiskWriteSpeed) for use in local
        checkpoints while performing a backup.
        BackupDiskWriteSpeedPct is interpreted as a percentage
        which can be set between 0 and 90 inclusive, with a
        default value of 50. (Bug #20204854)
        References: See also Bug #21372136.

      * When a data node is known to have been alive by other
        nodes in the cluster at a given global checkpoint, but
        its sysfile reports a lower GCI, the higher GCI is used
        to determine which global checkpoint the data node can
        recreate. This caused problems when the data node being
        started had a clean file system (GCI = 0), or when it was
        more than more global checkpoint behind the other nodes.
        Now in such cases a higher GCI known by other nodes is
        used only when it is at most one GCI ahead. (Bug
        References: See also Bug #20334650, Bug #21899993. This
        bug was introduced by Bug #29167.

      * When restoring a specific database or databases with the
        --include-databases or --exclude-databases option,
        ndb_restore attempted to apply foreign keys on tables in
        databases which were not among those being restored. (Bug

      * After restoring the database schema from backup using
        ndb_restore, auto-discovery of restored tables in
        transactions having multiple statements did not work
        correctly, resulting in Deadlock found when trying to get
        lock; try restarting transaction errors.
        This issue was encountered both in the mysql client, as
        well as when such transactions were executed by
        application programs using Connector/J and possibly other
        MySQL APIs.
        Prior to upgrading, this issue can be worked around by
        all SQL nodes following the restore operation, before
        executing any other statements. (Bug #18075170)

      * ndb_desc used with the --extra-partition-info and
        --blob-info options failed when run against a table
        containing one or more TINYBLOB. columns. (Bug #14695968)

      * Operations relating to global checkpoints in the internal
        event data buffer could sometimes leak memory. (Bug
        #78205, Bug #21689380)
        References: See also Bug #76165, Bug #20651661.

      * Trying to create an NDB table with a composite foreign
        key referencing a composite primary key of the parent
        table failed when one of the columns in the composite
        foreign key was the table's primary key and in addition
        this column also had a unique key. (Bug #78150, Bug

      * When attempting to enable index statistics, creation of
        the required system tables, events and event
        subscriptions often fails when multiple mysqld processes
        using index statistics are started concurrently in
        conjunction with starting, restarting, or stopping the
        cluster, or with node failure handling. This is normally
        recoverable, since the affected mysqld process or
        processes can (and do) retry these operations shortly
        thereafter. For this reason, such failures are no longer
        logged as warnings, but merely as informational events.
        (Bug #77760, Bug #21462846)

      * Adding a unique key to an NDB table failed when the table
        already had a foreign key. Prior to upgrading, you can
        work around this issue by creating the unique key first,
        then adding the foreign key afterwards, using a separate
        ALTER TABLE statement. (Bug #77457, Bug #20309828)

      * Cluster Replication: When using conflict detection and
        resolution with NDB$EPOCH2_TRANS()
        on-ndb-epoch2-trans), delete-delete conflicts were not
        handled in a transactional manner. (Bug #20713499)

      * Cluster API: While executing dropEvent(), if the
        coordinator DBDICT failed after the subscription manager
        (SUMA block) had removed all subscriptions but before the
        coordinator had deleted the event from the system table,
        the dropped event remained in the table, causing any
        subsequent drop or create event with the same name to
        fail with NDB error 1419 Subscription already dropped or
        error 746 Event name already exists. This occurred even
        when calling dropEvent() with a nonzero force argument.
        Now in such cases, error 1419 is ignored, and DBDICT
        deletes the event from the table. (Bug #21554676)

      * Cluster API: If the total amount of memory allocated for
        the event buffer exceeded approximately 40 MB, the
        calculation of memory usage percentages could overflow
        during computation. This was due to the fact that the
        associated routine used 32-bit arithmetic; this has now
        been changed to use Uint64 values instead. (Bug #78454,
        Bug #21847552)

      * Cluster API: The nextEvent2() method continued to return
        exceptional events such as TE_EMPTY, TE_INCONSISTENT, and
        TE_OUT_OF_MEMORY for event operations which already had
        been dropped. (Bug #78167, Bug #21673318)

      * Cluster API: After the initial restart of a node
        following a cluster failure, the cluster failure event
        added as part of the restart process was deleted when an
        event that existed prior to the restart was later
        deleted. This meant that, in such cases, an Event API
        client had no way of knowing that failure handling was
        needed. In addition, the GCI used for the final cleanup
        of deleted event operations, performed by pollEvents()
        and nextEvent() when these methods have consumed all
        available events, was lost. (Bug #78143, Bug #21660947)

      * Cluster API: The internal value representing the latest
        global checkpoint was not always updated when a completed
        epoch of event buffers was inserted into the event queue.
        This caused subsequent calls to Ndb::pollEvents() and
        pollEvents2() to fail when trying to obtain the correct
        GCI for the events available in the event buffers. This
        could also result in later calls to nextEvent() or
        nextEvent2() seeing events that had not yet been
        discovered. (Bug #78129, Bug #21651536)

On Behalf of the MySQL/ORACLE RE Team
Hery Ramilison
MySQL Cluster 7.4.8 has been releasedHery Ramilison17 Oct