MySQL Forums
Forum List  »  Announcements

MySQL Cluster 7.6.2 dmr has been released
Posted by: Piotr Obrzut
Date: May 08, 2017 08:29AM

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.2 dmr, 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 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.2 (5.7.18-ndb-7.6.2) (2017-04-19,
Development Milestone 2)

   MySQL NDB Cluster 7.6.2 is a new release of NDB 7.6, based on
   MySQL Server 5.7 and including features in version 7.6 of the
   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 bugfixes and changes made
   in previous NDB Cluster releases, as well as all bugfixes and
   feature changes which were added in mainline MySQL 5.7
   through MySQL 5.7.18 (see Changes in MySQL 5.7.18
   (2017-04-10, General Availability)

     * Platform-Specific Notes

     * Functionality Added or Changed

     * Bugs Fixed

   Platform-Specific Notes

     * Solaris: The minimum required version of Solaris is now
       Solaris 11 update 3, due to a dependency on system
       runtime libraries.

     * Solaris: On Solaris, MySQL is now built with Developer
       Studio 12.5 instead of gcc. The binaries require the
       Developer Studio C/C++ runtime libraries to be installed.
       See here for how to install only the libraries:

   Functionality Added or Changed

     * Important Change: As part of an ongoing effort to
       simplify NDB Cluster configuration, memory for indexes is
       now allocated dynamically from DataMemory
       the IndexMemory
       configuration parameter is now deprecated, and is subject
       to removal in a future release. Any memory which has been
       set for IndexMemory in the config.ini file is now
       automatically added to DataMemory. In addition, the
       default value for DataMemory has been increased to 98M,
       and the default for IndexMemory has been decreased to 0.
       In addition to simplifying configuration of NDB
       l), a further benefit of these changes is that scaling up
       by increasing the number of LDM threads is no longer
       limited by having set an insufficiently large value for
       IndexMemory. Previously, it was sometimes the case that
       increasing the number of LDM threads could lead to index
       memory exhaustion while large amounts of DataMemory
       remained available.
       Because instances of the DBACC kernel block (responsible
       for hash index storage) now share memory with each one
       another as well as with DBLQH (the kernel block that acts
       as the local data manager), they can take advantage of
       the fact that scaling up does not increase DataMemory
       usage greatly, and make use of spare memory for indexes
       freely. (For more information about these kernel blocks,
       see The DBACC Block
       and The DBLQH Block
       In other words, index memory is no longer a static quantity
       allocated to each DBACC instance only once, on startupof the
       cluster, but rather this resource can now be allocated and
       deallocated whenever conditions require it.
       Related changes which have been made as part of this work
       are listed here:

          + Several instances of DataMemory usage not related to
            storage of table data now use transaction memory
            instead. These include RT_DBTUP_COPY_PAGE,

          + Data nodes now generate MemoryUsage events (see NDB
            Cluster Log Events
            and writes appropriate messages in the cluster log when resource
            usage reaches 99%,in addition to when it reaches 80%, 90%,
            or 100% as they did previously.

            and other commands which expose memory consumption
            now shows index memory consumption using a page size
            of 32K rather than 8K.

          + IndexMemory is no longer one of the values displayed
            in the ndbinfo.memoryusage
            table's memory_type column.

          + The ndbinfo.resources
            table now shows the DISK_OPERATIONS resource as
            TRANSACTION_MEMORY. The RESERVED resource has been

          + IndexMemory is no longer displayed in ndb_config

     * Performance: A number of debugging statements and
       printouts in the sources for the DBTC and DBLQH kernel
       blocks, as well as in related code, were moved into
       debugging code or removed altogether. This is expected to
       result in an improvement of up to 10% in the performance
       of local data management and transaction coordinator
       threads in many common use cases.

     * ndbinfo Information Database: Added two tables to the
       information database. The config_nodes
       table provides information about nodes that are configured
       as part of a given NDB Cluster, such as node ID and process type.
       The processes
       shows information about nodes currently connected to the cluster;
       this information includes the process name and system process ID,
       and service address. For each data node and SQL node, it also
       shows the process ID of the node's angel process.
       As part of the work done to implement the processes
       table, a new Ndb_cluster_connection
       method set_service_uri()
       is added to the NDB API. For more information, see The
       ndbinfo config_nodes Table
       and The ndbinfo processes Table
       as well as Ndb_cluster_connection::set_service_uri()

     * Added the --query-all
       option to ndb_config
       This option acts much like the --query
       option except that --query-all (short form: -a) dumps
       configuration information for all attributes at one time.
       (Bug #60095, Bug #11766869)

     * Previously, when one LDM thread experienced I/O lag, such
       as during a disk overload condition, it wrote to a local
       checkpoint more slowly---that is, it wrote in I/O lag
       mode. However, other LDM threads did not necessarily
       observe or conform to this state. To ensure that write
       speed for the LCP is reduced by all LDM threads when such
       a slowdown is encountered, NDB now tracks I/O lag mode
       globally, so that I/O lag state is reported as soon as at
       least one thread is writing in I/O lag mode, and thus all
       LDM threads are forced to write in lag mode while the lag
       condition persists. This reduction in write speed by
       other LDM instances should increase overall capacity,
       enabling the disk overload condition to be overcome more
       quickly in such cases than before.

     * Added the ndb_import
       tool to facilitate the loading of CSV-formatted data, such as
       that produced by SELECT INTO OUTFILE
       , into an NDB
       table. ndb_import
       is intended to function much like mysqlimport
       or the LOAD DATA INFILE
       SQL statement, and supports many similar options for
       formatting of the data file. A connection to an NDB
       management server (ndb_mgmd
       is required; there must be an otherwise unused [api] slot
       in the cluster's config.ini file for this purpose. In addition,
       the target database and table (created using the NDB storage
       engine) must already exist, and the name of the CSV file
       (less any file extension) must be the same as that of the
       target table. A running SQL node is needed for creating
       the target database and table, but is not required for
       to function. For more information, see ndb_import ---
       Import CSV Data Into NDB

   Bugs Fixed

     * Partitioning: The output of EXPLAIN PARTITIONS
       displayed incorrect values in the partitions column when
       run on an explicitly partitioned NDB
       table having a large number of partitions.
       This was due to the fact that, when processing an EXPLAIN
       statement, mysqld
       calculates the partition ID for a hash value as
       (hash_value % number_of_partitions), which is correct
       only when the table is partitioned by HASH, since other
       partitioning types use different methods of mapping hash
       values to partition IDs. This fix replaces the partition
       ID calculation performed by mysqld
       ( with
       an internal NDB function which calculates the partition
       ID correctly, based on the table's partitioning type.
       (Bug #21068548)
       References: See also: Bug #25501895, Bug #14672885.

     * Microsoft Windows: When collecting information about CPUs
       on Windows, the Auto-Installer counted only physical
       cores, unlike on other platforms, where it collects
       information about both physical and virtual cores. Now
       the CPU information obtained on Windows is the same as
       that provided on other platforms. (Bug #85209, Bug

     * When ndb_report_thresh_binlog_epoch_slip
       was enabled, an event buffer status message with
       report_reason=LOW/ENOUGH_FREE_EVENTBUFFER was printed in
       the logs when event buffer usage was high and then
       decreased to a lower level. This calculation was based on
       total allocated event buffer memory rather than the limit
       set by ndb_eventbuffer_max_alloc
       it was also printed even when the event buffer had unlimited
       memory (ndb_eventbuffer_max_alloc = 0, the default),
       which could confuse users. This is fixed as follows:

          + The calculation of ndb_eventbuffer_free_percent
            is now based on ndb_eventbuffer_max_alloc, rather than the amount actually allocated.

          + When ndb_eventbuffer_free_percent is set and
            ndb_eventbuffer_max_alloc is equal to 0, event
            buffer status messages using
            report_reason=LOW/ENOUGH_FREE_EVENTBUFFER are no
            longer printed.

          + When ndb_report_thresh_binlog_epoch_slip is set, an
            event buffer status message showing
            report_reason=BUFFERED_EPOCHS_OVER_THRESHOLD is
            written each 10 seconds (rather than every second)
            whenever this is greater than the threshold.
       (Bug #25726723)

     * A bulk update is executed by reading records and
       executing a transaction on the set of records, which is
       started while reading them. When transaction
       initialization failed, the transaction executor function
       was subsequently unaware that this had occurred, leading
       to SQL node failures. This issue is fixed by providing
       appropriate error handling when attempting to initialize
       the transaction. (Bug #25476474)
       References: See also: Bug #20092754.

     * CPU usage of the data node's main thread by the DBDIH
       master block as the end of a local checkpoint could
       approach 100% in certain cases where the database had a
       very large number of fragment replicas. This is fixed by
       reducing the frequency and range of fragment queue
       checking during an LCP. (Bug #25443080)

     * Execution of an online ALTER TABLE ... REORGANIZE
       statement on an NDB table having a primary key
       whose length was greater than 80 bytes led to
       restarting of data nodes, causing the reorganization to
       fail. (Bug #25152165)

     * Multiple data node failures during a partial restart of
       the cluster could cause API nodes to fail. This was due
       to expansion of an internal object ID map by one thread,
       thus changing its location in memory, while another
       thread was still accessing the old location, leading to a
       segmentation fault in the latter thread.
       The internal map() and unmap() functions in which this
       issue arose have now been made thread-safe. (Bug
       References: See also: Bug #25306089.

     * The planned shutdown of an NDB Cluster having more than
       10 data nodes was not always performed gracefully. (Bug

     * Dropped TRANS_AI signals that used the long signal format
       were not handled by the DBTC kernel block. (Bug #85606,
       Bug #25777337)
       References: See also: Bug #85519, Bug #27540805.

     * Iproved pushed join handling by eliminating unneeded
       FLUSH_AI attributes that passed an empty row to the DBSPJ
       kernel block, when a row should be passed to the SPJ API
       only; this reduces the set of AttrInfo projections that
       must be executed in order to produce the result. This
       also makes it possible to employ packed TRANSID_AI
       signals when delivering SPJ API results, which is more
       efficient. (Bug #85525, Bug #25741170)
       References: See also: Bug #85545, Bug #25750355.

     * Use of the long signal format (introduced in NDB 6.4) for
       an incoming TRANSID_AI message is supported by the
       blocks, but the DBTUP block produced long signals only
       when sending to DPSPJ or DBUTIL, and otherwise sent a
       series of short signals instead. Now DBTUP uses long
       signals for such messages whenever the receiving block
       supports this optimization. (Bug #85519, Bug #25740805)

     * To prevent a scan from returning more rows, bytes, or
       both than the client has reserved buffers for, the DBTUP
       kernel block reports the size of the TRANSID_AI it has
       sent to the client in the TUPKEYCONF signal it sends to
       the requesting DBLQH block. DBLQH is aware of the maximum
       batch size available for the result set, and terminates
       the scan batch if this has been exceeded.
       The DBSPJ block's FLUSH_AI attribute allows DBTUP to
       produce two TRANSID_AI results from the same row, one for
       the client, and one for DBSPJ, which is needed for key
       lookups on the joined tables. The size of both of these
       were added to the read length reported by the DBTUP
       block, which caused the controlling DBLQH block to
       believe that it had consumed more of the available
       maximum batch size than was actually the case, leading to
       premature termination of the scan batch which could have
       a negative impact on performance of SPJ scans. To correct
       this, only the actual read length part of an API request
       is now reported in such cases. (Bug #85408, Bug

     * Data node binaries for Solaris 11 built using Oracle
       Developer Studio 12.5 on SPARC platforms failed with bus
       errors. (Bug #85390, Bug #25695818)

     * During the initial phase of a scan request, the DBTC
       kernel block sends a series of DIGETNODESREQ signals to
       the DBDIH block in order to obtain dictionary information
       for each fragment to be scanned. If DBDIH returned
       DIGETNODESREF, the error code from that signal was not
       read, and Error 218 Out of LongMessageBuffer was always
       returned instead. Now in such cases, the error code from
       the DIGETNODESREF signal is actually used. (Bug #85225,
       Bug #25642405)

     * If the user attempts to invoke
       while the Auto-Installer is still running---for example, after
       closing the terminal in which it was started and later
       opening a new terminal and invoking it in the new one---the
       program fails with the error Web server already running, which
       is expected behavior. In such cases, the file must
       first be removed prior to restarting the Auto-Installer (also
       expected behavior). Now when the program fails for this
       reason, the location of is included in the error
       message to simplify this task. (Bug #85169, Bug

     * The planned shutdown of a data node after one or more
       data nodes in the same node group had failed was not
       always performed correctly. (Bug #85168, Bug #25610703)

     * There existed the possibility of a race condition between
       schema operations on the same database object originating
       from different SQL nodes; this could occur when one of
       the SQL nodes was late in releasing its metadata lock on
       the affected schema object or objects in such a fashion
       as to appear to the schema distribution coordinator that
       the lock release was acknowledged for the wrong schema
       change. This could result in incorrect application of the
       schema changes on some or all of the SQL nodes or a
       timeout with repeated waiting max ### sec for
       distributing... messages in the node logs due to failure
       of the distribution protocol. (Bug #85010, Bug #25557263)
       References: See also: Bug #24926009.

     * When a foreign key was added to or dropped from an NDB
       table using an ALTER TABLE
       statement, the parent table's metadata was not updated,
       which made it possible to execute invalid alter
       operations on the parent afterwards.
       Until you can upgrade to this release, you can work
       around this problem by running SHOW CREATE TABLE
       on the parent immediately after adding or dropping
       the foreign key; this statement causes the table's
       metadata to be reloaded. (Bug #82989, Bug #24666177)

     * Transactions on NDB
       tables with cascading foreign keys returned
       inconsistent results when the query cache was also
       enabled, due to the fact that mysqld
       ( was
       not aware of child table updates. This meant that results
       for a later SELECT
       ( from
       the child table were fetched from the query cache, which
       at that point contained stale data.
       This is fixed in such cases by adding all children of the
       parent table to an internal list to be checked by NDB for
       updates whenever the parent is updated, so that mysqld
       ( is
       now properly informed of any updated child tables that
       should be invalidated from the query cache. (Bug #81776,
       Bug #23553507)

     * Solaris; ndbmemcache: ndbmemcache was not built correctly
       on Solaris platforms when compiling NDB Cluster using
       Developer Studio. (Bug #85477, Bug #25730703)

     * NDB Disk Data: In some cases, setting dynamic in-memory
       columns of an NDB Disk Data table to NULL was not handled
       correctly. (Bug #79253, Bug #22195588)

     * NDB Replication: Execution of CREATE TABLE
       ) could in some cases cause the replication slave SQL
       thread to hang. (Bug #85015, Bug #25654833)
       References: This issue is a regression of: Bug #83676,
       Bug #25042101.

On Behalf of the MySQL RE Team
Piotr Obrzut 

Options: ReplyQuote

Written By
MySQL Cluster 7.6.2 dmr has been released
May 08, 2017 08:29AM

Sorry, you can't reply to this topic. It has been closed.

Content reproduced on this site is the property of the respective copyright holders. It is not reviewed in advance by Oracle and does not necessarily represent the opinion of Oracle or any other party.