MySQL Lists are EOL. Please join:

List:Announcements« Previous MessageNext Message »
From:Balasubramanian Kandasamy Date:February 26 2015 2:33pm
Subject:MySQL Cluster 7.4.4 has been released
View as plain text  
Dear MySQL Users,

MySQL Cluster 7.4.4 (GA) is a first GA 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.4 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.

The release notes are available from

http://dev.mysql.com/doc/relnotes/mysql-cluster/7.4/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 Cluster NDB 7.4.4 (5.6.23-ndb-7.4.4) (2015-02-26, 
General Availability)

    MySQL Cluster NDB 7.4.4 is a new release of MySQL Cluster,
    based on MySQL Server 5.6 and including features under
    development for version 7.4 of the NDB storage engine, as
    well as fixing a number of 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
http://dev.mysql.com/downloads/cluster/.

    For an overview of changes made in MySQL Cluster NDB 7.4, see
    MySQL Cluster Development in MySQL Cluster NDB 7.4
    (http://dev.mysql.com/doc/refman/5.6/en/mysql-cluster-develop 
<http://dev.mysql.com/doc/refman/5.6/en/mysql-cluster-development-5-6-ndb-7-4.html>
ment-5-6-ndb-7-4.html 
<http://dev.mysql.com/doc/refman/5.6/en/mysql-cluster-development-5-6-ndb-7-4.html>).

    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.23 (see Changes in MySQL 5.6.23
    (2015-02-02)
    (http://dev.mysql.com/doc/relnotes/mysql/5.6/en/news-5-6-23.h 
<http://dev.mysql.com/doc/relnotes/mysql/5.6/en/news-5-6-23.html>
tml <http://dev.mysql.com/doc/relnotes/mysql/5.6/en/news-5-6-23.html>)).

    Bugs Fixed

      * The values of the Ndb_last_commit_epoch_server and
        Ndb_last_commit_epoch_session status variables were
        incorrectly reported on some platforms. To correct this
        problem, these values are now stored internally as long
        long, rather than long. (Bug #20372169)

      * When a data node fails or is being restarted, the
        remaining nodes in the same nodegroup resend to
        subscribers any data which they determine has not already
        been sent by the failed node. Normally, when a data node
        (actually, the SUMA kernel block) has sent all data
        belonging to an epoch for which it is responsible, it
        sends a SUB_GCP_COMPLETE_REP signal, together with a
        count, to all subscribers, each of which responds with a
        SUB_GCP_COMPLETE_ACK. When SUMA receives this
        acknowledgment from all subscribers, it rports this to
        the other nodes in the same nodegroup so that they know
        that there is no need to resend this data in case of a
        subsequent node failure. If a node failed before all
        subscribers sent this acknowledgement but before all the
        other nodes in the same nodegroup received it from the
        failing node, data for some epochs could be sent (and
        reported as complete) twice, which could lead to an
        unplanned shutdown.
        The fix for this issue adds to the count reported by
        SUB_GCP_COMPLETE_ACK a list of identifiers which the
        receiver can use to keep track of which buckets are
        completed and to ignoreany duplicate reported for an
        already completed bucket. (Bug #17579998)

      * The output format of SHOW CREATE TABLE for an NDB table
        containing foreign key constraints did not match that for
        the equivalent InnoDB table, which could lead to issues
        with some third-party applications. (Bug #75515, Bug
        #20364309)

      * An ALTER TABLE statement containing comments and a
        partitioning option against an NDB table caused the SQL
        node on which it was executed to fail. (Bug #74022, Bug
        #19667566)

      * Cluster API: When a transaction is started from a cluster
        connection, Table and Index schema objects may be passed
        to this transaction for use. If these schema objects have
        been acquired from a different connection
        (Ndb_cluster_connection object), they can be deleted at
        any point by the deletion or disconnection of the owning
        connection. This can leave a connection with invalid
        schema objects, which causes an NDB API application to
        fail when these are dereferenced.
        To avoid this problem, if your application uses multiple
        connections, you can now set a check to detect sharing of
        schema objects between connections when passing a schema
        object to a transaction, using the
        NdbTransaction::setSchemObjectOwnerChecks() method added
        in this release. When this check is enabled, the schema
        objects having the same names are acquired from the
        connection and compared to the schema objects passed to
        the transaction. Failure to match causes the application
        to fail with an error. (Bug #19785977)

      * Cluster API: The increase in the default number of
        hashmap buckets (DefaultHashMapSize API node
        configuration parameter) from 240 to 3480 in MySQL
        Cluster NDB 7.2.11 increased the size of the internal
        DictHashMapInfo::HashMap type considerably. This type was
        allocated on the stack in some getTable() calls which
        could lead to stack overflow issues for NDB API users.
        To avoid this problem, the hashmap is now dynamically
        allocated from the heap. (Bug #19306793)

On behalf of Oracle/MySQL RE Team
Balasubramanian Kandasamy

Thread
MySQL Cluster 7.4.4 has been releasedBalasubramanian Kandasamy26 Feb