MySQL Cluster 7.2.18 has been released

Murthy Narkedimilli <[email protected]>
Newsgroups gmane.comp.db.mysql.announce,gmane.comp.db.mysql.general,gmane.comp.db.mysql.packagers
Message-ID <[email protected]>
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, and Memcached)
  - Active-Active/Multi-Master geographic replication

MySQL Cluster 7.2.18, 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.2/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.2.18 (5.5.40-ndb-7.2.18) (2014-10-16)

    MySQL Cluster NDB 7.2.18 is a new release of MySQL Cluster,
    incorporating new features in the NDB storage engine, and fixing
    recently discovered bugs in previous MySQL Cluster NDB 7.2
    development releases.

    Obtaining MySQL Cluster NDB 7.2.  MySQL Cluster NDB 7.2 source
    code and binaries can be obtained from
http://dev.mysql.com/downloads/cluster/.

    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.5 through
    MySQL 5.5.40 (see Changes in MySQL 5.5.40 (2014-09-22)
(http://dev.mysql.com/doc/relnotes/mysql/5.5/en/news-5-5-40.html))

    Functionality Added or Changed

      * Added the --exclude-missing-tables option for ndb_restore.
        When enabled, the option causes tables present in the backup
        but not in the target database to be ignored. (Bug #57566, Bug
        #11764704)

    Bugs Fixed

      * When assembling error messages of the form Incorrect state for
        node n state: node_state, written when the transporter failed
        to connect, the node state was used in place of the node ID in
        a number of instances, which resulted in errors of this type
        for which the node state was reported incorrectly. (Bug
        #19559313, Bug #73801)

      * In some cases, transporter receive buffers were reset by one
        thread while being read by another. This happened when a race
        condition occurred between a thread receiving data and another
        thread initiating disconnect of the transporter (disconnection
        clears this buffer). Concurrency logic has now been
        implemented to keep this race from taking place. (Bug
        #19554279, Bug #73656)

      * The failure of a data node could in some situations cause a
        set of API nodes to fail as well due to the sending of a
        CLOSE_COMREQ signal that was sometimes not completely
        initialized. (Bug #19513967)

      * A more detailed error report is printed in the event of a
        critical failure in one of the NDB internal sendSignal*()
        methods, prior to crashing the process, as was already
        implemented for sendSignal(), but was missing from the more
        specialized sendSignalNoRelease() method. Having a crash of
        this type correctly reported can help with identifying
        configuration hardware issues in some cases. (Bug #19414511)
        References: See also Bug #19390895.

      * ndb_restore failed to restore the cluster's metadata when
        there were more than approximately 17 K data objects. (Bug
        #19202654)

      * Parallel transactions performing reads immediately preceding a
        delete on the same tuple could cause the NDB kernel to crash.
        This was more likely to occur when separate TC threads were
        specified using the ThreadConfig configuration parameter. (Bug
        #19031389)

      * Attribute promotion between different TEXT types (any of
        TINYTEXT, TEXT, MEDIUMTEXT, and LONGTEXT) by ndb_restore was
        not handled properly in some cases. In addition, TEXT values
        are now truncated according to the limits set by mysqld (for
        example, values converted to TINYTEXT from another type are
        truncated to 256 bytes). In the case of columns using a
        multibyte character set, the value is truncated to the end of
        the last well-formed character.
        Also as a result of this fix, conversion to a TEXT column of
        any size that uses a different character set from the original
        is now disallowed. (Bug #18875137)

      * The NDB optimized node recovery mechanism attempts to transfer
        only relevant page changes to a starting node in order to
        speed the recovery process; this is done by having the
        starting node indicate the index of the last global checkpoint
        (GCI) in which it participated, so that the node that was
        already running copies only data for rows which have changed
        since that GCI. Every row has a GCI metacolumn which
        facilitates this; for a deleted row, the slot formerly stpring
        this row's data contains a GCI value, and for deleted pages,
        every row on the missing page is considered changed and thus
        needs to be sent.
        When these changes are received by the starting node, this
        node performs a lookup for the page and index to determine
        what they contain. This lookup could cause a real underlying
        page to be mapped against the logical page ID, even when this
        page contained no data.
        One way in which this issue could manifest itself occurred
        after cluster DataMemory usage approached maximum, and
        deletion of many rows followed by a rolling restart of the
        data nodes was performed with the expectation that this would
        free memory, but in fact it was possible in this scenario for
        memory not to be freed and in some cases for memory usage
        actually to increase to its maximum.
        This fix solves these issues by ensuring that a real physical
        page is mapped to a logical ID during node recovery only when
        this page contains actual data which needs to be stored. (Bug
        #18683398, Bug #18731008)

      * mysqld failed while attempting a read removal before a delete
        with an index merge. This occurred only when a quick select
        was also generated for the delete operation. During read
        removal, the index from the quick select is used to access the
        table structure. In this case, because the delete uses an
        index merge, the quick select index is set to MAX_KEY instead
        of a valid index value, which led to a bad pointer (which was
        then dereferenced).
        The fix for this problem adds a check so that read removal
        before delete is not attempted if the quick select index has a
        value of MAX_KEY. (Bug #18487960)

      * When a data node sent a MISSING_DATA signal due to a buffer
        overflow and no event data had yet been sent for the current
        epoch, the dummy event list created to handle this
        inconsistency was not deleted after the information in the
        dummy event list was transferred to the completed list. (Bug
        #18410939)

      * Incorrect calculation of the next autoincrement value
        following a manual insertion towards the end of a cached range
        could result in duplicate values sometimes being used. This
        issue could manifest itself whne using certain combinations of
        values for auto_increment_increment, auto_increment_offset,
        and ndb_batch_prefetch_sz.
        This issue has been fixed by modifying this calculation to
        ensure that the next value from the cache as computed by NDB
        is of the form auto_increment_offset + (N *
        auto_increment_increment. This avoids any rounding up by the
        MySQL Server of the returned value, which could result in
        duplicate entries when the rounded-up value fell outside the
        range of values cached by NDB. (Bug #17893872)

      * ndb_show_tables --help output contained misleading information
        about the --database (-d) option. In addition, the long form
        of the option (--database) did not work properly. (Bug
        #17703874)

      * Using the --help option with ndb_print_file caused the program
        to segfault. (Bug #17069285)

      * For multithreaded data nodes, some threads do communicate
        often, with the result that very old signals can remain at the
        top of the signal buffers. When performing a thread trace, the
        signal dumper calculated the latest signal ID from what it
        found in the signal buffers, which meant that these old
        signals could be erroneously counted as the newest ones. Now
        the signal ID counter is kept as part of the thread state, and
        it is this value that is used when dumping signals for trace
        files. (Bug #73842, Bug #19582807)

      * Cluster API: The fix for Bug #16723708 stopped the
        ndb_logevent_get_next() function from casting a log event's
        ndb_mgm_event_category to an enum type, but this change
        interfered with existing applications, and so the function's
        original behavior is now reinstated. A new MGM API function
        exhibiting the corrected behavior ndb_logevent_get_next2() has
        been added in this release to take the place of the reverted
        function, for use in applications that do not require backward
        compatibility. In all other respects apart from this, the new
        function is identical with its predecessor. (Bug #18354165)

      * ClusterJ: Retrieval of values from BLOB and TEXT columns by
        ClusterJ column accessor methods was not handled correctly.
        (Bug #18419468, Bug #19028487)

On behalf of Oracle/MySQL RE Team,
Murthy Narkedimilli

-- 
MySQL Announce Mailing List
For list archives: http://lists.mysql.com/announce
To unsubscribe:    http://lists.mysql.com/announce
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.