MySQL Cluster 7.4.14 has been released
Posted by: Sreedhar Sreedhargadda
Date: January 17, 2017 10:38AM
Date: January 17, 2017 10:38AM
Dear MySQL Users, MySQL Cluster is the distributed, shared-nothing variant of MySQL. This storage engine provides: - In-Memory storage - Real-time performance - 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.14, 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 NDB Cluster 7.4.14 (5.6.35-ndb-7.4.14) (2017-01-17 , General Availability) MySQL NDB Cluster 7.4.14 is a new release of MySQL NDB 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 NDB Cluster releases. Obtaining MySQL NDB Cluster 7.4. MySQL NDB Cluster 7.4 source code and binaries can be obtained from http://dev.mysql.com/downloads/cluster/. For an overview of changes made in MySQL NDB Cluster 7.4, see What is New in NDB Cluster 7.4 (http://dev.mysql.com/doc/refman/5.6/en/mysql-cluster-what -is-new-7-4.html). 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.6 through MySQL 5.6.35 (see Changes in MySQL 5.6.35 (2016-12-12, General Availability) (http://dev.mysql.com/doc/relnotes/mysql/5.6/en/news -5-6-35.html)). Bugs Fixed * ndb_restore did not restore tables having more than 341 columns correctly. This was due to the fact that the buffer used to hold table metadata read from .ctl files was of insufficient size, so that only part of the table descriptor could be read from it in such cases. This issue is fixed by increasing the size of the buffer used by ndb_restore for file reads. (Bug #25182956) * Queries against the ndbinfo.memory_per_fragment table when running with a large number of data nodes could produce unexpected results for the highest-numbered nodes. (Bug #25176404) * The rand() function was used to produce a unique table ID and table version needed to identify a schema operation distributed between multiple SQL nodes, relying on the assumption that rand() would never produce the same numbers on two different instances of mysqld. It was later determined that this is not the case, and that in fact it is very likely for the same random numbers to be produced on all SQL nodes. This fix removes the usage of rand() for producing a unique table ID or version, and instead uses a sequence in combination with the node ID of the coordinator. This guarantees uniqueness until the counter for the sequence wraps, which should be sufficient for this purpose. The effects of this duplication could be observed as timeouts in the log (for example NDB create db: waiting max 119 sec for distributing) when restarting multiple mysqld processes simultaneously or nearly so, or when issuing the same CREATE DATABASE or DROP DATABASE statement on multiple SQL nodes. (Bug #24926009) * The ndb_show_tables utility did not display type information for hash maps or fully replicated triggers. (Bug #24383742) * Long message buffer exhaustion when firing immediate triggers could result in row ID leaks; this could later result in persistent RowId already allocated errors (NDB Error 899). (Bug #23723110) References: See also: Bug #19506859, Bug #13927679. * when a parent NDB table in a foreign key relationship was updated, the update cascaded to a child table as expected, but the change was not cascaded to a child table of this child table (that is, to a grandchild of the original parent). This can be illustrated using the tables generated by the following CREATE TABLE statements: CREATE TABLE parent( id INT PRIMARY KEY AUTO_INCREMENT, col1 INT UNIQUE, col2 INT ) ENGINE NDB; CREATE TABLE child( ref1 INT UNIQUE, FOREIGN KEY fk1(ref1) REFERENCES parent(col1) ON UPDATE CASCADE ) ENGINE NDB; CREATE TABLE grandchild( ref2 INT, FOREIGN KEY fk2(ref2) REFERENCES child(ref1) ON UPDATE CASCADE ) ENGINE NDB; Table child is a child of table parent; table grandchild is a child of table child, and a grandchild of parent. In this scenario, a change to column col1 of parent cascaded to ref1 in table child, but it was not always propagated in turn to ref2 in table grandchild. (Bug #83743, Bug #25063506) * When a data node running with StopOnError set to 0 underwent an unplanned shutdown, the automatic restart performed the same type of start as the previous one. In the case where the data node had previously been started with the --initial option, this meant that an initial start was performed, which in cases of multiple data node failures could lead to loss of data. This issue also occurred whenever a data node shutdown led to generation of a core dump. A check is now performed to catch all such cases, and to perform a normal restart instead. In addition, in cases where a failed data node was unable prior to shutting down to send start phase information to the angel process, the shutdown was always treated as a startup failure, also leading to an initial restart. This issue is fixed by adding a check to execute startup failure handling only if a valid start phase was received from the client. (Bug #83510, Bug #24945638) On behalf of the MySQL Release Team -Sreedhar S
Subject
Views
Written By
Posted
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.