This is a new Beta development 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 Beta 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.22 (see Changes in MySQL 5.1.22 (2007-09-24, Release Candidate)).
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
It is now possible to control whether fixed-width or
variable-width storage is used for a given column of an
NDB table by means of the
COLUMN_FORMAT specifier as part of the
column's definition in a
It is also possible to control whether a given column of an
NDB table is stored in memory or on
disk, using the
STORAGE specifier as part of
the column's definition in a
For permitted values and other information about
see CREATE TABLE Syntax.
A new cluster management server startup option
--bind-address makes it
possible to restrict management client connections to
ndb_mgmd to a single host and port. For more
ndb_mgmd — The MySQL Cluster Management Server Daemon.
DROP INDEX operations
can now be performed explicitly for
NDB tables—that is, without
copying or locking of the affected tables—using
ALTER ONLINE TABLE. Indexes can also be
created and dropped online using
respectively, using the
You can force operations that would otherwise be performed
online to be done offline using the
Renaming of tables and columns for
tables is performed in place without table copying.
The protocol for handling global checkpoints has been changed.
It is now possible to control how often the GCI number is
updated, and how often global checkpoints are written to disk,
configuration parameter. This improves the reliability and
performance of MySQL Cluster Replication.
GCPs handled using the new protocol are sometimes referred to as “micro-GCPs”.
Multi-way replication failover and recovery for
NDB is facilitated with the
introduction of the
--ndb-log-orig option. When
mysqld is started with this option, the
originating server ID and epoch of each binary log event is
recorded in the
which now contains two additional columns
orig_epoch for storing this information. In
such cases, a single epoch on a slave may be represented by
multiple rows in the slave's
ndb_binlog_index table, one for each epoch as
it originated from a master.
NDB event was left behind
but the corresponding table was later recreated and received a
new table ID, the event could not be dropped.
When creating an
NDB table with a column that
COLUMN_FORMAT = DYNAMIC, but the table
ROW_FORMAT=FIXED, the table is
considered dynamic, but any columns for which the row format is
unspecified default to
FIXED. Now in such
cases the server issues the warning Row format FIXED
incompatible with dynamic attribute
An insufficiently descriptive and potentially misleading Error 4006 (Connect failure - out of connection objects...) was produced when either of the following two conditions occurred:
There were no more transaction records in the transaction coordinator
NDB object in the NDB API
was initialized with insufficient parallelism
Separate error messages are now generated for each of these two cases. (Bug #11313)
For micro-GCPs, the assignment of “fake” CGI events no longer cause buckets to be sent out of order. Now, when assigning a GCI to a non-GCI event (that is, creating a pseudo-GCI or “fake” CGI), the GCI that is to arrive is always initiated, even if no known GCI exists, which could occur in the event of a node failure. (Bug #30884)