This is a new Beta development release, incorporating new
features in the
NDB storage engine
and fixing recently discovered bugs in MySQL Cluster NDB 6.4.2.
The successor version to MySQL Cluster NDB 6.4.3 is MySQL Cluster NDB 7.0.4. See Changes in MySQL Cluster NDB 7.0.4 (5.1.32-ndb-7.0.4) (2009-03-18).
Obtaining MySQL Cluster NDB 6.4.3. MySQL Cluster NDB 6.4.3 is a source-only release. You can obtain the source code from ftp://ftp.mysql.com/pub/mysql/download/cluster_telco/mysql-5.1.32-ndb-6.4.3/.
This Beta release incorporates all bugfixes and changes made in previous MySQL Cluster NDB 6.1, 6.2, 6.3, and 6.4 releases, as well as all bugfixes and feature changes which were added in mainline MySQL 5.1 through MySQL 5.1.32 (see Changes in MySQL 5.1.32 (2009-02-14)).
This Beta release, as any other pre-production release, should not be installed on production level systems or systems with critical data. Please refer to our bug database at http://bugs.mysql.com/ for more details about the individual bugs fixed in this version.
Important Change; Replication:
RESET SLAVEnow reset the values shown for
Last_SQL_Errnoin the output of
SHOW SLAVE STATUS. (Bug #34654)
References: See also: Bug #44270.
A new data node configuration parameter
MaxLCPStartDelayhas been introduced to facilitate parallel node recovery by causing a local checkpoint to be delayed while recovering nodes are synchronizing data dictionaries and other meta-information. For more information about this parameter, see Defining MySQL Cluster Data Nodes. (Bug #43053)
New options are introduced for ndb_restore for determining which tables or databases should be restored:
--include-databasescan be used to restore specific tables or databases.
--exclude-databasescan be used to exclude the specified tables or databases from being restored.
For more information about these options, see ndb_restore — Restore a MySQL Cluster Backup. (Bug #40429)
Disk Data: It is now possible to specify default locations for Disk Data data files and undo log files, either together or separately, using the data node configuration parameters
FileSystemPathUndoFiles. For information about these configuration parameters, see Disk Data file system parameters.
It is also now possible to specify a log file group, tablespace, or both, that is created when the cluster is started, using the
InitialTablespacedata node configuration parameters. For information about these configuration parameters, see Disk Data object creation parameters.
Performance: Updates of the
SYSTAB_0system table to obtain a unique identifier did not use transaction hints for tables having no primary key. In such cases the NDB kernel used a cache size of 1. This meant that each insert into a table not having a primary key required an update of the corresponding
SYSTAB_0entry, creating a potential performance bottleneck.
With this fix, inserts on
NDBtables without primary keys can be under some conditions be performed up to 100% faster than previously. (Bug #39268)
References: This issue is a regression of: Bug #29263.
Packaging: Packages for MySQL Cluster were missing the
libndbclient.afiles. (Bug #42278)
ALTER TABLE ... REORGANIZE PARTITIONon an
NDBCLUSTERtable having only one partition caused mysqld to crash. (Bug #41945)
References: See also: Bug #40389.
Using indexes containing variable-sized columns could lead to internal errors when the indexes were being built.
This same issue could also cause redistribution of table data using
ALTER ONLINE TABLEstatements to fail with tables containing variable-sized columns. (Bug #43226)
Backup IDs greater than 231 were not handled correctly, causing negative values to be used in backup directory names and printouts. (Bug #43042)
When using ndbmtd, NDB kernel threads could hang while trying to start the data nodes with
LockPagesInMainMemoryset to 1. (Bug #43021)
When using multiple management servers and starting several API nodes (possibly including one or more SQL nodes) whose connection strings listed the management servers in different order, it was possible for 2 API nodes to be assigned the same node ID. When this happened it was possible for an API node not to get fully connected, consequently producing a number of errors whose cause was not easily recognizable. (Bug #42973)
When using multi-threaded data nodes,
MaxNoOfLocalScanswere effectively multiplied by the number of local query handlers in use by each ndbmtd instance. (Bug #42765)
References: See also: Bug #42215.
ndb_error_reporter worked correctly only with GNU tar. (With other versions of tar, it produced empty archives.) (Bug #42753)
NDBCLUSTERtables caused such tables to become locked. (Bug #42751)
References: See also: Bug #16229, Bug #18135.
When performing more than 32 index or tuple scans on a single fragment, the scans could be left hanging. This caused unnecessary timeouts, and in addition could possibly lead to a hang of an LCP. (Bug #42559)
References: This issue is a regression of: Bug #42084.
A data node failure that occurred between calls to
NdbTransaction::execute()was not correctly handled; a subsequent call to
nextResult()caused a null pointer to be deferenced, leading to a segfault in mysqld. (Bug #42545)
If the cluster configuration cache file was larger than 32K, the management server would not start. (Bug #42543)
SHOW GLOBAL STATUS LIKE 'NDB%'before mysqld had connected to the cluster caused a segmentation fault. (Bug #42458)
When using ndbmtd for all data nodes, repeated failures of one data node during DML operations caused other data nodes to fail. (Bug #42450)
Data node failures that occurred before all data nodes had connected to the cluster were not handled correctly, leading to additional data node failures. (Bug #42422)
When using multi-threaded data nodes, their
IndexMemoryusage as reported was multiplied by the number of local query handlers (worker threads), making it appear that much more memory was being used than was actually the case. (Bug #42215)
References: See also: Bug #42765.
Given a MySQL Cluster containing no data (that is, whose data nodes had all been started using
--initial, and into which no data had yet been imported) and having an empty backup directory, executing
START BACKUPwith a user-specified backup ID caused the data nodes to crash. (Bug #41031)
In some cases,
NDBdid not check correctly whether tables had changed before trying to use the query cache. This could result in a crash of the debug MySQL server. (Bug #40464)
Disk Data: It was not possible to add an in-memory column online to a table that used a table-level or column-level
STORAGE DISKoption. The same issue prevented
ALTER ONLINE TABLE ... REORGANIZE PARTITIONfrom working on Disk Data tables. (Bug #42549)
Disk Data: Repeated insert and delete operations on disk-based tables could lead to failures in the NDB Tablespace Manager (
TSMANkernel block). (Bug #40344)
Disk Data: Creating a Disk Data tablespace with a very large extent size caused the data nodes to fail. The issue was observed when using extent sizes of 100 MB and larger. (Bug #39096)
Disk Data: Trying to execute a
CREATE LOGFILE GROUPstatement using a value greater than
UNDO_BUFFER_SIZEcaused data nodes to crash.
As a result of this fix, the upper limit for
600M; attempting to set a higher value now fails gracefully with an error. (Bug #34102)
References: See also: Bug #36702.
Disk Data: When attempting to create a tablespace that already existed, the error message returned was Table or index with given name already exists. (Bug #32662)
Disk Data: Using a path or file name longer than 128 characters for Disk Data undo log files and tablespace data files caused a number of issues, including failures of
CREATE LOGFILE GROUP,
ALTER LOGFILE GROUP,
CREATE TABLESPACE, and
ALTER TABLESPACEstatements, as well as crashes of management nodes and data nodes.
With this fix, the maximum length for path and file names used for Disk Data undo log files and tablespace data files is now the same as the maximum for the operating system. (Bug #31769, Bug #31770, Bug #31772)
Disk Data: Attempting to perform a system restart of the cluster where there existed a logfile group without and undo log files caused the data nodes to crash.Note
While issuing a
CREATE LOGFILE GROUPstatement without an
ADD UNDOFILEoption fails with an error in the MySQL server, this situation could arise if an SQL node failed during the execution of a valid
CREATE LOGFILE GROUPstatement; it is also possible to create a logfile group without any undo log files using the NDB API.
Cluster Replication: Being disconnected from the cluster while setting up the binary log caused mysqld to hang or crash. (Bug #43045)
Cluster Replication: When replicating between MySQL Clusters,
AUTO_INCREMENTwas not set properly on the slave cluster. (Bug #42232)
Cluster API: Some error messages from ndb_mgmd contained newline (
\n) characters. This could break the MGM API protocol, which uses the newline as a line separator. (Bug #43104)
Cluster API: When using an ordered index scan without putting all key columns in the read mask, this invalid use of the NDB API went undetected, which resulted in the use of uninitialized memory. (Bug #42591)