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.
Functionality Added or Changed
The ndbd and ndb_mgmd man pages have been reclassified from volume 1 to volume 8. (Bug #34642)
mysqld_safe now traps Signal 13
SIGPIPE) so that this signal no longer kills
the MySQL server process.
Node or system restarts could fail due an unitialized variable
DTUP kernel block. This issue was
found in MySQL Cluster NDB 6.3.11.
It was not possible to determine the value used for the
--ndb-cluster-connection-pool option in the
mysql client. Now this value is reported as a
system status variable.
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
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)
References: This bug is a regression of Bug #34033.
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.
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)
START BACKUP command was issued while
ndb_restore was running, the backup being
restored could be overwritten.
NDBCLUSTER test failures
occurred in builds compiled using icc on IA64
CHANGE MASTER TO statement with
MASTER_HEARTBEAT_PERIOD option failed to
reset the heartbeat period to its default value.
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.
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)
Cluster API: Scans having no bounds set were handled incorrectly. (Bug #35876)
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)
which was inadvertently removed in MySQL Cluster NDB 6.3.11, has
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.