This is a new source release, fixing recently discovered bugs in previous MySQL Cluster NDB 6.3 releases.
Obtaining MySQL Cluster NDB 6.3. This is a source-only release, which you must compile and install using the instructions found in Section 2.3, “MySQL Installation Using a Source Distribution”, and in Section 17.2.1, “MySQL Cluster Multi-Computer Installation”. 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 Section C.1.28, “Changes in MySQL 5.1.24 (08 April 2008)”).
Please refer to our bug database at http://bugs.mysql.com/ for more details about the individual bugs fixed in this version.
Functionality added or changed:
The ndbd and ndb_mgmd man pages have been reclassified from volume 1 to volume 8. (Bug#34642)
Node or system restarts could fail due an unitialized variable
DTUP kernel block. This issue was
found in MySQL Cluster NDB 6.3.11.
The ndb_waiter utility wrongly calculated timeouts. (Bug#35435)
ndb_restore incorrectly handled some datatypes 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
NDB tables. 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.
ndb_mgmd reported errors to
STDOUT rather than to
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)
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
DECIMAL column was used to
retrieve data from an
NDB table, no
results were returned even if the target table had a matched
value in the column that was defined with the secondary index.
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.
NDBCLUSTER test failures
occurred in builds compiled using icc on IA64
START BACKUP command was issued while
ndb_restore was running, the backup being
restored could be overwritten.
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_only was set to 1.
system variable caused 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.
Cluster API: Closing a scan before it was executed caused the application to segfault. (Bug#36375)
Using NDB API applications from older MySQL Cluster versions
libndbclient from newer ones caused the
cluster to fail.
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
PRIVILEGES statement after creating a temporary table
mysql database with the same name as
one of the MySQL system tables caused the server to crash.
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.