The NDB storage engine code was not safe for strict-alias optimization in gcc 4.2.1. (Bug #31761)

It was possible in some cases for a node group to be “lost” due to missed local checkpoints following a system restart. (Bug #31525)

A cluster restart could sometimes fail due to an issue with table IDs. (Bug #30975)

A node failure during a local checkpoint could lead to a subsequent failure of the cluster during a system restart. (Bug #31257)

Whenever a TCP send buffer is over 80% full, temporary error 1218 (Send Buffers overloaded in NDB kernel) is now returned. See SendBufferMemory for more information.

When restarting a data node, queries could hang during that node's start phase 5, and continue only after the node had entered phase 6. (Bug #29364)

Disk Data: The number of free extents was incorrectly reported for some tablespaces. (Bug #28642)

Disk Data: Disk data meta-information that existed in ndbd might not be visible to mysqld. (Bug #28720)

Replica redo logs were inconsistently handled during a system restart. (Bug #29354)

When a node failed to respond to a COPY_GCI signal as part of a global checkpoint, the master node was killed instead of the node that actually failed. (Bug #29331)

The wrong data pages were sometimes invalidated following a global checkpoint. (Bug #29067)

If at least 2 files were involved in REDO invalidation, then file 0 of page 0 was not updated and so pointed to an invalid part of the redo log. (Bug #29057)

An invalid comparison made during REDO validation that could lead to an Error while reading REDO log condition. (Bug #29118)

Disk Data: When dropping a page, the stack's bottom entry could sometime be left “cold” rather than “hot”, violating the rules for stack pruning. (Bug #29176)

Memory corruption could occur due to a problem in the DBTUP kernel block. (Bug #29229)

In the event that two data nodes in the same node group and participating in a GCP crashed before they had written their respective P0.sysfile files, QMGR could refuse to start, issuing an invalid Insufficient nodes for restart error instead. (Bug #29167)

Cluster API: NdbApi.hpp depended on ndb_global.h, which was not actually installed, causing the compilation of programs that used NdbApi.hpp to fail. (Bug #35853)

New cluster management client DUMP commands were added to aid in tracking transactions, scan operations, and locks. See DUMP 2350, DUMP 2352, and DUMP 2550.

It is now possible to set the maximum size of the allocation unit for table memory using the MaxAllocate configuration parameter. (Bug #29044)

Important Change: The TimeBetweenWatchdogCheckInitial configuration parameter was added to enable setting of a separate watchdog timeout for memory allocation during startup of the data nodes. (Bug #28899)

A new configuration parameter ODirect causes NDB to attempt using O_DIRECT writes for LCP, backups, and redo logs, often lowering CPU usage.

Having large amounts of memory locked caused swapping to disk. (Bug #28751)

LCP files were not removed following an initial system restart. (Bug #28726)

Disk Data: Repeated INSERT and DELETE operations on a Disk Data table having one or more large VARCHAR columns could cause data nodes to fail. (Bug #20612)

Some unneeded printouts in the ndbd out file were removed.

A new times printout was added in the ndbd watchdog thread.

Setting InitialNoOfOpenFiles equal to MaxNoOfOpenFiles caused an error. This was due to the fact that the actual value of MaxNoOfOpenFiles as used by the cluster was offset by 1 from the value set in config.ini. (Bug #28749)

A corrupt schema file could cause a File already open error. (Bug #28770)

A regression in the heartbeat monitoring code could lead to node failure under high load. This issue affected MySQL 5.1.19 and MySQL Cluster NDB 6.1.10 only. (Bug #28783)

A fast global checkpoint under high load with high usage of the redo buffer caused data nodes to fail. (Bug #28653)

A race condition could result when nonmaster nodes (in addition to the master node) tried to update active status due to a local checkpoint (that is, between NODE_FAILREP and COPY_GCIREQ events). Now only the master updates the active status. (Bug #28717)

Disk Data: When loading data into a cluster following a version upgrade, the data nodes could forcibly shut down due to page and buffer management failures (that is, ndbrequire failures in PGMAN). (Bug #28525)

When an API node sent more than 1024 signals in a single batch, NDB would process only the first 1024 of these, and then hang. (Bug #28443)

Disk Data: The cluster backup process scanned in ACC index order, which had bad effects for disk data. (Bug #28593)

Repeated insertion of data generated by mysqldump into NDB tables could eventually lead to failure of the cluster. (Bug #27437)

Local checkpoint files relating to dropped NDB tables were not removed. (Bug #28348)

Disk Data: Extremely large inserts into Disk Data tables could lead to data node failure in some circumstances. (Bug #27942)

Cluster API: In a multi-operation transaction, a delete operation followed by the insertion of an implicit NULL failed to overwrite an existing value. (Bug #20535)

Incompatible Change; Cluster Replication: The schema for the ndb_apply_status table in the mysql system database has changed. When upgrading to this release from a previous MySQL Cluster NDB 6.x or mainline MySQL 5.1 release, you must drop the mysql.ndb_apply_status table, then restart the server for the table to be re-created with the new schema.

See MySQL Cluster Replication Schema and Tables, for additional information.

Memory usage of a mysqld process grew even while idle. (Bug #27560)

Under some circumstances, a node restart could fail to update the Global Checkpoint Index (GCI). (Bug #28023)

The cluster waited 30 seconds instead of 30 milliseconds before reading table statistics. (Bug #28093)

Performing a delete followed by an insert during a local checkpoint could cause a Rowid already allocated error. (Bug #27205)

An INSERT followed by a delete DELETE on the same NDB table caused a memory leak. (Bug #27756)

References: This bug was introduced by Bug #20612.

Under certain rare circumstances, ndbd could get caught in an infinite loop when one transaction took a read lock and then a second transaction attempted to obtain a write lock on the same tuple in the lock queue. (Bug #28073)

Under certain rare circumstances performing a DROP TABLE or TRUNCATE TABLE on an NDB table could cause a node failure or forced cluster shutdown. (Bug #27581)

Disk Data; Cluster Replication: An issue with replication of Disk Data tables could in some cases lead to node failure. (Bug #28161)

Disk Data: When restarting a data node following the creation of a large number of Disk Data objects (approximately 200 such objects), the cluster could not assign a node ID to the restarting node. (Bug #25741)

Disk Data: Changing a column specification or issuing a TRUNCATE TABLE statement on a Disk Data table caused the table to become an in-memory table.

This fix supersedes an incomplete fix that was made for this issue in MySQL 5.1.15. (Bug #24667, Bug #25296)

Disk Data: Changes to a Disk Data table made as part of a transaction could not be seen by the client performing the changes until the transaction had been committed. (Bug #27757)

Cluster API: An issue with the way in which the Dictionary::listEvents() method freed resources could sometimes lead to memory corruption. (Bug #27663)

Incompatible Change; Cluster Replication: The schema for the ndb_apply_status table in the mysql system database has changed. When upgrading to this release from a previous MySQL Cluster NDB 6.x or mainline MySQL 5.1 release, you must drop the mysql.ndb_apply_status table, then restart the server for the table to be re-created with the new schema.

See MySQL Cluster Replication Schema and Tables, for additional information.

mysqld processes would sometimes crash under high load.

(Bug #26825)

The failure of a data node while restarting could cause other data nodes to hang or crash. (Bug #27003)

mysqld could crash shortly after a data node failure following certain DML operations. (Bug #27169)

It was not possible to set LockPagesInMainMemory equal to 0. (Bug #27291)

When a data node was taking over as the master node, a race condition could sometimes occur as the node was assuming responsibility for handling of global checkpoints. (Bug #27283)

A data node failing while another data node was restarting could leave the cluster in an inconsistent state. In certain rare cases, this could lead to a race condition and the eventual forced shutdown of the cluster. (Bug #27466)

A race condition could sometimes occur if the node acting as master failed while node IDs were still being allocated during startup. (Bug #27286)

The same failed request from an API node could be handled by the cluster multiple times, resulting in reduced performance. (Bug #27087)

Disk Data: DROP INDEX on a Disk Data table did not always move data from memory into the tablespace. (Bug #25877)

Cluster API: A delete operation using a scan followed by an insert using a scan could cause a data node to fail. (Bug #27203)

Cluster API: An issue with the way in which the Dictionary::listEvents() method freed resources could sometimes lead to memory corruption. (Bug #27663)

Incompatible Change; Cluster Replication: The schema for the ndb_apply_status table in the mysql system database has changed. When upgrading to this release from a previous MySQL Cluster NDB 6.x or mainline MySQL 5.1 release, you must drop the mysql.ndb_apply_status table, then restart the server for the table to be re-created with the new schema.

See MySQL Cluster Replication Schema and Tables, for additional information.

mysqld processes would sometimes crash under high load.

(Bug #26825)

Creating a table on one SQL node while in single user mode caused other SQL nodes to crash. (Bug #26997)

An infinite loop in an internal logging function could cause trace logs to fill up with Unknown Signal type error messages and thus grow to unreasonable sizes. (Bug #26720)

Disk Data: When creating a log file group, setting INITIAL_SIZE to less than UNDO_BUFFER_SIZE caused data nodes to crash. (Bug #25743)

An --ndb-wait-connected option has been added for mysqld. When used, it causes mysqld wait a specified amount of time to be connected to the cluster before accepting client connections.

Cluster API: It is now possible to specify the transaction coordinator when starting a transaction. See Ndb::startTransaction(), for more information.

Cluster API: It is now possible to iterate over all existing NDB objects using three new methods of the Ndb_cluster_connection class:

Using only the --print_data option (and no other options) with ndb_restore caused ndb_restore to fail. (Bug #26741)

References: This bug was introduced by Bug #14612.

An inadvertent use of unaligned data caused ndb_restore to fail on some 64-bit platforms, including Sparc and Itanium-2. (Bug #26739)

The ndbd_redo_log_reader utility is now part of the default build. For more information, see ndbd_redo_log_reader — Check and Print Content of Cluster Redo Log.

The ndb_show_tables utility now displays information about table events. See ndb_show_tables — Display List of NDB Tables, for more information.

Cluster API: A new listEvents() method has been added to the Dictionary class.

The InvalidUndoBufferSize error used the same error code (763) as the IncompatibleVersions error. InvalidUndoBufferSize now uses its own error code (779). (Bug #26490)

The LockPagesInMainMemory parameter was not read until after distributed communication had already started between cluster nodes. When the value of this parameter was 1, this could sometimes result in data node failure due to missed heartbeats. (Bug #26454)

An invalid pointer was returned following a FSCLOSECONF signal when accessing the REDO logs during a node restart or system restart. (Bug #26515)

The failure of a data node when restarting it with --initial could lead to failures of subsequent data node restarts. (Bug #26481)

The message Error 0 in readAutoIncrementValue(): no Error was written to the error log whenever SHOW TABLE STATUS was performed on a Cluster table that did not have an AUTO_INCREMENT column.

(Bug #21033)

No appropriate error message was provided when there was insufficient REDO log file space for the cluster to start. (Bug #25801)

Under some circumstances, following the restart of a management node, all data nodes would connect to it normally, but some of them subsequently failed to log any events to the management node. (Bug #26293)

Takeover for local checkpointing due to multiple failures of master nodes was sometimes incorrectly handled. (Bug #26457)

A memory allocation failure in SUMA (the cluster Subscription Manager) could cause the cluster to crash. (Bug #25239)

Disk Data: A memory overflow could occur with tables having a large amount of data stored on disk, or with queries using a very high degree of parallelism on Disk Data tables. (Bug #26514)

Disk Data: Use of a tablespace whose INITIAL_SIZE was greater than 1 GB could cause the cluster to crash. (Bug #26487)

Using node IDs greater than 48 could sometimes lead to incorrect memory access and a subsequent forced shutdown of the cluster. (Bug #26267)

A single cluster can now support up to 255 API nodes, including MySQL servers acting as SQL nodes. See Issues Exclusive to MySQL Cluster, for more information.

A memory leak could cause problems during a node or cluster shutdown or failure. (Bug #25997)

Disk Data; Cluster API: A delete and a read performed in the same operation could cause one or more data nodes to crash. This could occur when the operation affected more than 5 columns concurrently, or when one or more of the columns was of the VARCHAR type and was stored on disk. (Bug #25794)

A new configuration parameter MemReportFrequency enables additional control of data node memory usage. Previously, only warnings at predetermined percentages of memory allocation were given; setting this parameter enables that behavior to be overridden.

When a data node was shut down using the management client STOP command, a connection event (NDB_LE_Connected) was logged instead of a disconnection event (NDB_LE_Disconnected). (Bug #22773)

SELECT statements with a BLOB or TEXT column in the selected column list and a WHERE condition including a primary key lookup on a VARCHAR primary key produced empty result sets. (Bug #19956)

Disk Data: Performing a node restart with a newly dropped Disk Data table could lead to failure of the node during the restart. (Bug #24917)

Disk Data: Repeated CREATE, DROP, or TRUNCATE TABLE in various combinations with system restarts between these operations could lead to the eventual failure of a system restart. (Bug #21948)

Disk Data: MEDIUMTEXT columns of Disk Data tables were stored in memory rather than on disk, even if the columns were not indexed. (Bug #25001)

Disk Data: When restoring from backup a cluster containing any Disk Data tables with hidden primary keys, a node failure resulted which could lead to a crash of the cluster. (Bug #24166)

Disk Data: Extents that should have been available for re-use following a DROP TABLE operation were not actually made available again until after the cluster had performed a local checkpoint. (Bug #17605)

Cluster API: A unique index lookup on a nonexistent tuple could lead to a data node timeout (error 4012). (Bug #25059)

Cluster API: When using the NdbTransaction::execute() method, a very long timeout (greater than 5 minutes) could result if the last data node being polled was disconnected from the cluster. (Bug #24949)

Cluster API: Invoking the NdbTransaction::execute() method using execution type Commit and abort option AO_IgnoreError could lead to a crash of the transaction coordinator (DBTC). (Bug #25090)

Cluster API: Due to an error in the computation of table fragment arrays, some transactions were not executed from the correct starting point. (Bug #24914)