Web lists-archives.com

MySQL Cluster 7.4.8 has been released

Dear MySQL Users,

MySQL Cluster 7.4.8 (General Availability) is a new 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 General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe:    http://lists.mysql.com/mysql