Major changes and new features in NDB Cluster 7.5 which are likely to be of interest are shown in the following list:
ndbinfo Enhancements. A number of changes are made in the
ndbinfodatabase, chief of which is that it now provides detailed information about NDB Cluster node configuration parameters.
config_paramstable has been made read-only, and has been enhanced with additional columns providing information about each configuration parameter, including the parameter's type, default value, maximum and minimum values (where applicable), a brief description of the parameter, and whether the parameter is required. This table also provides each parameter with a unique
A row in the
config_valuestable shows the current value of a given parameter on the node having a specified ID. The parameter is identified by the value of the
config_paramcolumn, which maps to the
Using this relationship you can write a join on these two tables to obtain the default, maximum, minimum, and current values for one or more NDB Cluster configuration parameters by name. An example SQL statement using such a join is shown here:
SELECT p.param_name AS Name, v.node_id AS Node, p.param_type AS Type, p.param_default AS 'Default', p.param_min AS Minimum, p.param_max AS Maximum, CASE p.param_mandatory WHEN 1 THEN 'Y' ELSE 'N' END AS 'Required', v.config_value AS Current FROM config_params p JOIN config_values v ON p.param_number = v.config_param WHERE p. param_name IN ('NodeId', 'HostName','DataMemory', 'IndexMemory');
For more information about these changes, see Section 220.127.116.11, “The ndbinfo config_params Table”. See Section 18.104.22.168, “The ndbinfo config_values Table”, for further information and examples.
In addition, the
ndbinfodatabase no longer depends on the
MyISAMstorage engine. All
ndbinfotables and views now use
ndbinfotables were introduced in NDB 7.5.4. These tables are listed here, with brief descriptions:
dict_obj_infoprovides the names and types of database objects in
NDB, as well as information about parent obejcts where applicable
NDBtable distribution status information
table_fragmentsprovides information about the distribution of
table_infoprovides information about logging, checkpointing, storage, and other options in force for each
table_replicasprovides information about fragment replicas
See the descriptions of the individual tables for more information.
Default row and column format changes. Starting with NDB 7.5.1, the default value for both the
ROW_FORMAToption and the
CREATE TABLEcan be set to
FIXED, using a new MySQL server variable
ndb_default_column_formatis added as part of this change; set this to
DYNAMIC(or start mysqld with the equivalent option
--ndb-default-column-format=FIXED) to force this value to be used for
ROW_FORMAT. Prior to NDB 7.5.4, the default for this variable was
DYNAMIC; in this and later versions, the default is
FIXED, which provides backwards compatibility with prior releases (Bug #24487363).
The row format and column format used by existing table columns are unaffected by this change. New columns added to such tables use the new defaults for these (possibly overridden by
ndb_default_column_format), and existing columns are changed to use these as well, provided that the
ALTER TABLEstatement performing this operation specifies
ndb_binlog_index no longer dependent on MyISAM. As of NDB 7.5.2, the
ndb_binlog_indextable employed in NDB Cluster Replication now uses the
InnoDBstorage engine instead of
MyISAM. When upgrading, you can run mysql_upgrade with
--upgrade-system-tablesto cause it to execute
ALTER TABLE ... ENGINE=INNODBon this table. Use of
MyISAMfor this table remains supported for backward compatibility.
A benefit of this change is that it makes it possible to depend on transactional behavior and lock-free reads for this table, which can help alleviate concurrency issues during purge operations and log rotation, and improve the availability of this table.
ALTER TABLE changes. NDB Cluster formerly supported an alternative syntax for online
ALTER TABLE. This is no longer supported in NDB Cluster 7.5, which makes exclusive use of
ALGORITHM = DEFAULT|COPY|INPLACEfor table DDL, as in the standard MySQL Server.
Another change affecting the use of this statement is that
ALTER TABLE ... ALGORITHM=INPLACE RENAMEmay now contain DDL operations in addition to the renaming.
ExecuteOnComputer parameter deprecated. The
ExecuteOnComputerconfiguration parameter for management nodes, data nodes, and API nodes has been deprecated and is now subject to removal in a future release of NDB Cluster. You should use the equivalent
HostNameparameter for all three types of nodes.
records-per-key optimization. The NDB handler now uses the records-per-key interface for index statistics implemented for the optimizer in MySQL 5.7.5. Some of the benefits from this change include those listed here:
Connection pool node IDs. NDB 7.5.0 adds the mysqld
--ndb-cluster-connection-pool-nodeidsoption, which allows a set of node IDs to be set for the connection pool. This setting overrides
--ndb-nodeid, which means that it also overrides both the
--ndb-connectstringoption and the
create_old_temporals removed. The
create_old_temporalssystem variable was deprecated in NDB Cluster 7.4, and has now been removed.
ndb_mgm Client PROMPT command. NDB Cluster 7.5 adds a new command for setting the client's command-line prompt. The following example illustrates the use of the
ndb_mgm> PROMPT mgm#1: mgm#1: SHOW Cluster Configuration --------------------- [ndbd(NDB)] 4 node(s) id=5 @10.100.1.1 (mysql-5.7.21-ndb-7.5.10, Nodegroup: 0, *) id=6 @10.100.1.3 (mysql-5.7.21-ndb-7.5.10, Nodegroup: 0) id=7 @10.100.1.9 (mysql-5.7.21-ndb-7.5.10, Nodegroup: 1) id=8 @10.100.1.11 (mysql-5.7.21-ndb-7.5.10, Nodegroup: 1) [ndb_mgmd(MGM)] 1 node(s) id=50 @10.100.1.8 (mysql-5.7.21-ndb-7.5.10) [mysqld(API)] 2 node(s) id=100 @10.100.1.8 (5.7.21-ndb-7.5.10) id=101 @10.100.1.10 (5.7.21-ndb-7.5.10) mgm#1: PROMPT ndb_mgm> EXIT jon@valhaj:/usr/local/mysql/bin>
For additional information and examples, see Section 21.5.2, “Commands in the NDB Cluster Management Client”.
Increased FIXED column storage per fragment. NDB Cluster 7.5 and later supports a maximum of 128 TB per fragment of data in
FIXEDcolumns. In NDB Cluster 7.4 and earlier, this was 16 GB per fragment.
Deprecated parameters removed. The following NDB Cluster data node configuration parameters were deprecated in previous releases of NDB Cluster, and were removed in NDB 7.5.0:
Id: deprecated in NDB 7.1.9; replaced by
NoOfDiskPagesToDiskDuringRestartACC: both deprecated, had no effect; replaced in MySQL 5.1.6 by
DiskCheckpointSpeedInRestart, which itself was later deprecated (in NDB 7.4.1) and is now also removed.
NoOfDiskPagesToDiskAfterRestartTUP: both deprecated, and had no effect; replaced in MySQL 5.1.6 by
DiskCheckpointSpeed, which itself was later deprecated (in NDB 7.4.1) and is now also removed.
ReservedSendBufferMemory: deprecated in NDB 7.2.5; no longer had any effect.
Discless: archaic (pre-MySQL 4.1) synonym for and long since replaced by
The archaic and unused (and for this reason also previously undocumented)
ByteOrdercomputer configuration parameter was also removed in NDB 7.5.0.
The parameters just described are not supported in NDB 7.5. Attempting to use any of these parameters in an NDB Cluster configuration file now results in an error.
DBTC scan enhancements. Scans have been improved by reducing the number of signals used for communication between the
DBDIHkernel blocks in
NDB, enabling higher scalability of data nodes when used for scan operations by decreasing the use of CPU resources for scan operations, in some cases by an estimated five percent.
Also as result of these changes response times should be greatly improved, which could help prevent issues with overload of the main threads. In addition, scans made in the
BACKUPkernel block have also been improved and made more efficient than in previous releases.
JSON column support. NDB 7.5.2 and later supports the
JSONcolumn type for
NDBtables and the JSON functions found in the MySQL Server, subject to the limitation that an
NDBtable can have at most 3
Read from any replica; specify number of hashmap partition fragments. Previously, all reads were directed towards the primary replica except for simple reads. (A simple read is a read that locks the row while reading it.) Beginning with NDB 7.5.2, it is possible to enable reads from any replica. This is disabled by default but can be enabled for a given SQL node using the
ndb_read_backupsystem variable added in this release.
Previously, it was possible to define tables with only one type of partition mapping, with one primary partition on each LDM in each node, but in NDB 7.5.2 it becomes possible to be more flexible about the assignment of partitions by setting a partition balance (fragment count type). Possible balance schemes are one per node, one per node group, one per LDM per node, and one per LDM per node group.
This setting can be controlled for individual tables by means of a
PARTITION_BALANCEoption (renamed from
FRAGMENT_COUNT_TYPEin NDB 7.5.4) embedded in
ALTER TABLEstatements. Settings for table-level
READ_BACKUPare also supported using this syntax. For more information and examples, see Section 22.214.171.124, “Setting NDB_TABLE Options”.
In NDB API applications, a table's partition balance can also be get and set using methods supplied for this purpose; see Table::getPartitionBalance(), and Table::setPartitionBalance(), as well as Object::PartitionBalance, for more information about these.
As part of this work, NDB 7.5.2 also introduces the
ndb_data_node_neighboursystem variable. This is intended for use, in transaction hinting, to provide a “nearby” data node to this SQL node.
In addition, when restoring table schemas, ndb_restore
--restore_metanow uses the target cluster's default partitioning, rather than using the same number of partitions as the original cluster from which the backup was taken. See Section 126.96.36.199.2, “Restoring to More Nodes Than the Original”, for more information and an example.
NDB 7.5.3 adds a further enhancement to
READ_BACKUP: In this and later versions, it is possible to set
READ_BACKUPfor a given table online as part of
ALTER TABLE ... ALGORITHM=INPLACE ....
ThreadConfig improvements. A number of enhancements and feature additions are implemented in NDB 7.5.2 for the
ThreadConfigmultithreaded data node (ndbmtd) configuration parameter, including support for an increased number of platforms. These changes are described in the next few paragraphs.
Non-exclusive CPU locking is now supported on FreeBSD and Windows, using
cpuset. Exclusive CPU locking is now supported on Solaris (only) using the
cpuset_exclusiveparameters which are introduced in this release.
Thread prioritzation is now available, controlled by the new
thread_priois supported on Linux, FreeBSD, Windows, and Solaris, and varies somewhat by platform. For more information, see the description of
realtimeparameter is now supported on Windows platforms.
Partitions larger than 16 GB. Due to an improvement in the hash index implementation used by NDB Cluster data nodes, partitions of
NDBtables may now contain more than 16 GB of data for fixed columns, and the maximum partition size for fixed columns is now raised to 128 TB. The previous limitation was due to the fact that the
DBACCblock in the
NDBkernel used only 32-bit references to the fixed-size part of a row in the
DBTUPblock, although 45-bit references to this data are used in
DBTUPitself and elsewhere in the kernel outside
DBACC; all such references in to the data handled in the
DBACCblock now use 45 bits instead.
Print SQL statements from ndb_restore. NDB 7.5.4 adds the
--print-sql-logoption for the ndb_restore utility provided with the NDB Cluster distribution. This option enables SQL logging to
stdout. Important: Every table to be restored using this option must have an explicitly defined primary key.
See Section 21.4.24, “ndb_restore — Restore an NDB Cluster Backup”, for more information.
Organization of RPM packages. Beginning with NDB 7.5.4, the naming and organization of RPM packages provided for NDB Cluster align more closely with those released for the MySQL server. The names of all NDB Cluster RPMs are now prefixed with
mysql-cluster. Data nodes are now installed using the
data-nodepackage; management nodes are now installed from the
management-serverpackage; and SQL nodes require the
commonpackages. MySQL and
NDBclient programs, including the mysql client and the ndb_mgm management client, are now included in the
For a detailed listing of NDB Cluster RPMs and other information, see Section 188.8.131.52, “Installing NDB Cluster from RPM”.
ndbinfo processes and config_nodes tables. NDB 7.5.7 adds two tables to the
ndbinfoinformation database to provide information about cluster nodes; these tables are listed here:
config_nodes: This table provides the node ID, process type, and host name for each node listed in an NDB cluster's configuration file.
processesshows information about nodes currently connected to the cluster; this information includes the process name and system process ID; for each data node and SQL node, it also shows the process ID of the node's angel process. In addition, the table shows a service address for each connected node; this address can be set in NDB API applications using the
Ndb_cluster_connection::set_service_uri()method, which is also added in NDB 7.5.7.
System name. The system name of an NDB cluster can be used to identify a specific cluster. Beginning with NDB 7.5.7, the MySQL Server shows this name as the value of the
Ndb_system_namestatus variable; NDB API applications can use the
Ndb_cluster_connection::get_system_name()method which is added in the same release.
A system name based on the time the management server was started is generated automatically; you can override this value by adding a
[system]section to the cluster's configuration file and setting the
Nameparameter to a value of your choice in this section, prior to starting the management server.
NDB Cluster 7.5 is also supported by MySQL Cluster Manager, which provides an advanced command-line interface that can simplify many complex NDB Cluster management tasks. See MySQL™ Cluster Manager 1.4.4 User Manual, for more information.