This is a new source release, fixing recently discovered bugs in previous MySQL Cluster releases.
MySQL Cluster NDB 6.3 no longer in development. MySQL Cluster NDB 6.3 is no longer being actively developed; if you are using a MySQL Cluster NDB 6.3 release, you should upgrade to the latest version of MySQL Cluster, which is available from http://dev.mysql.com/downloads/cluster/ .
Obtaining MySQL Cluster NDB 6.3. This is a source-only release, which you must compile and install using the instructions found in Installing MySQL from Source, and in MySQL Cluster Installation and Upgrades. You can download the GPL source tarball from the MySQL FTP site at ftp://ftp.mysql.com/pub/mysql/download/cluster_telco/.
This release incorporates all bugfixes and changes made in the previous MySQL Cluster NDB 6.3 release, as well as all bugfixes and feature changes which were added in mainline MySQL 5.1 through MySQL 5.1.24 (see Changes in MySQL 5.1.24 (2008-04-08)).
Please refer to our bug database at http://bugs.mysql.com/ for more details about the individual bugs fixed in this version.
The ndbd and ndb_mgmd man pages have been reclassified from volume 1 to volume 8. (Bug #34642)
Important Change: mysqld_safe now traps Signal 13 (
SIGPIPE) so that this signal no longer kills the MySQL server process. (Bug #33984)
Node or system restarts could fail due an unitialized variable in the
DTUPkernel block. This issue was found in MySQL Cluster NDB 6.3.11. (Bug #35797)
It was not possible to determine the value used for the
--ndb-cluster-connection-pooloption in the mysql client. Now this value is reported as a system status variable. (Bug #35573)
The ndb_waiter utility wrongly calculated timeouts. (Bug #35435)
ndb_restore incorrectly handled some data types when applying log files from backups. (Bug #35343)
In some circumstances, a stopped data node was handled incorrectly, leading to redo log space being exhausted following an initial restart of the node, or an initial or partial restart of the cluster (the wrong CGI might be used in such cases). This could happen, for example, when a node was stopped following the creation of a new table, but before a new LCP could be executed. (Bug #35241)
SELECT ... LIKE ...queries yielded incorrect results when used on
NDBtables. As part of this fix, condition pushdown of such queries has been disabled; re-enabling it is expected to be done as part of a later, permanent fix for this issue. (Bug #35185)
ndb_mgmd reported errors to
STDOUTrather than to
STDERR. (Bug #35169)
Nested Multi-Range Read scans failed when the second Multi-Range Read released the first read's unprocessed operations, sometimes leading to an SQL node crash. (Bug #35137)
In some situations, a problem with synchronizing checkpoints between nodes could cause a system restart or a node restart to fail with Error 630 during restore of TX. (Bug #34756)
References: This issue is a regression of: Bug #34033.
A node failure during an initial node restart followed by another node start could cause the master data node to fail, because it incorrectly gave the node permission to start even if the invalidated node's LCP was still running. (Bug #34702)
When a secondary index on a
DECIMALcolumn was used to retrieve data from an
NDBtable, no results were returned even if the target table had a matched value in the column that was defined with the secondary index. (Bug #34515)
If a data node in one node group was placed in the “not started” state (using
), it was not possible to stop a data node in a different node group. (Bug #34201)
NDBCLUSTERtest failures occurred in builds compiled using icc on IA64 platforms. (Bug #31239)
START BACKUPcommand was issued while ndb_restore was running, the backup being restored could be overwritten. (Bug #26498)
CHANGE MASTER TOstatement with no
MASTER_HEARTBEAT_PERIODoption failed to reset the heartbeat period to its default value. (Bug #34686)
Cluster Replication: In some cases, when updating only one or some columns in a table, the complete row was written to the binary log instead of only the updated column or columns, even when
ndb_log_updated_onlywas set to 1. (Bug #35208)
Cluster Replication: Using
--ndb-wait-connectedcaused the server to wait for a partial connection, plus an additional 3 seconds for a complete connection to the cluster. This could lead to issues with setting up the binary log. (Bug #34757)
Cluster API: Closing a scan before it was executed caused the application to segfault. (Bug #36375)
Cluster API: Using NDB API applications from older MySQL Cluster versions with
libndbclientfrom newer ones caused the cluster to fail. (Bug #36124)
Cluster API: Some ordered index scans could return tuples out of order. (Bug #35908)
Cluster API: Scans having no bounds set were handled incorrectly. (Bug #35876)
NdbScanFilter::getNdbOperation(), which was inadvertently removed in MySQL Cluster NDB 6.3.11, has been restored. (Bug #35854)
FLUSH PRIVILEGESstatement after creating a temporary table in the
mysqldatabase with the same name as one of the MySQL system tables caused the server to crash.Note
While it is possible to shadow a system table in this way, the temporary table exists only for the current user and connection, and does not effect any user privileges.