The following list provides an overview of significant feature additions and changes first made in MySQL Cluster NDB 6.3. For more detailed information about all feature changes and bugfixes made in MySQL Cluster NDB 6.3, see http://dev.mysql.com/doc/relnotes/mysql-cluster/7.1/en/mysql-cluster-news-6-3.html.
Conflict detection and resolution. It is now possible to detect and resolve conflicts that arise in multi-master replication scenarios, such as circular replication, when different masters may try to update the same row on the slave with different data. Both “greatest timestamp wins” and “same timestamp wins” scenarios are supported. For more information, see Section 17.6.11, “MySQL Cluster Replication Conflict Resolution”.
Recovery of one master, many slaves replication setups. Recovery of multi-way replication setups (“one master, many slaves”) is now supported using the
--ndb-log-origserver option and changes in the
mysql.ndb_binlog_indextable. See Section 17.6.4, “MySQL Cluster Replication Schema and Tables”, for more information.
Enhanced selection options for transaction coordinator. New values and behaviors are introduced for
--ndb_optimized_node_selection, enabling greater flexibility when an SQL node chooses a transaction coordinator. For more information, see the description of
ndb_optimized_node_selectionin Section 184.108.40.206.2, “MySQL Cluster System Variables”.
Replication heartbeats. Replication heartbeats facilitate the task of monitoring and detecting failures in master-slave connections in real time. This feature is implemented using a new
MASTER_HEARTBEAT_PERIOD =clause for the
CHANGE MASTER TOstatement and the addition of two status variables
Slave_received_heartbeats. For more information, see Section 220.127.116.11, “CHANGE MASTER TO Syntax”.
NDB thread locks. It is possible to lock
NDBexecution threads and maintenance threads (such as file system and other operating system threads) to specific CPUs on multiprocessor data node hosts, and to leverage real-time scheduling.
Improved performance of updates using primary keys or unique keys. The number of unnecessary reads when performing a primary key or unique key update has been greatly reduced. Since it is seldom necessary to read a record prior to an update, this can yield a considerable improvement in performance. In addition, primary key columns are no longer written to when not needed during update operations.
Improved SQL statement performance metrics. The
Ndb_execute_countsystem status variable measures the number of round trips made by SQL statements to the
NDBkernel, providing an improved metric for determining efficiency with which statements are executed. For more information, see MySQL Cluster Status Variables:
Compressed LCPs and backups. Compressed local checkpoints and backups can save 50% or more of the disk space used by uncompressed LCPs and backups. These can be enabled using the two new data node configuration parameters
OPTIMIZE TABLE support with NDBCLUSTER tables.
OPTIMIZE TABLEis supported for dynamic columns of in-memory
NDBtables. In such cases, it is no longer necessary to drop (and possibly to re-create) a table, or to perform a rolling restart, in order to recover memory from deleted rows for general re-use by Cluster. The performance of
OPTIMIZEon Cluster tables can be tuned by adjusting the value of the
ndb_optimization_delaysystem variable, which controls the number of milliseconds to wait between processing batches of rows by
OPTIMIZE TABLE. In addition,
OPTIMIZE TABLEon an
NDBCLUSTERtable can be interrupted by, for example, killing the SQL thread performing the
Batching of transactions. It is possible to cause statements occurring within the same transaction to be run as a batch by setting the session variable
ON. To use this feature,
autocommitmust be set to
OFF. Batch sizes can be controlled using the
--ndb-batch-sizeoption for mysqld. For additional information, see Section 18.104.22.168.1, “MySQL Server Options for MySQL Cluster”, and Section 22.214.171.124.2, “MySQL Cluster System Variables”.
Attribute promotion with ndb_restore. It is possible using ndb_restore to restore data reliably from a column of a given type to a column that uses a “larger” type. This is sometimes referred to as attribute promotion. For example, MySQL Cluster backup data that originated in a
SMALLINTcolumn can be restored to a
BIGINTcolumn. See Section 17.4.20, “ndb_restore — Restore a MySQL Cluster Backup”, for more information.
Parallel data node recovery. Recovery of multiple data nodes can now be done in parallel, rather than sequentially. In other words, several data nodes can be restored concurrently, which can often result in much faster recovery times than when they are restored one at a time.
Increased local checkpoint efficiency. Only 2 local checkpoints are stored, rather than 3, lowering disk space requirements and the size and number of redo log files.
NDBCLUSTER table persistence control. Persistence of
NDBtables can be controlled using the session variables
NDBtables not to be checkpointed to disk;
ndb_table_temporarydoes the same, and in addition, no schema files are created. See Section 126.96.36.199, “MySQL Cluster mysqld Option and Variable Reference”.
Epoll support (Linux only). Epoll is an improved method for handling file descriptors, which is more efficient than scanning to determine whether a file descriptor has data to be read. (The term epoll is specific to Linux and equivalent functionality is known by other names on other platforms such as Solaris and FreeBSD.) Currently, MySQL Cluster supports this functionality on Linux only.
Distribution awareness (SQL nodes). In MySQL Cluster NDB 6.3, SQL nodes can take advantage of distribution awareness. Here we provide a brief example showing how to design a table to make a given class of queries distrubtion-aware. Suppose an
t1has the following schema:
CREATE TABLE t1 ( userid INT NOT NULL, serviceid INT NOT NULL AUTO_INCREMENT PRIMARY KEY, data VARCHAR(255) ) ENGINE=NDBCLUSTER;
Suppose further that most of the queries to be used in our application test values of the
useridcolumn of this table. The form of such a query looks something like this:
columnsFROM t1 WHERE userid
In this query,
relationrepresents some relational operator, such as
>, and so on. Queries using
INand a list of values can also be used:
columnsFROM t1 WHERE userid IN
To make use of distribution awareness, we need to make the
useridcolumn part of the table's primary key, then explicitly partition the table with this column being used as the partitioning key. (Recall that for a partitioned table having one or more unique keys, all columns of the table's partitioning key must also be part of all of the unique keys—for more information and examples, see Section 18.5.1, “Partitioning Keys, Primary Keys, and Unique Keys”.) In other words, the table schema should be equivalent to the following
CREATE TABLE t1 ( userid INT NOT NULL, serviceid INT NOT NULL AUTO_INCREMENT, data VARCHAR(255), PRIMARY KEY p (userid,serviceid) ) ENGINE=NDBCLUSTER PARTITION BY KEY(userid);
When the table is partitioned in this way, all rows having the same
useridvalue are found on the same node group, and the MySQL Server can immediately select the optimal node to use as the transaction coordinator.
Realtime extensions for multiple CPUs. When running MySQL Cluster data nodes on hosts with multiple processors, the realtime extensions make it possible to give priority to the data node process and control on which CPU cores it should operate. This can be done using the data node configuration parameters
SchedulerSpinTimer. Doing so properly can significantly lower response times and make them much more predictable response. For more information about using these parameters, see Defining Data Nodes: Realtime Performance Parameters
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 SCHEMAstatement to be issued on the new SQL node after it joins the cluster.
Detection of NDB API client connection errors. Beginning with MySQL Cluster NDB 6.3.20, the NDB API's
Ndb_cluster_connectionclass adds the
get_latest_error_msg()methods for catching and diagnosing problems with NDB API client connections.
Restoring specific databases, tables, or columns from a MySQL Cluster backup. It is now possible to exercise more fine-grained control when restoring a MySQL Cluster from backup using ndb_restore. Beginning with MySQL Cluster NDB 6.3.22, you can choose to restore only specified tables or databases, or exclude specific tables or databases from being restored, using the new ndb_restore options
--exclude-databases. Beginning with MySQL Cluster NDB 6.3.26, it is also possible to restore to a table having fewer columns than the original using the
--exclude-missing-columnsoption. For more information about all of these options, see Section 17.4.20, “ndb_restore — Restore a MySQL Cluster Backup”.
Improved Disk Data file system configuration. As of MySQL Cluster NDB 6.3.22, you can specify default locations for MySQL Cluster Disk Data data files and undo log files using the data node configuration parameters
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.3.22, using the data node configuration parameters
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. For more information, see Disk Data object creation parameters.
Configuration parameter data dumps. Starting with MySQL Cluster NDB 6.3.25, the ndb_config utility supports a
--configinfooption that causes it to dump a list of all configuration parameters supported by the cluster, along with brief descriptions, information about the parameters' default and permitted values, and the sections of the
config.inifile in which the parameters apply. An additional
--xmlswitch causes ndb_config to use XML rather than plain text output. Using ndb_config
--configinfo --xmlrequires no access to a running MySQL Cluster, any other programs, or any files. For more information and examples, see Section 17.4.7, “ndb_config — Extract MySQL Cluster Configuration Information”.
Per-table reporting of free space on disk. The
INFORMATION_SCHEMA.FILEStable shows information about used and free space in MySQL Cluster Disk Data data files, but this information is not applicable to individual tables. In MySQL Cluster NDB 6.3.27 and later, the ndb_desc utility provides two additional columns in its output that show the amount of space allocated on disk for a given
NDBtable as well the amount of space that remains available for additional storage of disk-based column data for that table. For more information, see Section 17.4.10, “ndb_desc — Describe NDB Tables”.
Improved restart times. Optimizations in redo log handling and other file system operations introduced in MySQL Cluster NDB 6.3.28 have the potential to reduce considerably the time required for restarts. While actual performance benefits observed in production setups will naturally vary depending on database size, hardware, and other conditions, our own preliminary testing has shown that these improvements can yield startup times that are faster than those typical of previous MySQL Cluster NDB 6.3 releases by a factor of 50 or more.
Increased flexibility in online upgrade procedure. Previously, when performing an upgrade of a running MySQL cluster, the order in which the types of cluster nodes had to be upgraded was very strict. However, beginning with MySQL Cluster NDB 6.3.29, MySQL Cluster supports online upgrading of API nodes (including MySQL servers running as SQL nodes) before upgrading management nodes, data nodes, or both.Important
Before attempting to use this new upgrade functionality, see Section 17.5.5, “Performing a Rolling Restart of a MySQL Cluster”, for additional information, especially if you are planning an online upgrade from MySQL Cluster NDB 6.3 to MySQL Cluster NDB 7.0.
New replication conflict resolution strategy. Beginning with MySQL Cluster NDB 6.3.31, the function
NDB$MAX_DELETE_WIN()is available to implement “greatest timestamp, delete wins” conflict resolution. See NDB$MAX_DELETE_WIN(column_name), for more information.
New CHANGE MASTER TO option for circular replication. Beginning with MySQL Cluster NDB 6.3.31, the
CHANGE MASTER TOstatement supports an
IGNORE_SERVER_IDSoption 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.)
Heartbeat thread policy and priority. Beginning with MySQL Cluster NDB 6.3.32, a new configuration parameter
HeartbeatThreadPrioritymakes it possible to set the policy and the priority for the heartbeat thread on management and API nodes.
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.3.32, the
--blob-infooption causes this program to include partition information for
BLOBtables in its output. Beginning with MySQL Cluster NDB 6.3.33, the
--extra-node-infooption causes ndb_desc to include information about data distribution (that is, which table fragments are stored on which data nodes). Each of these options also requires the use of the
Information about partition-to-node mappings can also be obtained using the
Table::getFragmentNodes()method, also added in MySQL Cluster NDB 6.3.33.
Replication attribute promotion and demotion. Beginning with MySQL Cluster NDB 6.3.33, MySQL Cluster Replication supports attribute promotion and demotion when replicating between columns of different but similar types on the master and the slave. For example, it is possible to promote an
INTcolumn on the master to a
BIGINTcolumn on the slave, and to demote a
TEXTcolumn to a
The implementation of type demotion distinguishes between lossy and non-lossy type conversions, and their use on the slave can be controlled by setting the
slave_type_conversionsglobal server system variable.
For more information, see Attribute promotion and demotion (MySQL Cluster).
Incompatible change in NDB API event reporting. Beginning with MySQL Cluster NDB 6.3.34, DDL events are no longer reported on
Eventobjects by default. Instead such event reporting must be enabled explicitly using the
Event::setReport()method. For more information, see Event::setReport(), and The Event::EventReport Type.
Heartbeat ordering. Beginning with MySQL Cluster NDB 6.3.35, it is possible to set a specific order for transmission of heartbeats between data nodes, using the
HeartbeatOrderdata node configuration parameter introduced in this version. This parameter can be useful in situations where multiple data nodes are running on the same host and a temporary disruption in connectivity between hosts would otherwise cause the loss of a node group (and thus failure of the cluster).
Relaxed ndb_restore column comparison rules. When restoring data, ndb_restore compares the attributes of a column for equality with the definition of the column in the target table. However, not all of these attributes need to be the same for ndb_restore to be meaningful, safe and useful. Beginning with MySQL Cluster NDB 6.3.35, ndb_restore automatically ignores differences in certain column attributes which do not necessarily have to match between the version of the column in a backup and the version of that column in the MySQL Cluster to which the column data is being restored. These attributes include the following:
The default value
The distribution key
In such cases, ndb_restore reports any such differences to minimize any chance of user error.
--add-drop-trigger option for mysqldump. Beginning with MySQL Cluster NDB 6.3.38, this option can be used to force all
CREATE TRIGGERstatements in mysqldump output to be preceded by a
DROP TRIGGER IF EXISTSstatement.
Skipping corrupted tables in NDB native backups. Beginning with MySQL Cluster NDB 6.3.40, you can cause ndb_restore to ignore tables that are corrupted due to missing blob parts tables by using the
--skip-broken-objectsoption. When this option is used, such tables are skipped, and the restoration of any remaining uncorrupted tables in the backup continues.
Restoring from a NDB native backup to a differently-named database. MySQL Cluster NDB 6.3.41 adds a new
--rewrite-databaseoption to ndb_restore, which makes it possible to restore to a database having a different name from that of the database in the backup. The option can be used multiple times, and it is possible to restore from more than one source database in the backup to a single target database (although no protection against table or other object name collision is provided).
See Section 17.4.20, “ndb_restore — Restore a MySQL Cluster Backup”, for more information.