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.
ADD INDEX, and
DROP INDEXoperations can now be performed explicitly for
NDBtables—that is, without copying or locking of the affected tables—using
ALTER ONLINE TABLE. Indexes can also be created and dropped online using
DROP INDEX, 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
MyISAMtables is performed in place without table copying.
It is now possible to control whether fixed-width or variable-width storage is used for a given column of an
NDBtable by means of the
COLUMN_FORMATspecifier as part of the column's definition in a
It is also possible to control whether a given column of an
NDBtable is stored in memory or on disk, using the
STORAGEspecifier as part of the column's definition in a
For permitted values and other information about
STORAGE, see CREATE TABLE Syntax.
A new cluster management server startup option
--bind-addressmakes it possible to restrict management client connections to ndb_mgmd to a single host and port. For more information, see ndb_mgmd — The MySQL Cluster Management Server Daemon.
Cluster Replication: Multi-way replication failover and recovery for
NDBis facilitated with the introduction of the
--ndb-log-origoption. When mysqld is started with this option, the originating server ID and epoch of each binary log event is recorded in the
mysql.ndb_binlog_indextable, which now contains two additional columns
orig_epochfor storing this information. In such cases, a single epoch on a slave may be represented by multiple rows in the slave's
ndb_binlog_indextable, one for each epoch as it originated from a master.
Cluster Replication: 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, using the
TimeBetweenEpochsconfiguration parameter. This improves the reliability and performance of MySQL Cluster Replication.
GCPs handled using the new protocol are sometimes referred to as “micro-GCPs”.
NDBevent was left behind but the corresponding table was later recreated and received a new table ID, the event could not be dropped. (Bug #30877)
When creating an
NDBtable with a column that has
COLUMN_FORMAT = DYNAMIC, but the table itself uses
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
column_name. (Bug #30276)
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
NDBobject 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)