MySQL 5.1 Reference Manual  /  ...  /  MySQL Cluster Development in MySQL Cluster NDB 6.2 MySQL Cluster Development in MySQL Cluster NDB 6.2

The following list provides an overview of significant feature additions and changes made in MySQL Cluster NDB 6.2. All of the changes in this list are also available in MySQL Cluster NDB 6.3 . For more detailed information about all feature changes and bugfixes made in MySQL Cluster NDB 6.2, see

  • Enhanced backup status reporting. Backup status reporting has been improved, aided in part by the introduction of a BackupReportFrequency configuration parameter.

  • Multiple cluster connections per SQL node. A single MySQL server acting as a MySQL Cluster SQL node can employ multiple connections to the cluster using the --ndb-cluster-connection-pool startup option for mysqld. This option is described in MySQL Cluster-Related Command Options for mysqld: --ndb-cluster-connection-pool option.

  • New data access interface. The NdbRecord interface provides a new and simplified data handler for use in NDB API applications.

  • New reporting commands. The new management client REPORT BackupStatus and REPORT MemoryUsage commands provide better access to information about the status of MySQL Cluster backups and how much memory is being used by MySQL Cluster for data and index storage. See Section 17.5.2, “Commands in the MySQL Cluster Management Client”, for more information about the REPORT commands. In addition, in-progress status reporting is provided by the ndb_restore utility; see Section 17.4.20, “ndb_restore — Restore a MySQL Cluster Backup”.

  • Improved memory allocation and configuration. Memory is now allocated by the NDB kernel to tables on a page-by-page basis, which significantly reduces the memory overhead required for maintaining NDBCLUSTER tables. In addition, the MaxAllocate configuration parameter now makes it possible to set the maximum size of the allocation unit used for table memory.

  • Choice of fixed-width or variable-width columns. You can control whether fixed-width or variable-width storage is used for a given column of an NDB table by employing of the COLUMN_FORMAT specifier as part of the column's definition in a CREATE TABLE or ALTER TABLE statement. In addition, the ability 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 CREATE TABLE or ALTER TABLE statement. For more information, see Section 13.1.17, “CREATE TABLE Syntax”, and Section 13.1.7, “ALTER TABLE Syntax”.

  • Controlling management client connections. The --bind-address cluster management server startup option makes it possible to restrict management client connections to ndb_mgmd to a single host (IP address or host name) and port, which can make MySQL Cluster management operations more secure. For more information about this option, see Section 17.4.4, “ndb_mgmd — The MySQL Cluster Management Server Daemon”.

  • Micro-GCPs. Due to a change in the protocol for handling of global checkpoints (GCPs handled in this manner sometimes being referred to as micro-GCPs), it is now possible to control how often the GCI number is updated, and how often global checkpoints are written to disk, using the TimeBetweenEpochs and TimeBetweenEpochsTimeout configuration parameters. This improves the reliability and performance of MySQL Cluster Replication.

  • Core online schema change support. Support for the online ALTER TABLE operations ADD COLUMN, ADD INDEX, and DROP INDEX is available. When the ONLINE keyword is used, the ALTER TABLE is noncopying, which means that indexes do not have to be re-created, which provides these benefits:

    • Single user mode is no longer required for ALTER TABLE operations that can be performed online.

    • Transactions can continue during ALTER TABLE operations that can be performed online.

    • Tables being altered online are not locked against access by other SQL nodes.

      However, such tables are locked against other operations on the same SQL node for the duration of the ALTER TABLE. We are working to overcome this limitation in a future MySQL Cluster release.

    Online CREATE INDEX and DROP INDEX statements are also supported. Online changes can be suppressed using the OFFLINE key word. See Section, “ALTER TABLE Online Operations in MySQL Cluster”, Section 13.1.13, “CREATE INDEX Syntax”, and Section 13.1.24, “DROP INDEX Syntax”, for more detailed information.

  • mysql.ndb_binlog_index improvements. More information has been added to the mysql.ndb_binlog_index table so that it is possible to determine which originating epochs have been applied inside an epoch. This is particularly useful for 3-way replication. See Section 17.6.4, “MySQL Cluster Replication Schema and Tables”, for more information.

  • Epoch lag control. The MaxBufferedEpochs data node configuration parameter provides a means to control the maximum number of unprocessed epochs by which a subscribing node can lag. Subscribers which exceed this number are disconnected and forced to reconnect.

  • Fully automatic database discovery. It is no longer a requirement for database autodiscovery that an SQL node already be connected to the cluster at the time that a database is created on another SQL node, or for a CREATE DATABASE or CREATE SCHEMA statement to be issued on the new SQL node after it joins the cluster.

  • Multiple data node processes per host. In earlier MySQL Cluster release series, we did not support MySQL Cluster deployments in production where more than one ndbd process was run on a single physical machine. However, beginning with MySQL Cluster NDB 6.2.0, you can use multiple data node processes on a single host.


    A multi-threaded version of ndbd tailored for use on hosts with multiple CPUs or cores was introduced in MySQL Cluster NDB 7.0. See Section, “MySQL Cluster Development in MySQL Cluster NDB 7.0”, and Section 17.4.3, “ndbmtd — The MySQL Cluster Data Node Daemon (Multi-Threaded)”, for more information.

  • Improved Disk Data file system configuration. As of MySQL Cluster NDB 6.2.17, you can specify default locations for MySQL Cluster Disk Data data files and undo log files using the data node configuration parameters FileSystemPathDD, FileSystemPathDataFiles, and FileSystemPathUndoFiles. This eliminates the need to use symbolic links to place Disk Data files separately from other files in data node file systems to improve Disk Data performance. For more information, see Disk Data file system parameters.

  • Automatic creation of Disk Data log file groups and tablespaces. Beginning with MySQL Cluster NDB 6.2.17, using the data node configuration parameters InitialLogFileGroup and InitialTablespace, you can cause the creation of a MySQL Cluster Disk Data log file group, tablespace, or both, when the cluster is first started. When using these parameters, no SQL statements are required to create these Disk Data objects.

  • Improved access to partitioning information. The ndb_desc utility now provides additional information about the partitioning of data stored in MySQL Cluster. Beginning with MySQL Cluster NDB 6.2.19, the --extra-node-info option causes ndb_desc to include information about data distribution (that is, which table fragments are stored on which data nodes). This option also requires the use of the --extra-partition-info option.

    Information about partition-to-node mappings can also be obtained using the Table::getFragmentNodes() method, also added in MySQL Cluster NDB 6.2.19.

  • New CHANGE MASTER TO option for circular replication. Beginning with MySQL Cluster NDB 6.2.19, the CHANGE MASTER TO statement supports an IGNORE_SERVER_IDS option which takes a comma-separated list of server IDs and causes events originating from the corresponding servers to be ignored. (Log rotation and log deletion events are preserved.)

    See Section, “CHANGE MASTER TO Syntax”, as well as Section, “SHOW SLAVE STATUS Syntax”, for more information.

User Comments
Sign Up Login You must be logged in to post a comment.