MySQL Forums
Forum List  »  Announcements

MySQL Cluster 7.6.3 dmr has been released
Posted by: Piotr Obrzut
Date: July 05, 2017 05:11AM

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.3 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 7.6.3 dmr is also available from our repository for Linux
platforms, go here for details:

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.3 (5.7.18-ndb-7.6.3) (2017-07-03, Development Milestone 3)

   MySQL NDB Cluster 7.6.3 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

   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)

     * Packaging Notes

     * Functionality Added or Changed

     * Bugs Fixed

   Packaging Notes

     * mysqladmin was added to Docker/Minimal packages because
       it is needed by InnoDB Cluster. (Bug #25998285)

   Functionality Added or Changed

     * NDB Replication: Added the --ndb-log-update-minimal
       option for logging by mysqld. This option causes only
       primary key values to be written in the before image, and
       only changed columns in the after image. (Bug #24438868)

     * In some critical situations such as data node failure, it
       was possible for the volume of log messages produced to
       cause file system and other issues, which compounded the
       problem, due to the fact that these messages were logged
       synchronously using stdout. To keep this from happening,
       log messages from worker threads now use a log buffer
       instead, which is non-blocking, and thus much less likely
       to cause interference with other processes under such
       conditions. (Bug #24748843)

     * Added the --diff-default option for ndb_config. This
       option causes the program to print only those parameters
       having values that differ from their defaults. (Bug
       #85831, Bug #25844166)

     * Added the ndb_top program on unix-based platforms. This
       utility shows CPU load and usage information for an NDB
       data node, with periodic updates (each second, by
       default). The display is in text or color ASCII graph
       format; both formats can be displayed at the same time.
       It is also possible to disable color output for the
       ndb_top connects to an NDB Cluster SQL node---that is, a
       MySQL Server---and for this reason must be able to
       connect as a MySQL user having the SELECT privilege on
       tables in the ndbinfo database.
       ndb_top is not currently available for Windows platforms.
       For more information, see ndb_top --- View CPU usage
       information for NDB threads


   Bugs Fixed

     * Packaging: Two missing dependencies were added to the apt

          + The data node package requires

          + The auto-installer requires python-paramiko
       (Bug #85679, Bug #25799465)

     * NDB Disk Data: If the tablespace for a disk table had
       been fully consumed when a node failed, and table rows
       were deleted and inserted---or updated with shrinking or
       expanding disk column values---while the node was
       unavailable, a subsequent restart could fail with error
       1601 Out of extents, tablespace full. We prevent this
       from happening by reserving 4 percent of the tablespace
       for use during node starts. (Bug #25923125)

     * NDB Replication: Added a check to stop an NDB replication
       slave when configuration as a multi-threaded slave is
       detected (for example, if slave_parallel_workers is set
       to a nonzero value). (Bug #21074209)

     * NDB Cluster APIs: The implementation method
       NdbDictionary::NdbTableImpl::getColumn(), used from many
       places in the NDB API where a column is referenced by
       name, has been made more efficient. This method used a
       linear search of an array of columns to find the correct
       column object, which could be inefficient for tables with
       many columns, and was detected as a significant use of
       CPU in customer applications. (Ideally, users should
       perform name-to-column object mapping, and then use
       column IDs or objects in method calls, but in practice
       this is not always done.) A less costly hash index
       implementation, used previously for the name lookup, is
       reinstated for tables having relatively many columns. (A
       linear search continues to be used for tables having
       fewer columns, where the difference in performance is
       neglible.) (Bug #24829435)

     * NDB Cluster APIs: NDB error 631 is reclassified as the
       (temporary) node recovery error Scan take over error,
       restart scan transaction. This was previously exposed to
       applications as an internal (and permanent) error which
       provided no description. (Bug #86401, Bug #26116231)

     * MySQL NDB ClusterJ: The JTie and NDB JTie tests were
       skipped when the unit tests for ClusterJ were being run.
       (Bug #26088583)

     * Backup .log files contained log entries for one or more
       extra fragments, due to an issue with filtering out
       changes logged by other nodes in the same node group.
       This resulted in a larger .log file and thus use of more
       resources than necessary; it could also cause problems
       when restoring, since backups from different nodes could
       interfere with one another while the log was being
       applied. (Bug #25891014)

     * Memory exhaustion during fragment creation led to an
       unplanned shutdown of the cluster. This issue could be
       triggered by the addition of unique keys to a large
       number of columns at the same time. (Bug #25851801)

     * When making the final write to a redo log file, it is
       expected that the next log file is already opened for
       writes, but this was not always the case with a slow
       disk, leading to node failure. Now in such cases NDB
       waits for the next file to be opened properly before
       attempting to write to it. (Bug #25806659)

     * Data node threads can be bound to a single CPU or a set
       of CPUs, a set of CPUs being represented internally by
       NDB as a SparseBitmask. When attempting to lock to a set
       of CPUs, CPU usage was excessive due to the fact that the
       routine performing the locks used the
       mt_thr_config.cpp::do_bind() method, which looks for bits
       that are set over the entire theoretical range of the
       SparseBitmask (2^32-2, or 4294967294). This is fixed by
       using SparseBitmask::getBitNo(), which can be used to
       iterate over only those bits that are actually set,
       instead. (Bug #25799506)

     * Setting NoOfFragmentLogParts such that there were more
       than 4 redo log parts per local data manager led to
       resource exhaustion and subsequent multiple data node
       failures. Since this is an invalid configuration, a check
       has been added to detect a configuration with more than 4
       redo log parts per LDM, and reject it as invalid. (Bug

     * In certain cases, a failed ALTER TABLE ... ADD UNIQUE KEY
       statement could lead to SQL node failure. (Bug #24444878)
       References: This issue is a regression of: Bug #23089566.

     * Error 240 is raised when there is a mismatch between
       foreign key trigger columns and the values supplied to
       them during trigger execution, but had no error message
       indicating the source of the problem. (Bug #23141739)
       References: See also: Bug #23068914, Bug #85857.

     * If the number of LDM blocks was not evenly divisible by
       the number of TC/SPJ blocks, SPJ requests were not
       equally distributed over the available SPJ instances. Now
       a round-robin distribution is used to distribute SPJ
       requests across all available SPJ instances more
       As part of this work, a number of unused member variables
       have been removed from the class Dbtc. (Bug #22627519)

     * ALTER TABLE .. MAX_ROWS=0 can now be performed only by
       using a copying ALTER TABLE statement. Resetting MAX_ROWS
       to 0 can no longer be performed using ALGORITHM=INPLACE.
       (Bug #21960004)

     * During a system restart, when a node failed due to having
       missed sending heartbeats, all other nodes reported only
       that another node had failed without any additional
       information. Now in such cases, the fact that heartbeats
       were missed and the ID of the node that failed to send
       heartbeats is reported in both the error log and the data
       node log. (Bug #21576576)

     * Due to a previous issue with unclear separation between
       the optimize and execute phases when a query involved a
       GROUP BY, the join-pushable evaluator was not sure
       whether its optimized query execution plan was in fact
       pushable. For this reason, such grouped joins were always
       considered not pushable. It has been determined that the
       separation issue has been resolved by work already done
       in MySQL 5.6, and so we now remove this limitation. (Bug
       #86623, Bug #26239591)

     * When deleting all rows from a table immediately followed
       by DROP TABLE, it was possible that the shrinking of the
       DBACC hash index was not ready prior to the drop. This
       shrinking is a per-fragment operation that does not check
       the state of the table. When a table is dropped, DBACC
       releases resources, during which the description of the
       fragment size and page directory is not consistent; this
       could lead to reads of stale pages, and undefined
       Inserting a great many rows followed by dropping the
       table should also have had such effects due to expansion
       of the hash index.
       To fix this problem we make sure, when a fragment is
       about to be released, that there are no pending expansion
       or shrinkage operations on this fragment. (Bug #86449,
       Bug #26138592)

     * Some error messages still referred to IndexMemory,
       although that parameter has been deprecated. (Bug #86385,
       Bug #26107514)

     * The internal function execute_signals() in mt.cpp read
       three section pointers from the signal even when none was
       passed to it. This was mostly harmless, although
       unneeded. When the signal read was the last one on the
       last page in the job buffer, and the next page in memory
       was not mapped or otherwise accessible, ndbmtd failed
       with an error. To keep this from occurring, this function
       now only reads section pointers that are actually passed
       to it. (Bug #86354, Bug #26092639)

     * There was at most one attempt in Dbacc to remove hash
       index pages freed when a table was dropped. This meant
       that, for large partitions (32 pages or more) there were
       always some pages lost. Now all hash index pages are
       freed when table using them is dropped. (Bug #86247, Bug

     * When a query on an NDB table failed due to a foreign key
       constraint violation, no useful information about the
       foreign key was shown in the error message, which
       contained only the text Unknown error code. (Bug #86241,
       Bug #26029485, Bug #16371292)
       References: See also: Bug #16275684.

     * The ndb_show_tables program --unqualified option did not
       work correctly when set to 0 (false); this should disable
       the option and so cause fully qualified table and index
       names to be printed in the output. (Bug #86017, Bug

     * When an NDB table with foreign key constraints is
       created, its indexes are created first, and then, during
       foreign key creation, these indexes are loaded into the
       NDB dictionary cache. When a CREATE TABLE statement
       failed due to an issue relating to foreign keys, the
       indexes already in the cache were not invalidated. This
       meant that any subsequent CREATE TABLE with any indexes
       having the same names as those in the failed statement
       produced inconsistent results. Now, in such cases, any
       indexes named in the failed CREATE TABLE are immediately
       invalidated from the cache. (Bug #85917, Bug #25882950)

     * During a local checkpoint, the record size is obtained
       from the DBTUP kernel block. This record size remained in
       use until the LCP scan was completed, which made it
       possible for DBTUP to update the maximum record size on
       commit of an ALTER TABLE that added a column to the
       table, and which could lead to node failure during the
       LCP. Now the record size is fetched at a point where
       updating it does not lead to this condition. (Bug #85858,
       Bug #25860002)

     * Attempting to execute ALTER TABLE ... ADD FOREIGN KEY
       when the key to be added had the name of an existing
       foreign key on the same table failed with the wrong error
       message. (Bug #85857, Bug #23068914)

     * The node internal scheduler (in mt.cpp) collects
       statistics about its own progress and any outstanding
       work it is performing. One such statistic is the number
       of outstanding send bytes, collected in
       send_buffer::m_node_total_send_buffer_size. This
       information may later be used by the send thread
       scheduler, which uses it as a metric to tune its own send
       performance versus latency.
       In order to reduce lock contention on the internal send
       buffers, they are split into two thr_send_buffer parts,
       m_buffer and m_sending, each protected by its own mutex,
       and their combined size repesented by
       Investigation of the code revealed that there was no
       consistency as to which mutex was used to update
       m_node_total_send_buffer_size, with the result that there
       was no consurrency protection for this value. To avoid
       this, m_node_total_send_buffer_size is replaced with two
       values, m_buffered_size and m_sending_size, which keep
       separate track of the sizes of the two buffers. These
       counters are updated under the protection of two
       different mutexes protecting each buffer individually,
       and are now added together to obtain the total size.
       With concurrency control established, updates of the
       partial counts should now be correct, so that their
       combined value no longer accumulates errors over time.
       (Bug #85687, Bug #25800933)

     * Enabled the use of short or packed short TRANSID_AI
       signals for sending results from DBSPJ back to the client
       API. (Bug #85545, Bug #25750355)
       References: See also: Bug #85525, Bug #25741170.

     * The maximum BatchByteSize as sent in SCANREQ signals was
       not always set correctly to reflect a limited byte size
       available in the client result buffers. The result buffer
       size calculation has been modified such that the
       effective batch byte size accurately reflects the maximum
       that may be returned by data nodes to prevent a possible
       overflow of the result buffers. (Bug #85411, Bug

     * When compiling the NDB kernel with gcc version 6.0.0 or
       later, it is now built using -flifetime-dse=1. (Bug
       #85381, Bug #25690926)

On Behalf of the MySQL RE Team
Piotr Obrzut

Options: ReplyQuote

Written By
MySQL Cluster 7.6.3 dmr has been released
July 05, 2017 05:11AM

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.