Chapter 4 MySQL Cluster Manager Client Commands

add hosts {--hosts=|-h }host_list site_name

host_list:
    host[, host[, ...]]

This command adds one or more hosts to an existing management site. Agents using the same port as the management site must be running on any hosts added using this command. This command takes two mandatory arguments: a list of hosts (using the --hosts option or its short form -h), and the name of the site to which the hosts are to be added.

The --hosts takes a comma-separated list of one or more hosts to be added to the site.

For example, the following command adds two hosts named torsk and kolja to management site mysite:

mcm> add hosts --hosts=torsk,kolja mysite;
+--------------------------+
| Command result           |
+--------------------------+
| Hosts added successfully |
+--------------------------+
1 row in set (0.48 sec)

None of the hosts added by this command may already be members of management site site_name. Do not attempt to add again a host that is already a member of the management site using its secondary (or alternate) IP address—the mcmd process on the host is already bound to the IP address that was supplied when the host was first added, and it cannot be bound again to another IP address.

remove hosts {--hosts=|-h }host_list site_name

host_list:
    host[, host[, ...]]

This command removes one or more hosts from an existing management site. It takes as arguments a required option --hosts (or its short form -h), whose value is a comma-separated list of one or more hosts to be removed, and the name of the site from which the hosts are to be removed. A number of limitations apply:

The following command removes two hosts named tonfisk and flundra from the management site mysite:

mcm> remove hosts --hosts=tonfisk,flundra mysite;
+----------------------------+
| Command result             |
+----------------------------+
| Hosts removed successfully |
+----------------------------+
1 row in set (0.48 sec)

change log-level [{--hosts=|-h }host_list] log_level site_name

host_list:
    host[,host[,...]]

Set the management agent's cluster logging level. This has the same effect as using the --log-level option; however, unlike the option, this command can be used at run time and does not require a restart of mcmd. Issuing this command overrides any value for --log-level set on the command line or in the agent configuration file.

When used with the log_level alone without a host_list and a site_name, this command applies only to the agent the mcm client is connected to. In the following example, the logging level is set to warning only on the host managed directly by the agent to which the mcm client is connected:

mcm> change log-level warning;
+--------------------------------+
| Command result                 |
+--------------------------------+
| Log-level changed successfully |
+--------------------------------+
1 row in set (0.00 sec)

You can specify the name of a site to be affected by the command. For example, the following invocation of the command applies to the site named mysite:

mcm> change log-level debug mysite;
+--------------------------------+
| Command result                 |
+--------------------------------+
| Log-level changed successfully |
+--------------------------------+
1 row in set (0.05 sec)

You can also restrict the change to one or more hosts in a given site using the --hosts option (or its short form -h), with multiple host names separated by commas. The following command changes the logging level to debug on the hosts named tonfisk and haj, but not on any other hosts in mysite:

mcm> change log-level --hosts=tonfisk,haj debug mysite;
+--------------------------------+
| Command result                 |
+--------------------------------+
| Log-level changed successfully |
+--------------------------------+
1 row in set (0.09 sec)

You must specify a site when using the --hosts option; trying to use --hosts alone results in an error.

Accepted values for log_level are the same as for the --log-level: one of debug, critical, error, info, message, or warning. For more detailed information about the meanings and effects of these values, see NDB Cluster Logging Management Commands.

rotate log [{--hosts=|-h }host_list] [site_name]

host_list:
    host[,host[,...]]

Rotate mcmd logs for the connected MySQL Cluster Manager agent, for agents running on certain hosts, or for agents on all hosts in a management site.

For example, to rotate logs for the agent to which the client session is connected:

mcm> rotate log;
+--------------------------+
| Command result           |
+--------------------------+
| Log rotated successfully |
+--------------------------+
1 row in set (0.03 sec)

A new log file, with a timestamp in its name, is created as a result:

-rw-r-----   1 mcmd cluster    74265 Jul 15 22:45 mcmd.log
-rw-r-----   1 mcmd cluster  1197573 Jul 15 22:45 mcmd.log.2014-07-15T22-45-28

To rotate logs for agents on specific hosts like nanna12 and nanna13, use the --hosts option (or its short form -h):

mcm> rotate log --hosts=nanna12,nanna13 mysite;

To rotate logs on all agents in the management site mysite:

mcm> rotate log mysite;

collect logs [cluster_name]

This command collects log files and other related files from all hosts. When the name of a cluster (cluster_name) is supplied with the command, it collects all the log files (.log) as well as the configuration files (.ini, .cnf), error files (.err), and trace files (.trace.log.*) used by all processes belonging to the cluster, and also all the agent log files.

When an mcmd agent receives the collect logs command from the mcm agent it is connected with, it sets up a TCP server socket using port 0, and lets the operating system assign the actual port number. All agents in the site are then instructed to perform the copying, and each of them spawns a TCP client, which connects to the TCP server socket set up earlier to copy the files over.

The collected files are put under the MySQL Cluster Manager data repository (/opt/mcm_data/ by default, or specified by the option --manager-directory) inside a folder named collected_files, under which the files are organized under a hierarchy of timestamps [for the file collections] and then host names; below the host name level, the file organization mimics that on the host. For example, the agent log for the host tonfisk, collected on 2014-07-31 at 07:44:05, is found at:

 /opt/mcm_data/collected-files/2014-07-31T07:44:05Z/tonfisk/opt/mysql/logs/mcmd-tonfisk-19001.log

If cluster_name is omitted, only the agent log files are collected.

create site {--hosts=|-h }host_list site_name

host_list:
    host[,host[,...]]

The create site command is used to create a MySQL Cluster Manager management site; that is, a set of MySQL Cluster Manager management agents running on one or more host computers. The command requires a list of one or more hosts where management agents are running and a name for the site. The host list is passed as the value of the --hosts option (short form: -h).

This is an example of a create site command that creates a site named mysite, consisting of the hosts tonfisk and flundra:

mcm> create site --hosts=tonfisk,flundra mysite;
+---------------------------+
| Command result            |
+---------------------------+
| Site created successfully |
+---------------------------+
1 row in set (0.31 sec)

mcm> list sites;
+--------+------+-------+-----------------+
| Site   | Port | Local | Hosts           |
+--------+------+-------+-----------------+
| mysite | 1862 | Local | tonfisk,flundra |
+--------+------+-------+-----------------+
1 row in set (0.06 sec)

Agents must be running on all hosts specified in the --hosts option when create site is executed; otherwise, the command fails with the error Agent on host host:port is unavailable. The host where the agent used to issue the command is running must be one of the hosts listed. Otherwise, the command fails with the error Host host_name is not a member of site site_name.

A given agent may be a member of one site only; if one of the management agents specified in the host_list already belongs to a site, the command fails with the error Host host is already a member of site site.

delete site site_name

The delete site command deletes an existing management site. The command does not stop or remove any agents making up the deleted site; instead, these agents continue to run, and remain available for use in other sites.

The command takes a single argument, the name of the site to be deleted. This example shows the deletion of a management site named mysite:

mcm> delete site mysite;
+---------------------------+
| Command result            |
+---------------------------+
| Site deleted successfully |
+---------------------------+
1 row in set (0.38 sec)

If the site to be deleted does not exist, the command fails with the error Command requires a site to be defined. If there are any packages referencing hosts belonging to the site, delete site fails with the error Packages exist in site site_name. The command also fails if there are defined any clusters that include hosts belonging to the site.

list sites

This command returns a list of the sites known to the management agent. It does not require any arguments. An example is shown here:

mcm> list sites;
+--------+------+-------+-----------------+
| Site   | Port | Local | Hosts           |
+--------+------+-------+-----------------+
| mysite | 1862 | Local | tonfisk,flundra |
+--------+------+-------+-----------------+
1 row in set (0.06 sec)

The output of list sites contains the following columns:

list hosts [--verbose|-v]  site_name

The list hosts command is used to obtain a list of the hosts comprising a given management site. The command requires a single argument, the name of the site to be examined. For each host listed, the information returned includes the hostname, status, and version of the management agent software in use, as shown in this example:

mcm> list hosts mysite;
+-----------+-----------+---------+
| Host      | Status    | Version |
+-----------+-----------+---------+
| tonfisk   | Available | 1.4.1   |
+-----------+-----------+---------+
| flundra   | Available | 1.4.1   |
+-----------+-----------+---------+
2 rows in set (0.16 sec)

If you omit the site_name argument, the command fails with an error, as shown here:

mcm> list hosts;
ERROR 6 (00MGR): Illegal number of operands

Using the --verbose option (short form : -v) causes the command to print additional information on the hosts:

mcm> list hosts --verbose mysite;
+---------+-----------+---------+-------+---------+-------------------------------+
| Host    | Status    | Version | Cores | Memory  | OS                            |
+---------+-----------+---------+-------+---------+-------------------------------+
| tonfisk | Available |  1.4.1  | 1     | 1819 Mb | Linux 3.13.11-100.fc19.x86_64 |
| flundra | Available |  1.4.1  | 1     | 1819 Mb | Linux 3.13.11-100.fc19.x86_64 |
+---------+-----------+---------+-------+---------+-------------------------------+
2 rows in set (0.07 sec)

show settings [--hostinfo]

This command lists the current values of a number of mcmd options:

mcm> show settings;
+-------------------+-----------------------------------------------------------------------------+
| Setting           | Value                                                                       |
+-------------------+-----------------------------------------------------------------------------+
| log-file          | /opt/mcm_data/mcmd.log
| log-level         | message                                                                     |
| log-use-syslog    | FALSE                                                                       |
| manager-directory | /opt/mcm_data           
| manager-username  | mcmd                                                                        |
| manager-password  | ********                                                                    |
| manager-port      | 1862                                                                        |
| xcom-port         | 18620                                                                       |
+-------------------+-----------------------------------------------------------------------------+
8 rows in set (0.00 sec)

Using the --hostinfo option makes the command print out information on the host that the mcm client is connected to:

mcm> show settings --hostinfo;
+-----------------+-------------------------------+
| Property        | Value                         |
+-----------------+-------------------------------+
| Hostname        | localhost.localdomain         |
| Platform        | Linux 3.13.11-100.fc19.x86_64 |
| Processor cores | 1                             |
| Total memory    | 1819 Mb                       |
+-----------------+-------------------------------+
4 rows in set (0.00 sec)

stop agents  [[--hosts=host_list] site_name]

This command stops one or more MySQL Cluster Manager agents on one or more hosts.

When used without any arguments, stop agents stops the agent to which the client is currently connected.

When used with the name of a management site, the command stops all agents running on hosts making up the site. The following stops all MySQL Cluster Manager agents running on hosts in mysite:

mcm> stop agents mysite;

You can also stop a subset of the agents in a given management site by listing the hosts where they are running with the --hosts option (short form: -h), along with the name of the site to which they belong. The result of the following command is to stop MySQL Cluster Manager agents running on hosts kolja and torsk, both of which are members of the management site mysite:

mcm> stop agents --hosts=kolja,torsk mysite;

Multiple host names following the --hosts option should be separated by commas, with no intervening spaces. Invoking stop agents with this option without supplying a site_name causes a syntax error. Using an undefined site_name or names of hosts not belonging to the site with this command also results in an error.

version

This command displays the version of the MySQL Cluster Manager software in use by the MySQL Cluster Manager agent to which this client is connected, as shown here:

mcm> version;
+-------------------------------------+
| Version                             |
+-------------------------------------+
| MySQL Cluster Manager 1.4.1 (64bit) |
+-------------------------------------+
1 row in set (0.00 sec)

The version command takes no arguments.

Using the show warnings command, you can check the warnings (up to the last five) issued to the agent log (mcmd.log). For example:

mcm> set delayed_insert_timeout:mysqld=400 mycluster;
+-----------------------------------+
| Command result                    |
+-----------------------------------+
| Cluster reconfigured successfully |
+-----------------------------------+

mcm> show warnings;
+---------+------+-----------------------------------------------------------------------+
| Level   | Code | Message                                                               |
+---------+------+-----------------------------------------------------------------------+
| Warning | -1   | Config variable delayed_insert_timeout was deprecated in mysqld 5.6.7 |
+---------+------+-----------------------------------------------------------------------+

add package {--basedir=|-b }path
    [{--hosts=|-h }host_list] package_name

host_list:
    host[,host[,...]]

This command creates a new package, or, if the package named package_name already exists, this command extends the package definition.

The --basedir option (short form: -b) indicates the location of the MySQL Cluster installation directory on the listed hosts, and is required. This must be the path to the top-level directory where the MySQL Cluster software is located (for example, /usr/local/mysql), and should not include the MySQL Cluster bin, libexec, or other subdirectory within the installation directory.

Hosts may be specified as a comma-separated list, using the --hosts option (short form: -h); however, this option is not required. If --hosts is omitted, the path is assumed to be valid for all hosts in the cluster that is created using this package (see Section 4.4.1, “The create cluster Command”).

Suppose we have two Linux hosts named tonfisk and flundra, and the MySQL Cluster software is installed in /usr/local/mysql on both hosts. In this case, you can create a package named mypackage that accounts for both hosts as shown here:

mcm> add package --basedir=/usr/local/mysql mypackage;
+----------------------------+
| Command result             |
+----------------------------+
| Package added successfully |
+----------------------------+
1 row in set (0.71 sec)

When this package is used to create a cluster, the MySQL Cluster Manager knows that it should find the MySQL Cluster software in the /usr/local/mysql directory on each of the hosts.

For options to MySQL Cluster Manager client command options having Windows paths as values, you must use forward slashes (/) in place of backslashes (\), so if tonfisk and flundra are Windows hosts where MySQL Cluster has been installed to the directory C:\mysql, the corresponding add package command would look like this (with the --basedir option highlighted):

mcm> add package --basedir=c:/mysql mypackage;
+----------------------------+
| Command result             |
+----------------------------+
| Package added successfully |
+----------------------------+
1 row in set (0.71 sec)

In the example just given, we could also have issued the command as add package --basedir=/usr/local/mysql --hosts=tonfisk,flundra mypackage (or add package --basedir=c:/mysql --hosts=tonfisk,flundra mypackage on Windows) with the same result, but the --hosts option was not required, since the MySQL Cluster software's location is the same on each host. Let us suppose, however, that the software is installed in /usr/local/ndb-host-10 on host tonfisk and in /usr/local/ndb-host-20 on host flundra. In this case, we must issue 2 separate commands, specifying the host as well as the base directory in each case, as shown here:

mcm> add package --basedir=/usr/local/ndb-host-10
   >   --hosts=tonfisk yourpackage;
+----------------------------+
| Command result             |
+----------------------------+
| Package added successfully |
+----------------------------+
1 row in set (0.68 sec)

mcm> add package --basedir=/usr/local/ndb-host-20
   >   --hosts=flundra yourpackage;
+----------------------------+
| Command result             |
+----------------------------+
| Package added successfully |
+----------------------------+
1 row in set (0.81 sec)

Assuming that both hosts belong to a site called mysite, you can verify that these packages have been created as desired using the list packages command, as shown here:

mcm> list packages mysite;
+-------------+---------------------------------------+-----------------+
| Package     | Path                                  | Hosts           |
+-------------+---------------------------------------+-----------------+
| yourpackage | /usr/local/ndb-host-10                | tonfisk         |
|             | /usr/local/ndb-host-20                | flundra         |
| mypackage   | /usr/local/mysql                      | tonfisk,flundra |
+-------------+---------------------------------------+-----------------+
3 rows in set (1.07 sec)

(For more information about this command, see Section 4.3.3, “The list packages Command”.)

It is possible to assign the same base directory (or directories) on the same host (or hosts) to multiple packages, as shown in this example, in which we assume that hosts tonfisk and flundra have previously been assigned to a site named mysite:

mcm> add package -b /usr/local/mysql-cluster mypackage;
+----------------------------+
| Command result             |
+----------------------------+
| Package added successfully |
+----------------------------+
1 row in set (1.41 sec)

mcm> add package -b /usr/local/mysql-cluster yourpackage;
+----------------------------+
| Command result             |
+----------------------------+
| Package added successfully |
+----------------------------+
1 row in set (1.58 sec)

mcm> list packages mysite;
+-------------+--------------------------+-----------------+
| Package     | Path                     | Hosts           |
+-------------+--------------------------+-----------------+
| mypackage   | /usr/local/mysql-cluster | tonfisk,flundra |
| yourpackage | /usr/local/mysql-cluster | tonfisk,flundra |
+-------------+--------------------------+-----------------+
2 rows in set (0.50 sec)

delete package [{--hosts=|-h }host_list] package_name

host_list:
    host[,host[,...]]

This command is used to unregister a package. More specifically, it removes any references to MySQL Cluster software installations added to the agent's repository when the package was created. delete package does not remove any MySQL Cluster installations; the command removes only references to the installations. Once a package has been unregistered, it can no longer be used for a create cluster command. The MySQL Cluster binaries remain, but cannot be used in a MySQL Cluster administered using the MySQL Cluster Manager unless and until the base directory containing them has been registered with another package. (It is possible to register a base directory with multiple packages; see Section 4.3.1, “The add package Command”, for more information and an example.)

If the --hosts option (short form: -h) is used with this command, the base directory settings for the host or hosts named by the option are removed as well. All hosts given in the host_list must be members of the site to which the package is registered. Otherwise, the command fails.

A package that is in use by a cluster cannot be unregistered; the cluster must first be deleted (see Section 4.4.2, “The delete cluster Command”).

Here is an example that demonstrates how to unregister a package named mypackage:

mcm> delete package mypackage;
+------------------------------+
| Command result               |
+------------------------------+
| Package deleted successfully |
+------------------------------+
1 row in set (1.23 sec)

You can also verify that the package was unregistered using the list packages command; the package name should no longer appear in the output of this command. If you attempt to use the unregistered package in a create cluster command, the command fails, as shown here:

mcm> create cluster --package=mypackage
   > --processhosts=ndb_mgmd@tonfisk,ndbd@grindval,ndbd@flundra,mysqld@tonfisk mycluster;
ERROR 4001 (00MGR): Package mypackage not defined

An upgrade cluster command that references an unregistered package also fails.

list packages [package_name] site_name

This command lists registered packages. It requires a single argument, that being the name of the site with which the packages are registered, as shown in this example:

mcm> list packages mysite;
+-------------+---------------------------------------+-----------------+
| Package     | Path                                  | Hosts           |
+-------------+---------------------------------------+-----------------+
| yourpackage | /usr/local/ndb-host-10                | tonfisk         |
|             | /usr/local/ndb-host-20                | flundra         |
| mypackage   | /usr/local/mysql                      | tonfisk,flundra |
+-------------+---------------------------------------+-----------------+
3 rows in set (1.07 sec)

If tonfisk and flundra are Windows hosts, the list of packages might look something like this:

mcm> list packages mysite;
+-------------+---------------------------------------+-----------------+
| Package     | Path                                  | Hosts           |
+-------------+---------------------------------------+-----------------+
| yourpackage | c:/cluster/ndb-host-10                | tonfisk         |
|             | c:/cluster/ndb-host-20                | flundra         |
| mypackage   | c:/mysql                              | tonfisk,flundra |
+-------------+---------------------------------------+-----------------+
3 rows in set (1.07 sec)

In the example just shown, yourpackage uses the MySQL Cluster binaries installed at C:\cluster\ndb-host-10 on host tonfisk, and at C:\cluster\ndb-host-20 on flundra; mypackage uses MySQL Cluster binaries installed at C:\mysql on both hosts.

The output contains three columns; these are described in the following list:

You can filter the results so that information relating to only a single package is displayed by supplying the package name before the site name, as shown here:

mcm> list packages yourpackage mysite;
+-------------+---------------------------------------+-----------------+
| Package     | Path                                  | Hosts           |
+-------------+---------------------------------------+-----------------+
| yourpackage | /usr/local/ndb-host-10                | tonfisk         |
|             | /usr/local/ndb-host-20                | flundra         |
+-------------+---------------------------------------+-----------------+
2 rows in set (0.55 sec)

(See Section 4.3.1, “The add package Command”, for the add package commands that were used to create yourpackage.)

When a package contains MySQL Cluster installations using different base directories on different hosts, each unique combination of path and host is shown in its own row. However, the name of the package is displayed in the first row only; all rows that immediately follow this row and that do not contain the package name also relate to the same package whose name is shown in the first preceding row to display a package name. For example, consider the list packages command and output shown here:

mcm> list packages mysite;
+-------------+---------------------------------------+---------+
| Package     | Path                                  | Hosts   |
+-------------+---------------------------------------+---------+
| yourpackage | /usr/local/ndb-host-10                | tonfisk |
|             | /usr/local/ndb-host-20                | flundra |
| mypackage   | /usr/local/mysql                      | tonfisk |
|             | /usr/local/bin/mysql                  | flundra |
+-------------+---------------------------------------+---------+
3 rows in set (1.07 sec)

This output shows that there are two packages defined for the site named mysite; these packages are named yourpackage and mypackage. The package yourpackage consists of the MySQL Cluster binaries in the directory /usr/local/ndb-host-10 on host tonfisk, and in the directory /usr/local/ndb-host-20 on host flundra. The package named mypackage consists of the MySQL Cluster binaries in the directory /usr/local/mysql on host tonfisk, and in the directory /usr/local/bin/mysql on host flundra.

If you omit the site_name argument, the command fails with an error, as shown here:

mcm> list packages;
ERROR 6 (00MGR): Illegal number of operands

create cluster {--package=|-P }package_name
    {--processhosts=|-R }process_host_list cluster_name
    [(--import|-m) cluster_name] [--verbose | -v]

process_host_list:
    process_name[:node_id]@host[,process_name@host[,...]]

process_name:
    {ndb_mgmd|ndbd|ndbmtd|mysqld|ndbapi}

This command creates a cluster to be managed by the MySQL Cluster Manager. However, it does not start the cluster (see Section 4.4.7, “The start cluster Command”).

This command can also be used to create a cluster earmarked specifically as a target for importing another cluster that is not already under MySQL Cluster Manager control, as described later in this section, by employing the --import option. See also Section 3.5, “Importing MySQL Clusters into MySQL Cluster Manager”.

create cluster requires the following arguments:

An additional --verbose option for this command causes create cluster to output extra information as it is executed, as shown later in this section.

The --import option flags the cluster as being created as a target for importing a cluster created outside MySQL Cluster Manager. This option causes the cluster's status to appear as import in the output of show status, as shown here:

mcm> show status --process newcluster;
+--------+----------+-------+--------+-----------+--------------+
| NodeId | Process  | Host  | Status | Nodegroup | Package      |
+--------+----------+-------+--------+-----------+--------------+
| 1      | ndb_mgmd | alpha | import |           | newpackage   |
| 5      | ndbd     | beta  | import | n/a       | newpackage   |
| 6      | ndbd     | gamma | import | n/a       | newpackage   |
| 10     | mysqld   | delta | import |           | newpackage   |
| 11     | ndbapi   | *     | import |           |              |
+--------+----------+-------+--------+-----------+--------------+
6 rows in set (0.04 sec)

Having the import status causes any of the commands start cluster, restart cluster, start process, and stop process to fail if they are executed before an import cluster command has been executed against this cluster. It is also not possible to execute upgrade cluster on a cluster having processes with import status. Other operations on this cluster continue to be performed normally.

For more information about importing clusters into MySQL Cluster Manager, including examples, see Section 3.5, “Importing MySQL Clusters into MySQL Cluster Manager”.

Example

Consider the following command issued in the MySQL Cluster Manager client, which creates a cluster named mycluster:

mcm> create cluster --package=mypackage
  -> --processhosts=ndb_mgmd@flundra,ndbd@tonfisk,ndbd@grindval,mysqld@flundra
  -> mycluster;
+------------------------------+
| Command result               |
+------------------------------+
| Cluster created successfully |
+------------------------------+
1 row in set (7.71 sec)

As defined by the command just shown, mycluster consists of four nodes: a management node on host flundra; two data nodes—one on each of the hosts tonfisk and grindval; and one SQL node, also on host flundra.

Using the --verbose option causes the command to print output similar to that produced by the list processes command, as shown here:

mcm> create cluster --verbose --package=mypackage
  -> --processhosts=ndb_mgmd@flundra,ndbd@tonfisk,ndbd@grindval,mysqld@flundra
  -> mycluster;
+--------+----------+----------+
| NodeId | Name     | Host     |
+--------+----------+----------+
| 49     | ndb_mgmd | flundra  |
| 1      | ndbd     | tonfisk  |
| 2      | ndbd     | grindval |
| 50     | mysqld   | flundra  |
+--------+----------+----------+
4 rows in set (0.32 sec)

You can also create this cluster in such a way that the mysqld process is permitted to connect to the cluster from any host able to reach the other cluster hosts over the network as shown here:

mcm> create cluster --package=mypackage
  -> --processhosts=ndb_mgmd@flundra,ndbd@tonfisk,ndbd@grindval,mysqld@*
  -> mycluster;
+------------------------------+
| Command result               |
+------------------------------+
| Cluster created successfully |
+------------------------------+
1 row in set (7.71 sec)

Configuration changes to the newly-created cluster can be made using the set command prior to starting the cluster. This is often preferable to doing after the cluster has been started, since set commands used to make configuration changes in a running cluster can require a rolling restart, and rolling restarts of clusters having many nodes or large quantities of data (or both) may take a great deal of time to complete.

delete cluster [--removedirs] cluster_name

This command deletes the cluster named cluster_name, removing it from the list of clusters managed by MySQL Cluster Manager.

delete cluster does not remove any MySQL Cluster binaries from hosts. However, it does remove the cluster configuration, data, and log files that reside in the MySQL Cluster Manager data repository (which is usually at /opt/mcm_data/).

This example demonstrates how to delete a cluster named mycluster:

mcm> delete cluster mycluster;
+------------------------------+
| Command result               |
+------------------------------+
| Cluster deleted successfully |
+------------------------------+
1 row in set (1.22 sec)

A look at the MySQL Cluster Manager data repository (at /opt/mcm_data/ in this case) shows that the folder that used to host the configuration, data, and log files for mycluster (/opt/mcm_data/clusters/mycluster) no longer exists:

shell> ls -l /opt/mcm_data/clusters
total 0

To remove the configuration and data files outside of the MySQL Cluster Manager data repository, delete cluster must be invoked with the --removedirs option, like this:

mcm> delete cluster --removedirs mycluster;
+------------------------------+
| Command result               |
+------------------------------+
| Cluster deleted successfully |
+------------------------------+
1 row in set (1.22 sec)

For example, if one of the data node on mycluster has its data directory outside of the MySQL Cluster Manager data repository:

mcm> get Datadir mycluster;
+---------+---------------------------+----------+---------+----------+---------+---------+---------+
| Name    | Value                     | Process1 | NodeId1 | Process2 | NodeId2 | Level   | Comment |
+---------+---------------------------+----------+---------+----------+---------+---------+---------+
| DataDir | /home/dso/mycluster/cdata | ndbd     | 1       |          |         | Process |         |
...

Deleting mycluster without using --removedirs does not remove the data directory for node 1:

shell> ls -l /home/dso/mycluster
total 4 drwxr-xr-x. 3 dso dso 4096 Sep 10 18:00 cdata

However, if the --removedirs option is used, the data directory for node 1 also gets removed:

shell> ls -l /home/dso/mycluster
total 0

delete cluster fails if the cluster to be deleted is running, as shown here:

mcm> delete cluster mycluster;
ERROR 5010 (00MGR): All processes must be stopped to delete cluster mycluster

You must shut down the cluster first, using stop cluster.

list clusters site_name

This command lists all clusters defined for a given management site named site_name, together with the package used by each cluster. For example, the command shown here displays a list of all clusters defined for the site named mysite:

mcm> list clusters mysite;
+------------------+----------+
| Cluster          | Package  |
+------------------+----------+
| mycluster        | m-7.1.26 |
| yourcluster      | y-7.1.26 |
| someothercluster | s-7.2.9  |
+------------------+----------+
3 rows in set (2.07 sec)

If site_name is omitted, the command fails with an error, as shown here:

mcm> list packages;
ERROR 6 (00MGR): Illegal number of operands

list nextnodeids cluster_name

MySQL Cluster Manager normally assigns IDs to new node processes automatically (although this can be overridden when issuing the create cluster or add process command). The list nextnodeids command can be used to see the next node ID that MySQL Cluster Manager has reserved for the next new process (of each possible process type) to be added to the cluster named cluster_name, which is required.

mcm> list nextnodeids mycluster;
+-----------+--------------+-------------+--------------------------+
| Category  | NodeId Range | Next NodeId | Processes                |
+-----------+--------------+-------------+--------------------------+
| Datanodes | 1  - 48      | 5           | ndbd, ndbmtd             |
| Others    | 49 - 255     | 52          | ndb_mgmd, mysqld, ndbapi |
+-----------+--------------+-------------+--------------------------+
2 rows in set (0.07 sec)

restart cluster cluster_name

This command performs a rolling restart (see Performing a Rolling Restart of an NDB Cluster) of the cluster named cluster_name. The cluster must already be running in order for this command to succeed. (For information about how to determine the operation state of the cluster, see Section 4.4.6, “The show status Command”.)

For example, the command shown here performs a rolling restart of the cluster named mycluster:

mcm> restart cluster mycluster;
+--------------------------------+
| Command result                 |
+--------------------------------+
| Cluster restarted successfully |
+--------------------------------+
1 row in set (1 min 22.53 sec)

If the cluster is not already running, restart cluster fails with an error, as shown here:

mcm> show status --cluster mycluster;
+-----------+---------+---------+
| Cluster   | Status  | Comment |
+-----------+---------+---------+
| mycluster | stopped |         |
+-----------+---------+---------+
1 row in set (1.49 sec)

mcm> restart cluster mycluster;
ERROR 5009 (00MGR): Restart can not be performed as processes are
stopped in cluster mycluster

Currently, there is no mechanism in MySQL Cluster Manager for performing system initial restarts of a cluster. This means that attributes that require an initial restart to be changed must be set before the cluster is started for the first time.

show status --cluster|-c cluster_name
show status --operation|-o cluster_name
show status --backup|-b cluster_name
show status --process|-r cluster_name

This command is used to check the status of clusters, cluster processes, backups, and commands issued in the MySQL Cluster Manager client. The type of status returned depends on which of the four options of --cluster (short form: -c), --operation (short form: -o), --backup (short form: -b), or --process (short form -r) is used with the command. (If none of these is used, --cluster is assumed.) These options are described in more detail in the next few paragraphs.

--cluster option

When this option is used, show status reports on the status of the cluster named cluster_name, as shown in this example:

mcm> show status --cluster mycluster;
+-----------+-------------------+---------+
| Cluster   | Status            | Comment |
+-----------+-------------------+---------+
| mycluster | fully operational |         |
+-----------+-------------------+---------+
1 row in set (0.01 sec)

When used with the --cluster option (short form: -c), the output of this command consist of two columns. The Cluster column contains the name of the cluster. The Status column contains a description of the cluster's status; possible values and their meanings are shown in the following table:

--operation option

When the --operation option (short form: -o) is used, it causes SHOW STATUS to display the status of the latest command to be executed. This includes commands that were issued using the --background option (short form -B). An example of this command is shown here:

mcm> show status --operation mycluster;
+-----------------+-----------+--------------+
| Command         | Status    | Description  |
+-----------------+-----------+--------------+
| restart cluster | executing | <no message> |
+-----------------+-----------+--------------+
1 row in set (1.60 sec)

The output contains 3 columns, described in the following list:

Possible values for the Status column, together with descriptions of these values, are shown in the following table:

--backup option

When this option is used, show status reports on the status of the backup process for the cluster named cluster_name, as shown in the following examples:

mcm> show status --backup mycluster;
+-----------------------------------------+
| Command result                          |
+-----------------------------------------+
| No backup currently active in mycluster |
+-----------------------------------------+
1 row in set (0.05 sec)

mcm> show status --backup mycluster;
+-----------------------------------------+
| Command result                          |
+-----------------------------------------+
| BackupId 5 currently active in mycluster|
+-----------------------------------------+
1 row in set (0.09 sec)

--process option

When run with this option, show status returns information about each process in the cluster named cluster_name, as shown in this example:

mcm> show status --process mycluster;
+------+----------+----------+---------+-----------+
| Id   | Process  | Host     | Status  | Nodegroup |
+------+----------+----------+---------+-----------+
| 1    | ndb_mgmd | tonfisk  | running |           |
| 2    | ndbd     | flundra  | running | 0         |
| 3    | ndbd     | grindval | running | 0         |
| 4    | mysqld   | lax      | running |           |
+------+----------+----------+---------+-----------+
4 rows in set (1.67 sec)

When the --process option (short form: -r) is used with show status, the output contains 5 columns, described in the following list:

Possible values for the Status column are shown in the following table, together with a description of what this value represents:

You must supply the name of an existing cluster with this command, or else show status fails with an error, as shown here:

mcm> show status;
ERROR 6 (00MGR): Illegal number of operands

mcm> show status -c nosuchcluster;
ERROR 5001 (00MGR): Cluster nosuchcluster not defined

start cluster [--initial|-i] cluster_name

This command starts the cluster named cluster_name, as shown in this example:

mcm> start cluster mycluster;
+------------------------------+
| Command result               |
+------------------------------+
| Cluster started successfully |
+------------------------------+
1 row in set (45.37 sec)

In order for the command to succeed, the cluster named in the command must already exist; otherwise the command fails with the error Cluster cluster_name not defined, as shown here:

mcm> list sites;
+--------+------+-------+------------------------------+
| Site   | Port | Local | Hosts                        |
+--------+------+-------+------------------------------+
| mysite | 1862 | Local | tonfisk,flundra,grindval,haj |
+--------+------+-------+------------------------------+
1 row in set (1.72 sec)

mcm> list clusters mysite;
+-----------+-----------+
| Cluster   | Package   |
+-----------+-----------+
| mycluster | mypackage |
+-----------+-----------+
1 row in set (1.70 sec)

mcm> start cluster yourcluster;
ERROR 5001 (00MGR): Cluster yourcluster not defined

In addition, the cluster must not already be running, as shown here:

mcm> show status --cluster mycluster;
+-----------+-------------------+---------+
| Cluster   | Status            | Comment |
+-----------+-------------------+---------+
| mycluster | fully operational |         |
+-----------+-------------------+---------+
1 row in set (0.01 sec)

mcm> start cluster mycluster;
ERROR 5005 (00MGR): Cluster mycluster is running

A cluster created for import cannot be started until the import has been completed. See Section 4.4.1, “The create cluster Command”, and Section 3.5, “Importing MySQL Clusters into MySQL Cluster Manager”, for more information.

--initial option

The --initial option (short form: -i) causes all cluster data node processes to be started as if start process --initial had been used, which means that all data nodes wipe their data and start with clean data node file systems. NDB tables that were previously stored in the cluster are lost.

Under normal circumstances, you should use this option to start a cluster only when either you do not wish to preserve any of its data (and want to make a clean start), or you intend to restore the cluster from backup to a known good state (see Section 4.7.4, “The restore cluster Command”). You should also be aware that no special warnings are printed by the mcm client when --initial is used with start cluster; the command is immediately executed.

For information about creating cluster backups, see Section 4.7.2, “The backup cluster Command”. If you need to know which backups are available (if any), use list backups.

Using the --initial option with start cluster does not cause mysql_install_db to be executed, or the mysql system database to be altered or removed, on any SQL nodes. This option also does not remove MySQL Cluster Disk Data tablespace files; if their removal is needed, it must be performed manually.

stop cluster cluster_name

This command stops the cluster named cluster_name, if it is running, as shown in this example:

mcm> stop cluster mycluster;
+------------------------------+
| Command result               |
+------------------------------+
| Cluster stopped successfully |
+------------------------------+
1 row in set (21.31 sec)

stop cluster fails if the cluster is not in an operational state (see Section 4.4.6, “The show status Command”, for information about obtaining the cluster's status):

mcm> show status --cluster mycluster;
+-----------+---------+---------+
| Cluster   | Status  | Comment |
+-----------+---------+---------+
| mycluster | stopped |         |
+-----------+---------+---------+
1 row in set (0.01 sec)

mcm> stop cluster mycluster;
ERROR 5006 (00MGR): Cluster mycluster is stopped

stop cluster cannot be used on a cluster created for import until the import has been completed. See Section 4.4.1, “The create cluster Command”, and Section 3.5, “Importing MySQL Clusters into MySQL Cluster Manager”, for more information.

autotune [--dryrun] [--writeload=writeload] template cluster_name

writeload:
    {low|medium|high}

template:
    {web|realtime|test}   

The command autotune a number of parameters for the cluster according to the specified values for the template argument and the [optional] writeload option, in order to optimize the cluster's performance.

The valid values for template are:

The valid values for --writeload are:

The cluster must be in the created or fully operational status for this command to work, or an error will result. The command tunes the cluster by issuing a number of set commands to adjust different parameters, and then performs a rolling restart for the cluster.

When the --dryrun option is used, the command does not make any actual changes to the cluster, but writes the set commands that it will issue for tuning into the file /path-to-mcm-data-repository/clusters/clustername/tmp/autotune.message_id.mcm.

mcm> autotune --dryrun --writeload=high realtime mycluster;
+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
| Command result                                                                                                                                                               |
+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
| Autotuning calculation complete. Please check /opt/mcm_data/clusters/mycluster/tmp/autotune.30fcce24_2184_0.mcm on host flundra for settings that will be applied.. |
+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
1 row in set (0.62 sec)

shell> cat /opt/mcm_data/clusters/mycluster/tmp/autotune.30fcce24_2184_0.mcm
# The following will be applied to the current cluster config:
set HeartbeatIntervalDbDb:ndbmtd=1500 mycluster;
set HeartbeatIntervalDbApi:ndbmtd=1500 mycluster;
set RedoBuffer:ndbmtd=64M mycluster;
set SharedGlobalMemory:ndbmtd=20M mycluster;
set DataMemory:ndbmtd=83886080 mycluster;
set IndexMemory:ndbmtd=18874368 mycluster;
set MaxNoOfExecutionThreads:ndbmtd=2 mycluster;
set FragmentLogFileSize:ndbmtd=256M mycluster;
set NoOfFragmentLogFiles:ndbmtd=3 mycluster;

After checking out those changes in the .mcm file, if you do not want to apply all of them to your cluster, you can edit the .mcm file as desired, and then execute it at the mcm client (see Section 3.5.2.3, “Creating and Configuring the Target Cluster” for how to do that). If you are happy with all the changes described in the file, issue the autotune command again without the --dryrun option, to perform the tuning:

mcm> autotune --writeload=high realtime mycluster;
+-----------------------------------------------------+
| Command result                                      |
+-----------------------------------------------------+
| Cluster successfully autotuned to template realtime |
+-----------------------------------------------------+
1 row in set (2 min 58.09 sec)

upgrade cluster {--package=|-P }package_name
 [{--nodeid|-n }node_id_list] [--force|-f]
 [--retry|-L] [--set=attribute_assignment_list] cluster_name

node_id_list:
    node_id[, node_id[, ...]]

attribute_assignment_list:
    attribute_assignment[,attribute_assignment][,...]

attribute_assignment:
    attribute_name:process_name[=value]

This command upgrades the cluster named cluster_name to the software package package_name specified with the --package. It accomplishes this by performing a rolling restart of the cluster.

The new package must be registered using add package before you can use it for an upgrade; otherwise, upgrade cluster fails with an error.

To use the command to perform an upgrade on a cluster, unless some special options are used (see explanations on the --force, --retry, and --nodeid options below), the cluster must be in the fully operational status (you can check that using the command show status --cluster cluster_name). A cluster created for import cannot be upgraded until the import has been completed. See Section 4.4.1, “The create cluster Command”, and Section 3.5, “Importing MySQL Clusters into MySQL Cluster Manager”, for more information.

Suppose mycluster is using MySQL Cluster NDB 7.4.8, and the binaries are registered with a package named 7.4.8, as shown by this list clusters command:

mcm> list clusters mysite;
+-----------+---------+
| Cluster   | Package |
+-----------+---------+
| mycluster | 7.4.8   |
+-----------+---------+
1 row in set (1.80 sec)

Now you wish to upgrade mycluster to MySQL Cluster NDB . Assuming that you have placed the NDB 7.5.4 binaries in the same directory on each host, the add package command to create a new package named 7.5.4 that contains these binaries might look something like this:

mcm> add package --basedir=/usr/local/ndb-7.5.4 7.5.4;
+----------------------------+
| Command result             |
+----------------------------+
| Package added successfully |
+----------------------------+
1 row in set (0.88 sec)

Both packages should now be listed in the output of the command list packages mysite. To perform the upgrade to the 7.5.4 package, use the upgrade cluster command as shown here:

mcm> upgrade cluster --package=7.5.4 mycluster;
+-------------------------------+
| Command result                |
+-------------------------------+
| Cluster upgraded successfully |
+-------------------------------+
1 row in set (3 min 17.00 sec)

Once the upgrade cluster command has been successfully executed, you can verify that mycluster is now using the 7.5.4 package from the output of the appropriate list clusters command:

mcm> list clusters mysite;
+-----------+---------+
| Cluster   | Package |
+-----------+---------+
| mycluster | 7.5.4   |
+-----------+---------+
1 row in set (1.80 sec)

The command can perform major as well as minor series upgrades. Despite the name of this command, upgrade cluster can also be used to perform MySQL Cluster downgrades.

Not all upgrades and downgrades between different versions of MySQL Cluster are supported by the command. Three criteria must be met:

When using the upgrade cluster command, you can use the --set option to reconfigure your MySQL Cluster at the same time. This is particularly helpful when the upgrade requires configuration changes to your cluster. This option takes as its argument an attribute assignment list similar in format to that used with the get and set commands; see description of the set command on the proper way to formulate an attribute assignment list. For example: if you want to change the memory assigned to each data node for storing database records to 750M, specify that with the --set option in your upgrade cluster command:

mcm> upgrade cluster --package=7.5.4 --set=DataMemory:ndbd=750M  mycluster;
+-------------------------------+
| Command result                |
+-------------------------------+
| Cluster upgraded successfully |
+-------------------------------+
1 row in set (3 min 17.04 sec)

Options for dealing with failed upgrades

The --force option (-f for short) should be used when you want to run the upgrade cluster command again after a failed upgrade attempt that ends up with any failed management or data nodes. Without the --force option, the upgrade cluster command only runs when the cluster is in the fully operational status.

The --retry option (-L for short) should be used when you want to retry the upgrade cluster command after a failed attempt that ends up with some nodes being upgraded, and some not. Without the --retry option, the upgrade cluster command cannot be run on the same cluster twice using the same package.

In the case of a failed or incomplete upgrade, instead of using the --force and --retry option, you can also choose to retry the upgrade only on the failed nodes by specifying them using the --nodeid option (-n in short). Check for any failed nodes after a failed upgrade:

mcm> upgrade cluster -P next mycluster;
ERROR 7006 (00MGR): Process error: <reason of failure>
mcm> show status --process mycluster;
+--------+----------+----------+---------+-----------+-----------+
| NodeId | Process  | Host     | Status  | Nodegroup | Package   |
+--------+----------+----------+---------+-----------+-----------+
| 49     | ndb_mgmd | thinkpad | running |           | next      |
| 1      | ndbmtd   | thinkpad | running | 0         | next      |
| 2      | ndbmtd   | thinkpad | running | 0         | next      |
| 50     | mysqld   | thinkpad | running |           | next      |
| 51     | mysqld   | thinkpad | failed  |           | next      |
| 52     | ndbapi   | *        | added   |           |           |
+--------+----------+----------+---------+-----------+-----------+
6 rows in set (0.03 sec)

Then, issue the command again, specifying the failed node with the --nodeid option:

mcm> upgrade cluster --nodeid=51 -P next mycluster;
+-------------------------------+
| Command result                |
+-------------------------------+
| Cluster upgraded successfully |
+-------------------------------+
1 row in set (26.03 sec)

get [--include-defaults|-d] [filter_specification_list] cluster_name

filter_specification_list:
    filter_specification[,filter_specification][,...]

filter_specification:
    [attribute_name][:process_specification][+process_specification]]

process_specification:
    [process_name][:process_id]

process_name:
    {ndb_mgmd|ndbd|ndbmtd|mysqld|ndbapi}

This command is used in the MySQL Cluster Manager client to obtain configuration attribute values from a MySQL Cluster. (See Section 4.5, “MySQL Cluster Manager Configuration Commands”, for a definition of the term “attribute” as it applies in the MySQL Cluster Manager.) The output includes the following columns:

By default, get returns only those attributes that have been set explicitly, either by the MySQL Cluster Manager itself, or by the user. In other words, it shows only attributes that are mandatory (including read-only attributes), or that have been set by the user after the cluster was created. Hereafter in this discussion, we refer to these as “non-default attributes”.

Thus, prior to setting any configuration attributes, you can obtain a list of all mandatory and read-only attributes by running the simplest possible form of this command, as shown here:

mcm> get mycluster;
mcm> get mycluster\G
*************************** 1. row ***************************
    Name: DataDir
   Value: /home/jon/bin/mcm/mcm_data/clusters/mycluster/1/data
Process1: ndbmtd
 NodeId1: 1
Process2:
 NodeId2:
   Level:
 Comment:
*************************** 2. row ***************************
    Name: HostName
   Value: torsk
Process1: ndbmtd
 NodeId1: 1
Process2:
 NodeId2:
   Level:
 Comment: Read only
*************************** 3. row ***************************
    Name: NodeId
   Value: 1
Process1: ndbmtd
 NodeId1: 1
Process2:
 NodeId2:
   Level:
 Comment: Read only
*************************** 4. row ***************************
    Name: DataDir
   Value: /home/jon/bin/mcm/mcm_data/clusters/mycluster/2/data
Process1: ndbmtd
 NodeId1: 2
Process2:
 NodeId2:
   Level:
 Comment:
*************************** 5. row ***************************
    Name: HostName
   Value: torsk
Process1: ndbmtd
 NodeId1: 2
Process2:
 NodeId2:
   Level:
 Comment: Read only
*************************** 6. row ***************************
    Name: NodeId
   Value: 2
Process1: ndbmtd
 NodeId1: 2
Process2:
 NodeId2:
   Level:
 Comment: Read only
*************************** 7. row ***************************
    Name: DataDir
   Value: /home/jon/bin/mcm/mcm_data/clusters/mycluster/49/data
Process1: ndb_mgmd
 NodeId1: 49
Process2:
 NodeId2:
   Level:
 Comment:
*************************** 8. row ***************************
    Name: HostName
   Value: torsk
Process1: ndb_mgmd
 NodeId1: 49
Process2:
 NodeId2:
   Level:
 Comment: Read only
*************************** 9. row ***************************
    Name: NodeId
   Value: 49
Process1: ndb_mgmd
 NodeId1: 49
Process2:
 NodeId2:
   Level:
 Comment: Read only

...

*************************** 24. row ***************************
    Name: ndbcluster
   Value:
Process1: mysqld
 NodeId1: 51
Process2:
 NodeId2:
   Level:
 Comment: Read only
*************************** 25. row ***************************
    Name: NodeId
   Value: 51
Process1: mysqld
 NodeId1: 51
Process2:
 NodeId2:
   Level:
 Comment: Read only
*************************** 26. row ***************************
    Name: port
   Value: 3307
Process1: mysqld
 NodeId1: 51
Process2:
 NodeId2:
   Level:
 Comment:
*************************** 27. row ***************************
    Name: socket
   Value: /tmp/mysql.mycluster.51.sock
Process1: mysqld
 NodeId1: 51
Process2:
 NodeId2:
   Level:
 Comment:
*************************** 28. row ***************************
    Name: tmpdir
   Value: /home/jon/bin/mcm/mcm_data/clusters/mycluster/51/data/tmp
Process1: mysqld
 NodeId1: 51
Process2:
 NodeId2:
   Level:
 Comment:
*************************** 29. row ***************************
    Name: NodeId
   Value: 52
Process1: ndbapi
 NodeId1: 52
Process2:
 NodeId2:
   Level:
 Comment: Read only
29 rows in set (0.05 sec)

On Windows, no substitutions for backslashes or other characters used in values of paths reported by the get command is performed. However, it is possible to see forward slashes used in such paths if the values were set using the set command. See Setting Attributes Containing Paths on Windows, for more information.

Although a socket attribute is shown for mysqld nodes in the get output from the previous example and is not marked Read only, MySQL Cluster Manager does not support socket files on Windows. For this reason; you should not attempt to set socket attributes for Windows mysqld processes using MySQL Cluster Manager.

To include default values for attributes that have not (or not yet) been set explicitly, you can invoke this command with the --include-defaults option (short form: -d), as shown here (in part):

mcm> get --include-defaults mycluster\G

*************************** 1. row ***************************
    Name: __ndbmt_classic
   Value: NULL
Process1: ndbmtd
 NodeId1: 1
Process2:
 NodeId2:
   Level: Default
 Comment:
*************************** 2. row ***************************
    Name: __ndbmt_lqh_threads
   Value: NULL
Process1: ndbmtd
 NodeId1: 1
Process2:
 NodeId2:
   Level: Default
 Comment:
*************************** 3. row ***************************
    Name: __ndbmt_lqh_workers
   Value: NULL
Process1: ndbmtd
 NodeId1: 1
Process2:
 NodeId2:
   Level: Default
 Comment:
*************************** 4. row ***************************
    Name: Arbitration
   Value: Default
Process1: ndbmtd
 NodeId1: 1
Process2:
 NodeId2:
   Level: Default
 Comment:
*************************** 5. row ***************************
    Name: ArbitrationTimeout
   Value: 7500
Process1: ndbmtd
 NodeId1: 1
Process2:
 NodeId2:
   Level: Default
 Comment:

...

*************************** 1094. row ***************************
    Name: DefaultOperationRedoProblemAction
   Value: queue
Process1: ndbapi
 NodeId1: 52
Process2:
 NodeId2:
   Level: Default
 Comment:
*************************** 1095. row ***************************
    Name: ExecuteOnComputer
   Value: NULL
Process1: ndbapi
 NodeId1: 52
Process2:
 NodeId2:
   Level: Default
 Comment:
*************************** 1096. row ***************************
    Name: HeartbeatThreadPriority
   Value: NULL
Process1: ndbapi
 NodeId1: 52
Process2:
 NodeId2:
   Level: Default
 Comment:
*************************** 1097. row ***************************
    Name: HostName
   Value:
Process1: ndbapi
 NodeId1: 52
Process2:
 NodeId2:
   Level: Default
 Comment:
*************************** 1098. row ***************************
    Name: MaxScanBatchSize
   Value: 262144
Process1: ndbapi
 NodeId1: 52
Process2:
 NodeId2:
   Level: Default
 Comment:
*************************** 1099. row ***************************
    Name: NodeId
   Value: 52
Process1: ndbapi
 NodeId1: 52
Process2:
 NodeId2:
   Level:
 Comment: Read only
*************************** 1100. row ***************************
    Name: TotalSendBufferMemory
   Value: 0
Process1: ndbapi
 NodeId1: 52
Process2:
 NodeId2:
   Level: Default
 Comment:
*************************** 1101. row ***************************
    Name: wan
   Value: false
Process1: ndbapi
 NodeId1: 52
Process2:
 NodeId2:
   Level: Default
 Comment:
1101 rows in set (0.09 sec)

As you can see, the output from this get command is quite long (and the number of rows generated increases with the number of nodes in the cluster.) However, it is possible to filter the output so that you can view only the attribute or attributes in which you are interested. This can be done by using a comma-separated list of one or more filter specifications. A filter specification is defined as shown here (condensed from that given at the beginning of this section, but effectively the same):

[attribute_name][:[process_name][:process_id]]

Filtering can be applied per attribute, per process type, and per process instance. We now provide some examples illustrating the use of such filters.

To obtain the value of a given attribute for all processes to which it applies in the cluster, you need only use the name of the attribute as a filter. For example, to obtain the HostName of all processes in the cluster named mycluster, you can execute the command shown here:

mcm> get HostName mycluster;
+----------+----------+----------+---------+----------+---------+-------+-----------+
| Name     | Value    | Process1 | NodeId1 | Process2 | NodeId2 | Level | Comment   |
+----------+----------+----------+---------+----------+---------+-------+-----------+
| HostName | flundra  | ndbd     | 1       |          |         |       | Read only |
| HostName | tonfisk  | ndbd     | 2       |          |         |       | Read only |
| HostName | grindval | ndb_mgmd | 49      |          |         |       | Read only |
| HostName | haj      | mysqld   | 50      |          |         |       | Read only |
| HostName | torsk    | mysqld   | 51      |          |         |       | Read only |
+----------+----------+----------+---------+----------+---------+-------+-----------+
5 rows in set (0.04 sec)

The wildcard * (asterisk character) can be used to match a single or multiple attribute names; for example:

mcm> get Host* mycluster;
+----------+----------+----------+---------+----------+---------+-------+-----------+
| Name     | Value    | Process1 | NodeId1 | Process2 | NodeId2 | Level | Comment   |
+----------+----------+----------+---------+----------+---------+-------+-----------+
| HostName | flundra  | ndbd     | 1       |          |         |       | Read only |
| HostName | tonfisk  | ndbd     | 2       |          |         |       | Read only |
| HostName | grindval | ndb_mgmd | 49      |          |         |       | Read only |
| HostName | haj      | mysqld   | 50      |          |         |       | Read only |
| HostName | torsk    | mysqld   | 51      |          |         |       | Read only |
+----------+----------+----------+---------+----------+---------+-------+-----------+
5 rows in set (0.04 sec)

mcm> get H* yourcluster;
+------------------------+---------+----------+---------+----------+---------+---------+-----------+
| Name                   | Value   | Process1 | NodeId1 | Process2 | NodeId2 | Level   | Comment   |
+------------------------+---------+----------+---------+----------+---------+---------+-----------+
| HostName               | tonfisk | ndb_mgmd | 49      |          |         |         | Read only |
| HostName               | flundra | ndb_mgmd | 53      |          |         |         | Read only |
| HeartbeatIntervalDbApi | 1500    | ndbmtd   | 1       |          |         | Process |           |
| HeartbeatIntervalDbDb  | 1500    | ndbmtd   | 1       |          |         | Process |           |
| HostName               | tonfisk | ndbmtd   | 1       |          |         |         | Read only |
| HeartbeatIntervalDbApi | 1500    | ndbmtd   | 2       |          |         | Process |           |
| HeartbeatIntervalDbDb  | 1500    | ndbmtd   | 2       |          |         | Process |           |
| HostName               | flundra | ndbmtd   | 2       |          |         |         | Read only |
| HostName               | tonfisk | mysqld   | 50      |          |         |         | Read only |
| HostName               | flundra | mysqld   | 51      |          |         |         | Read only |
+------------------------+---------+----------+---------+----------+---------+---------+-----------+
10 rows in set (0.09 sec)

To obtain the value of a given attribute for all processes of a given type, you can specify a filter of the form attribute_name:process_name. The following command retrieves the HostName of all ndbd processes (only) in the cluster mycluster:

mcm> get HostName:ndbd mycluster;
+----------+---------+----------+------+----------+------+-------+----------+
| Name     | Value   | Process1 | Id1  | Process2 | Id2  | Level | Comment  |
+----------+---------+----------+------+----------+------+-------+----------+
| HostName | flundra | ndbd     | 1    |          |      |       | Readonly |
| HostName | tonfisk | ndbd     | 2    |          |      |       | Readonly |
+----------+---------+----------+------+----------+------+-------+----------+
2 rows in set (0.12 sec)

To retrieve the value of a given attribute for a particular instance of a process, you can use a filter that takes the form attribute_name:process_name:process_id. For example, you can use the following command to obtain the hostname for the process having 2 as its process ID:

mcm> get HostName:ndbd:2 mycluster;
+----------+---------+----------+------+----------+------+-------+----------+
| Name     | Value   | Process1 | Id1  | Process2 | Id2  | Level | Comment  |
+----------+---------+----------+------+----------+------+-------+----------+
| HostName | tonfisk | ndbd     | 2    |          |      |       | Readonly |
+----------+---------+----------+------+----------+------+-------+----------+
1 row in set (1.67 sec)

The command works the same if the process type is omitted:

mcm> get HostName::2 mycluster;
+----------+---------+----------+------+----------+------+-------+----------+
| Name     | Value   | Process1 | Id1  | Process2 | Id2  | Level | Comment  |
+----------+---------+----------+------+----------+------+-------+----------+
| HostName | tonfisk | ndbd     | 2    |          |      |       | Readonly |
+----------+---------+----------+------+----------+------+-------+----------+
1 row in set (1.67 sec)

You can obtain information about multiple attributes within a single get command by specifying a list of filters, separated by commas. Each filter in the list must be a complete, valid filter. The command shown here retrieves the HostName and DataDir for all processes in mycluster:

mcm> get HostName,DataDir mycluster;
+----------+--------------+----------+---------+----------+---------+-------+-----------+
| Name     | Value        | Process1 | NodeId1 | Process2 | NodeId2 | Level | Comment   |
+----------+--------------+----------+---------+----------+---------+-------+-----------+
| DataDir  | /opt/c1data  | ndbd     | 1       |          |         |       |           |
| HostName | flundra      | ndbd     | 1       |          |         |       | Read only |
| DataDir  | /opt/c2data  | ndbd     | 2       |          |         |       |           |
| HostName | tonfisk      | ndbd     | 2       |          |         |       | Read only |
| DataDir  | /opt/c49data | ndb_mgmd | 49      |          |         |       |           |
| HostName | grindval     | ndb_mgmd | 49      |          |         |       | Read only |
| datadir  | /opt/c50data | mysqld   | 50      |          |         |       |           |
| HostName | haj          | mysqld   | 50      |          |         |       | Read only |
| datadir  | /opt/c51data | mysqld   | 51      |          |         |       |           |
| HostName | torsk        | mysqld   | 51      |          |         |       | Read only |
+----------+--------------+----------+---------+----------+---------+-------+-----------+
10 rows in set (0.05 sec)

To retrieve the values of HostName and DataDir for only the data nodes in mycluster, you can use the get command shown here:

mcm> get HostName:ndbd,DataDir:ndbd mycluster;
+----------+-------------+----------+-----+----------+-----+-------+-----------+
| Name     | Value       | Process1 | Id1 | Process2 | Id2 | Level | Comment   |
+----------+-------------+----------+-----+----------+-----+-------+-----------+
| DataDir  | /opt/c2data | ndbd     | 1   |          |     |       |           |
| HostName | tonfisk     | ndbd     | 1   |          |     |       | Read only |
| DataDir  | /opt/c3data | ndbd     | 2   |          |     |       |           |
| HostName | flundra     | ndbd     | 2   |          |     |       | Read only |
+----------+-------------+----------+-----+----------+-----+-------+-----------+
4 rows in set (1.36 sec)

In the example just shown, each filter includes a process type specifier. If you omit this specifier from one of the filters, you obtain a result that you might not expect:

mcm> get HostName,DataDir:ndbd mycluster;
+----------+-------------+----------+-----+----------+-----+-------+-----------+
| Name     | Value       | Process1 | Id1 | Process2 | Id2 | Level | Comment   |
+----------+-------------+----------+-----+----------+-----+-------+-----------+
| HostName | grindval    | ndb_mgmd | 49  |          |     |       | Read only |
| DataDir  | /opt/c2data | ndbd     | 1   |          |     |       |           |
| HostName | tonfisk     | ndbd     | 1   |          |     |       | Read only |
| DataDir  | /opt/c3data | ndbd     | 2   |          |     |       |           |
| HostName | flundra     | ndbd     | 2   |          |     |       | Read only |
| HostName | haj         | mysqld   | 50  |          |     |       | Read only |
| HostName | torsk       | mysqld   | 51  |          |     |       | Read only |
+----------+-------------+----------+-----+----------+-----+-------+-----------+
6 rows in set (0.58 sec)

The filter list HostName,DataDir:ndbd is perfectly valid. However, it actually consists of the filters HostName and DataDir:ndbd—in other words, it means “the HostName for all processes, and the DataDir for ndbd processes”.

Suppose you wish to obtain the values for HostName for just the ndb_mgmd and mysqld processes in mycluster. You might be tempted to try using something like HostName:ndb_mgmd,mysqld for the filter list, but this does not work, as you can see here:

mcm> get HostName:ndb_mgmd,mysqld mycluster;
ERROR 6003 (00MGR): No such config variable mysqld for process

This is due to the fact that each filter in the filter list must be a valid filter, and must include an attribute name. (In the filter list just shown, MySQL Cluster Manager tries to interpret the first string following the comma as an attribute name.) The correct filter list to use in a get command for retrieving the HostName for the ndb_mgmd and mysqld processes in mycluster is shown in this example:

mcm> get HostName:ndb_mgmd,HostName:mysqld mycluster;
+----------+----------+----------+------+----------+------+-------+-----------+
| Name     | Value    | Process1 | Id1  | Process2 | Id2  | Level | Comment   |
+----------+----------+----------+------+----------+------+-------+-----------+
| HostName | grindval | ndb_mgmd | 49   |          |      |       | Read only |
| HostName | haj      | mysqld   | 50   |          |      |       | Read only |
| HostName | torsk    | mysqld   | 51   |          |      |       | Read only |
+----------+----------+----------+------+----------+------+-------+-----------+
2 rows in set (0.21 sec)

It is also possible to obtain a list of attributes and their values for a given process type or instance of a process. For a given process type, use a filter having the form :process_name. For example, to retrieve all non-default attributes applying to ndbd processes in a cluster named mycluster, you can use the filter :ndbd, as shown here:

mcm> get :ndbd mycluster;
+--------------+-------------+----------+-----+----------+-----+-------+-----------+
| Name         | Value       | Process1 | Id1 | Process2 | Id2 | Level | Comment   |
+--------------+-------------+----------+-----+----------+-----+-------+-----------+
| DataDir      | /opt/c2data | ndbd     | 1   |          |     |       |           |
| HostName     | tonfisk     | ndbd     | 1   |          |     |       | Read only |
| NodeId       | 1           | ndbd     | 1   |          |     |       | Read only |
| DataDir      | /opt/c3data | ndbd     | 2   |          |     |       |           |
| HostName     | flundra     | ndbd     | 2   |          |     |       | Read only |
| NodeId       | 2           | ndbd     | 2   |          |     |       | Read only |
+--------------+-------------+----------+-----+----------+-----+-------+-----------+
6 rows in set (0.77 sec)

(The example just shown assumes that no attributes are set to non-default values.)

To get a list of all non-default attributes for a single instance of a process, use a filter having the form :process_name:process_id, as shown in this example, which retrieves all non-default attributes for the ndbd process having 2 as its process ID:

mcm> get :ndbd:2 mycluster;
+--------------+-------------+----------+-----+----------+-----+-------+-----------+
| Name         | Value       | Process1 | Id1 | Process2 | Id2 | Level | Comment   |
+--------------+-------------+----------+-----+----------+-----+-------+-----------+
| DataDir      | /opt/c2data | ndbd     | 2   |          |     |       |           |
| HostName     | flundra     | ndbd     | 2   |          |     |       | Read only |
| NodeId       | 2           | ndbd     | 2   |          |     |       | Read only |
+--------------+-------------+----------+-----+----------+-----+-------+-----------+
4 rows in set (0.32 sec)

If you try to obtain values for an attribute which you know is supported by your MySQL Cluster version, but the result is empty, this almost certainly means that it is a default attribute which either has not been changed since the cluster was created or has been reset. In order to view default attributes using get, you must execute the command using the --include-defaults option (short form: -d).

Suppose you want to see how much DataMemory is configured for the ndbd processes in the cluster named mycluster, and you execute what appears to be the correct get command, but an empty result is returned, as shown here:

mcm> get DataMemory:ndbd mycluster;
Empty set (1.19 sec)

This means that the DataMemory attribute has its default value for all data nodes in the cluster. If you do not recall what this value is, you can determine it easily by repeating the same command with the addition of the --include-defaults (-d) option:

mcm> get --include-defaults DataMemory:ndbd mycluster;
+------------+----------+----------+-----+----------+-----+---------+---------+
| Name       | Value    | Process1 | Id1 | Process2 | Id2 | Level   | Comment |
+------------+----------+----------+-----+----------+-----+---------+---------+
| DataMemory | 83886080 | ndbd     | 1   |          |     | Default |         |
| DataMemory | 83886080 | ndbd     | 2   |          |     | Default |         |
+------------+----------+----------+-----+----------+-----+---------+---------+
2 rows in set (0.62 sec)

Now suppose that you increase the DataMemory to 500 megabytes per data node, then repeat the get command to verify the new value:

mcm> set DataMemory:ndbd=500M mycluster;
+-----------------------------------+
| Command result                    |
+-----------------------------------+
| Cluster reconfigured successfully |
+-----------------------------------+
1 row in set (7.77 sec)

mcm> get --include-defaults DataMemory:ndbd mycluster;
+------------+-------+----------+-----+----------+-----+---------+---------+
| Name       | Value | Process1 | Id1 | Process2 | Id2 | Level   | Comment |
+------------+-------+----------+-----+----------+-----+---------+---------+
| DataMemory | 500M  | ndbd     | 1   |          |     | Process |         |
| DataMemory | 500M  | ndbd     | 2   |          |     | Process |         |
+------------+-------+----------+-----+----------+-----+---------+---------+
2 rows in set (1.46 sec)

You can see that, not only has the Value column in the get command output been updated to the new value, but the Level column has also been updated from Default to Process. This means that you no longer need the --include-defaults option to view this attribute, as shown here:

mcm> get DataMemory:ndbd mycluster;
+------------+-------+----------+-----+----------+-----+---------+---------+
| Name       | Value | Process1 | Id1 | Process2 | Id2 | Level   | Comment |
+------------+-------+----------+-----+----------+-----+---------+---------+
| DataMemory | 500M  | ndbd     | 1   |          |     | Process |         |
| DataMemory | 500M  | ndbd     | 2   |          |     | Process |         |
+------------+-------+----------+-----+----------+-----+---------+---------+
2 rows in set (0.63 sec)

However, if you reset DataMemory (also on the process level), this is no longer the case. Then, DataMemory once again assumes its default value, after which you must use the --include-defaults option to retrieve it, as shown in this example:

mcm> reset DataMemory:ndbd mycluster;
+-----------------------------------+
| Command result                    |
+-----------------------------------+
| Cluster reconfigured successfully |
+-----------------------------------+
1 row in set (7.65 sec)

mcm> get DataMemory:ndbd mycluster;
Empty set (1.76 sec)

mcm> get --include-defaults DataMemory:ndbd mycluster;
+------------+----------+----------+-----+----------+-----+---------+---------+
| Name       | Value    | Process1 | Id1 | Process2 | Id2 | Level   | Comment |
+------------+----------+----------+-----+----------+-----+---------+---------+
| DataMemory | 83886080 | ndbd     | 1   |          |     | Default |         |
| DataMemory | 83886080 | ndbd     | 2   |          |     | Default |         |
+------------+----------+----------+-----+----------+-----+---------+---------+
2 rows in set (1.01 sec)

For more information about these commands, see Section 4.5.3, “The set Command”, and Section 4.5.2, “The reset Command”.

The get command also tags multi-entry replication attributes as so in the Comment column; for example:

mcm> get replicate_ignore_table:mysqld mycluster;
+------------------------+--------------+----------+---------+----------+---------+---------+-------------+
| Name                   | Value        | Process1 | NodeId1 | Process2 |NodeId2  | Level   | Comment     |
+------------------------+--------------+----------+---------+----------+---------+---------+-------------+
| replicate_ignore_table | mydb.t1      | mysqld   | 50      |          |         |         | Multi-entry |
| replicate_ignore_table | mydb.t50     | mysqld   | 50      |          |         |         | Multi-entry |
| replicate_ignore_table | mydb.mytable | mysqld   | 50      |          |         | Process | Multi-entry |
| replicate_ignore_table | mydb.t51     | mysqld   | 51      |          |         |         | Multi-entry |
| replicate_ignore_table | mydb.mytable | mysqld   | 51      |          |         | Process | Multi-entry |
+------------------------+--------------+----------+---------+----------+---------+---------+-------------+
5 rows in set (0.05 sec)

On how to reset multi-entry attributes, see Section 4.5.2, “The reset Command”.

The get command does not normally display configuration attributes applying to TCP, SHM, or SCI connections. However, such attributes can be set in the MySQL Cluster Manager client (using the set command); and once they have been set, they are displayed by applicable get commands. See Setting TCP Connection Attributes, which provides an example of this.

reset filter_specification_list cluster_name

filter_specification_list:
    filter_specification[,filter_specification][,...]

filter_specification:
    attribute_name[:process_specification][+process_specification]]

process_specification:
    [process_name][:process_id]

process_name:
    {ndb_mgmd|ndbd|ndbmtd|mysqld|ndbapi}

This command resets an attribute to its default value. Attributes can be set on either the process level or instance level. To reset an attribute on the process level, use a filter specification having the form attribute_name:process_name, where attribute_name is the name of the attribute to be reset, and process_name is the name of a MySQL Cluster process. To reset a configuration attribute on the instance level, use a filter specification of the form attribute_name:process_name:process_id, where process_id is the process ID.

You cannot issue a reset command that resets all values for a given configuration attribute regardless of process type; each reset command must specify a process type or instance of a process. Otherwise, the command fails, as shown here:

mcm> reset DataMemory mycluster;
ERROR 3 (00MGR): Illegal syntax

You also cannot revert all configuration attributes for a given process type or instance of a process using a single filter specification; you must always include the name of the attribute to be reset. Otherwise, the reset command fails, as shown here:

mcm> reset :ndbd mycluster;
ERROR 3 (00MGR): Illegal syntax

mcm> reset :ndbd:3 mycluster;
ERROR 3 (00MGR): Illegal syntax

Suppose that the data memory for all ndbd processes in the cluster named mycluster has been set to 500 MB, as shown in the output of this get command:

mcm> get DataMemory mycluster;
+------------+-------+----------+-----+----------+-----+---------+---------+
| Name       | Value | Process1 | Id1 | Process2 | Id2 | Level   | Comment |
+------------+-------+----------+-----+----------+-----+---------+---------+
| DataMemory | 500M  | ndbd     | 2   |          |     | Process |         |
| DataMemory | 500M  | ndbd     | 3   |          |     | Process |         |
+------------+-------+----------+-----+----------+-----+---------+---------+
2 rows in set (1.91 sec)

We can see from the entries in the Level column that the DataMemory setting for both ndbd processes applies on the process level. A process-level setting cannot be reset on the instance level, as shown here:

mcm> reset DataMemory:ndbd:2 mycluster;
ERROR 6010 (00MGR): No matching user defined setting was
found for config attribute DataMemory
mcm> reset DataMemory:ndbd:3 mycluster;
ERROR 6010 (00MGR): No matching user defined setting was
found for config attribute DataMemory

The following reset command also does not work, although you might think that it would do so, since it attempts to reset the attribute's value for both ndbd processes:

mcm> reset DataMemory:ndbd:2,DataMemory:ndbd:3 mycluster;
ERROR 6010 (00MGR): No matching user defined setting was
found for config attribute DataMemory

The previous command fails because MySQL Cluster Manager regards this as an attempt to apply two instance-level configuration changes. Because the DataMemory setting is a process-level setting, you must instead reset DataMemory to its default value on the process level; you can do this by using the filter specification DataMemory:ndbd in the reset command, as shown here:

mcm> reset DataMemory:ndbd mycluster;
+-----------------------------------+
| Command result                    |
+-----------------------------------+
| Cluster reconfigured successfully |
+-----------------------------------+
1 row in set (6.16 sec)

If you execute the same get command as shown previously, the result is now empty:

mcm> get DataMemory mycluster;
Empty set (0.74 sec)

This is because the get command by default does not report default values. To retrieve the DataMemory values after resetting them, you must invoke get using the --include-defaults (short form: -d) option:

mcm> get --include-defaults DataMemory mycluster;
+------------+----------+----------+-----+----------+-----+---------+---------+
| Name       | Value    | Process1 | Id1 | Process2 | Id2 | Level   | Comment |
+------------+----------+----------+-----+----------+-----+---------+---------+
| DataMemory | 83886080 | ndbd     | 2   |          |     | Default |         |
| DataMemory | 83886080 | ndbd     | 3   |          |     | Default |         |
+------------+----------+----------+-----+----------+-----+---------+---------+
2 rows in set (1.21 sec)

The DataMemory values are now included in the output, and are marked with the word Default in the Comments column.

Now suppose that the mysqld configuration attribute wait_timeout for the mysqld process having the ID 4 in the cluster named mycluster has previously been set to the value 200 as shown here, and that no other changes have been to this attribute:

mcm> set wait_timeout:mysqld:4=200 mycluster;
+-----------------------------------+
| Command result                    |
+-----------------------------------+
| Cluster reconfigured successfully |
+-----------------------------------+
1 row in set (7.78 sec)

mcm> get -d wait_timeout:mysqld:4 mycluster;
+--------------+-------+----------+-----+----------+-----+-------+---------+
| Name         | Value | Process1 | Id1 | Process2 | Id2 | Level | Comment |
+--------------+-------+----------+-----+----------+-----+-------+---------+
| wait_timeout | 200   | mysqld   | 4   |          |     |       |         |
+--------------+-------+----------+-----+----------+-----+-------+---------+
1 row in set (0.98 sec)

Because the Level column is empty, we know that this setting applies on the instance level. If you try to reset it on the process level, the attempt fails, as shown here:

mcm> reset wait_timeout:mysqld mycluster2;
ERROR 6010 (00MGR): No matching user defined setting was
found for config attribute wait_timeout

If you wish to reset this attribute to its default value, you must use the reset command with the instance-level filter specification wait_timeout:mysqld:4, as shown here:

mcm> reset wait_timeout:mysqld:4 mycluster;
+-----------------------------------+
| Command result                    |
+-----------------------------------+
| Cluster reconfigured successfully |
+-----------------------------------+
1 row in set (7.61 sec)

Once you have reset wait_timeout, it no longer appears in the output of the earlier get command:

mcm> get wait_timeout:mysqld mycluster;
Empty set (1.42 sec)

This is because the default behavior of the get command is to display only those values that have been set either by the MySQL Cluster Manager or by the user. Since wait_timeout has been allowed to revert to its default value, you must use the --include-defaults (short form: -d) option to retrieve it, as shown here:

mcm> get -d wait_timeout:mysqld mycluster;
+--------------+-------+----------+-----+----------+-----+---------+---------+
| Name         | Value | Process1 | Id1 | Process2 | Id2 | Level   | Comment |
+--------------+-------+----------+-----+----------+-----+---------+---------+
| wait_timeout | 28800 | mysqld   | 4   |          |     | Default |         |
+--------------+-------+----------+-----+----------+-----+---------+---------+
1 row in set (1.66 sec)

Now consider a situation in which process-level and instance-level settings have been made to a configuration attribute; in this example, we use IndexMemory. First, verify that IndexMemory is set to its default value for all data node processes (in this case, there are two of them):

mcm> get -d IndexMemory mycluster;
+-------------+----------+----------+-----+----------+-----+---------+---------+
| Name        | Value    | Process1 | Id1 | Process2 | Id2 | Level   | Comment |
+-------------+----------+----------+-----+----------+-----+---------+---------+
| IndexMemory | 18874368 | ndbd     | 2   |          |     | Default |         |
| IndexMemory | 18874368 | ndbd     | 3   |          |     | Default |         |
+-------------+----------+----------+-----+----------+-----+---------+---------+
2 rows in set (1.24 sec)

Now apply both a process-level change and an instance-level change to this attribute. You can do this with a single set command, as shown here:

mcm> set IndexMemory:ndbd=500M,IndexMemory:ndbd:3=750M mycluster;
+-----------------------------------+
| Command result                    |
+-----------------------------------+
| Cluster reconfigured successfully |
+-----------------------------------+
1 row in set (7.29 sec)

Because the process-level change was specified first, it is overridden for the ndbd process by the instance-level change specified second. The output from the following get command confirms that this is the case:

mcm> get IndexMemory mycluster;
+-------------+-------+----------+-----+----------+-----+---------+---------+
| Name        | Value | Process1 | Id1 | Process2 | Id2 | Level   | Comment |
+-------------+-------+----------+-----+----------+-----+---------+---------+
| IndexMemory | 500M  | ndbd     | 2   |          |     | Process |         |
| IndexMemory | 750M  | ndbd     | 3   |          |     |         |         |
+-------------+-------+----------+-----+----------+-----+---------+---------+
2 rows in set (0.85 sec)

If the instance-level IndexMemory setting for the ndbd process with process ID 3 is reset, the process-level setting still applies, as shown here:

mcm> reset IndexMemory:ndbd:3 mycluster;
+-----------------------------------+
| Command result                    |
+-----------------------------------+
| Cluster reconfigured successfully |
+-----------------------------------+
1 row in set (6.41 sec)

mcm> get IndexMemory mycluster;
+-------------+-------+----------+-----+----------+-----+---------+---------+
| Name        | Value | Process1 | Id1 | Process2 | Id2 | Level   | Comment |
+-------------+-------+----------+-----+----------+-----+---------+---------+
| IndexMemory | 500M  | ndbd     | 2   |          |     | Process |         |
| IndexMemory | 500M  | ndbd     | 3   |          |     | Process |         |
+-------------+-------+----------+-----+----------+-----+---------+---------+
2 rows in set (1.09 sec)

Now, re-apply the instance-level IndexMemory setting, and verify using get that it has taken effect:

mcm> set IndexMemory:ndbd:3=750M mycluster;
+-----------------------------------+
| Command result                    |
+-----------------------------------+
| Cluster reconfigured successfully |
+-----------------------------------+
1 row in set (6.79 sec)

mcm> get IndexMemory mycluster;
+-------------+-------+----------+-----+----------+-----+---------+---------+
| Name        | Value | Process1 | Id1 | Process2 | Id2 | Level   | Comment |
+-------------+-------+----------+-----+----------+-----+---------+---------+
| IndexMemory | 500M  | ndbd     | 2   |          |     | Process |         |
| IndexMemory | 750M  | ndbd     | 3   |          |     |         |         |
+-------------+-------+----------+-----+----------+-----+---------+---------+
2 rows in set (1.76 sec)

If you reset the process-level setting, the instance-level setting remains, and only the ndbd process having process ID 2 has its IndexMemory reset to the default value; the instance-level setting remains in effect, as you can see from the following sequence of commands:

mcm> reset IndexMemory:ndbd mycluster;
+-----------------------------------+
| Command result                    |
+-----------------------------------+
| Cluster reconfigured successfully |
+-----------------------------------+
1 row in set (7.36 sec)

mcm> get -d IndexMemory mycluster;
+-------------+----------+----------+-----+----------+-----+---------+---------+
| Name        | Value    | Process1 | Id1 | Process2 | Id2 | Level   | Comment |
+-------------+----------+----------+-----+----------+-----+---------+---------+
| IndexMemory | 18874368 | ndbd     | 2   |          |     | Default |         |
| IndexMemory | 750M     | ndbd     | 3   |          |     |         |         |
+-------------+----------+----------+-----+----------+-----+---------+---------+
2 rows in set (0.10 sec)

The get and reset commands fully support multi-entry replication attributes; for example, if the replicate_ignore_table attribute has multiple entries:

mcm> get replicate_ignore_table:mysqld mycluster;
+------------------------+--------------+----------+---------+----------+---------+---------+-------------+
| Name                   | Value        | Process1 | NodeId1 | Process2 |NodeId2  | Level   | Comment     |
+------------------------+--------------+----------+---------+----------+---------+---------+-------------+
| replicate_ignore_table | mydb.t1      | mysqld   | 50      |          |         |         | Multi-entry |
| replicate_ignore_table | mydb.t50     | mysqld   | 50      |          |         |         | Multi-entry |
| replicate_ignore_table | mydb.mytable | mysqld   | 50      |          |         | Process | Multi-entry |
| replicate_ignore_table | mydb.t51     | mysqld   | 51      |          |         |         | Multi-entry |
| replicate_ignore_table | mydb.mytable | mysqld   | 51      |          |         | Process | Multi-entry |
+------------------------+--------------+----------+---------+----------+---------+---------+-------------+
5 rows in set (0.05 sec)

Without specifying a node ID, all the attribute's entries associated with the specified process type are reset with the following command:

mcm> reset replicate_ignore_table:mysqld mycluster;  # removes all process level entries
+-----------------------------------+
| Command result                    |
+-----------------------------------+
| Cluster reconfigured successfully |
+-----------------------------------+
1 row in set (0.47 sec)

mcm> get replicate_ignore_table:mysqld mycluster;
+------------------------+----------+----------+---------+----------+---------+-------+-------------+
| Name                   | Value    | Process1 | NodeId1 | Process2 | NodeId2 | Level | Comment     |
+------------------------+----------+----------+---------+----------+---------+-------+-------------+
| replicate_ignore_table | mydb.t1  | mysqld   | 50      |          |         |       | Multi-entry |
| replicate_ignore_table | mydb.t50 | mysqld   | 50      |          |         |       | Multi-entry |
| replicate_ignore_table | mydb.t51 | mysqld   | 51      |          |         |       | Multi-entry |
+------------------------+----------+----------+---------+----------+---------+-------+-------------+
3 rows in set (0.08 sec)

With a node ID specified, only the instance entries associated with the node ID are reset by the following command:

mcm> reset replicate_ignore_table:mysqld:51 mycluster;  # removes all instance level entries for nodeid 51
+-----------------------------------+
| Command result                    |
+-----------------------------------+
| Cluster reconfigured successfully |
+-----------------------------------+
1 row in set (0.57 sec)

mcm> get replicate_ignore_table:mysqld mycluster;
+------------------------+----------+----------+---------+----------+---------+-------+-------------+
| Name                   | Value    | Process1 | NodeId1 | Process2 | NodeId2 | Level | Comment     |
+------------------------+----------+----------+---------+----------+---------+-------+-------------+
| replicate_ignore_table | mydb.t1  | mysqld   | 50      |          |         |       | Multi-entry |
| replicate_ignore_table | mydb.t50 | mysqld   | 50      |          |         |       | Multi-entry |
+------------------------+----------+----------+---------+----------+---------+-------+-------------+
2 rows in set (0.09 sec)

Resetting TCP Connection Attributes.  Certain configuration attributes, such as those relating to TCP connections, apply to connections between processes rather than to individual processes or individual process types. As shown elsewhere (see Setting TCP Connection Attributes), when you set such an attribute on the process level using MySQL Cluster Manager, this means that the attribute applies to all connections between the two types of processes specified when issuing the set command. It is also possible to set such an attribute on the instance level, in which case it applies only to a single connection between two process instances.

Similarly, it is possible to reset such an attribute on either the process or instance level, depending on the level or levels at which it was set. In either case, an extended form of the process specifier is required, just as it is when setting an attribute that applies to a connection between processes. Assume that the SendBufferMemory attribute has previously been set for all connections between the two ndbd processes and the two mysqld processes that are found in a MySQL Cluster named mycluster2, as shown in the output of this get command:

mcm> get SendBufferMemory mycluster2;
+------------------+-------+----------+-----+----------+-----+---------+---------+
| Name             | Value | Process1 | Id1 | Process2 | Id2 | Level   | Comment |
+------------------+-------+----------+-----+----------+-----+---------+---------+
| SendBufferMemory | 4M    | ndbd     | 2   | mysqld   | 4   | Process |         |
| SendBufferMemory | 4M    | ndbd     | 2   | mysqld   | 5   | Process |         |
| SendBufferMemory | 4M    | ndbd     | 3   | mysqld   | 4   | Process |         |
| SendBufferMemory | 8M    | ndbd     | 3   | mysqld   | 5   |         |         |
+------------------+-------+----------+-----+----------+-----+---------+---------+
4 rows in set (0.59 sec)

Suppose that you wish to reset SendBufferMemory only for the connection between the ndbd process having process ID 3 and the mysqld process having process ID 5. The SendBufferMemory setting that applies to this connection is specified on the instance level, as you can see because the Level column value corresponding to this connection is empty; this means that it is possible to reset this value on the instance level. You can do this using the reset command shown here:

mcm> reset SendBufferMemory:ndbd:3+mysqld:5 mycluster2;
+-----------------------------------+
| Command result                    |
+-----------------------------------+
| Cluster reconfigured successfully |
+-----------------------------------+
1 row in set (7.03 sec)

You can verify that the attribute was reset using the get command. However, as noted previously, once the instance-level setting has been removed, the process-level setting for this attribute again takes effect, so that the same setting applies to all connections between ndbd and mysqld processes, as shown here:

mcm> get SendBufferMemory mycluster2;
+------------------+-------+----------+-----+----------+-----+---------+---------+
| Name             | Value | Process1 | Id1 | Process2 | Id2 | Level   | Comment |
+------------------+-------+----------+-----+----------+-----+---------+---------+
| SendBufferMemory | 4M    | ndbd     | 2   | mysqld   | 4   | Process |         |
| SendBufferMemory | 4M    | ndbd     | 2   | mysqld   | 5   | Process |         |
| SendBufferMemory | 4M    | ndbd     | 3   | mysqld   | 4   | Process |         |
| SendBufferMemory | 4M    | ndbd     | 3   | mysqld   | 5   | Process |         |
+------------------+-------+----------+-----+----------+-----+---------+---------+
4 rows in set (0.87 sec)

To reset this attribute on the process level, you can use the following reset command:

mcm> reset SendBufferMemory:ndbd+mysqld mycluster2;
+-----------------------------------+
| Command result                    |
+-----------------------------------+
| Cluster reconfigured successfully |
+-----------------------------------+
1 row in set (8.01 sec)

You can verify that the attribute has been reset for all connection between ndbd processes and mysqld processes, by using the get command, as shown here:

mcm> get -d SendBufferMemory mycluster2;
Empty set (1.39 sec)

As noted elsewhere in this manual (see Section 4.5.1, “The get Command”), the empty result set is to be expected in this case, even when get is invoked using the --include-defaults (or -d) option, because the MySQL Cluster Manager client does not display attributes that appear in the [tcp], [shm], or [sci] sections of the config.ini configuration file if they have not been explicitly set by the user.

set attribute_assignment_list cluster_name

attribute_assignment_list:
    attribute_assignment[,attribute_assignment][,...]

attribute_assignment:
    attribute_name:process_specification[+process_specification][=value]

process_specification:
    [process_name][:process_id]

process_name:
    {ndb_mgmd|ndbd|ndbmtd|mysqld|ndbapi}

This command is used to set values for one or more configuration attributes. Attributes can be set on either the process level or instance level.

set commands are executed whether or not the cluster has been started. In a cluster that is not running, the MySQL Cluster Manager merely updates the configuration files. However, in a running cluster, the MySQL Cluster Manager in addition automatically performs any node restarts or rolling restarts (see Performing a Rolling Restart of an NDB Cluster) that are required to cause the attribute changes to take effect. However, since restart operations—particularly rolling restarts, where each process in the cluster must be stopped and restarted in turn—can take a great deal of time, it is preferable to make configuration changes before starting the cluster and putting it into use.

To set an attribute on the process level, use a set statement that contains an attribute assignment having the form attribute_name:process_name=value.

For example, to set DataMemory to 500 MB on the ndbd process level, so that the new value applies to all ndbd processes in the cluster, you can issue a set command containing the attribute assignment DataMemory:ndbd=500M, as shown here:

mcm> set DataMemory:ndbd=500M mycluster;
+-----------------------------------+
| Command result                    |
+-----------------------------------+
| Cluster reconfigured successfully |
+-----------------------------------+
1 row in set (5.68 sec)

To verify that the new setting is being used, you can issue the following get command:

mcm> get DataMemory mycluster;
+------------+-------+----------+------+----------+------+---------+---------+
| Name       | Value | Process1 | Id1  | Process2 | Id2  | Level   | Comment |
+------------+-------+----------+------+----------+------+---------+---------+
| DataMemory | 500M  | ndbd     | 1    |          |      | Process |         |
| DataMemory | 500M  | ndbd     | 2    |          |      | Process |         |
+------------+-------+----------+------+----------+------+---------+---------+
2 rows in set (0.79 sec)

To set an attribute for a specific process instance, include the process ID in the attribute assignment; the form of such an attribute assignment is attribute_name:process_name:process_id=value. For example, to set the wait_timeout attribute for the mysqld process that has process ID 50 to 200, you would issue a set command that contains the attribute assignment wait_timeout:mysqld:51=200, like this:

mcm> set wait_timeout:mysqld:50=200 mycluster;
+-----------------------------------+
| Command result                    |
+-----------------------------------+
| Cluster reconfigured successfully |
+-----------------------------------+
1 row in set (6.18 sec)

You can verify that the setting has taken effect using an applicable get command:

mcm> get wait_timeout mycluster;
+--------------+-------+----------+------+----------+------+-------+---------+
| Name         | Value | Process1 | Id1  | Process2 | Id2  | Level | Comment |
+--------------+-------+----------+------+----------+------+-------+---------+
| wait_timeout | 200   | mysqld   | 50   |          |      |       |         |
+--------------+-------+----------+------+----------+------+-------+---------+
1 row in set (0.50 sec)

Attributes which are marked Read only cannot be set. Attempting to do so fails with an error, as shown here:

mcm> get :ndbd mycluster;
+--------------+-------------+----------+-----+----------+-----+-------+-----------+
| Name         | Value       | Process1 | Id1 | Process2 | Id2 | Level | Comment   |
+--------------+-------------+----------+-----+----------+-----+-------+-----------+
| DataDir      | /opt/c2data | ndbd     | 1   |          |     |       |           |
| HostName     | tonfisk     | ndbd     | 1   |          |     |       | Read only |
| NodeId       | 2           | ndbd     | 1   |          |     |       | Read only |
| DataDir      | /opt/c3data | ndbd     | 2   |          |     |       |           |
| HostName     | grindval    | ndbd     | 2   |          |     |       | Read only |
| NodeId       | 3           | ndbd     | 2   |          |     |       | Read only |
+--------------+-------------+----------+-----+----------+-----+-------+-----------+
6 rows in set (1.42 sec)
mcm> set HostName:ndbd:1=lax mycluster;
ERROR 6008 (00MGR): Config attribute HostName is read only and cannot be changed

However, you can set mandatory attributes, such as in the example shown previously in this section where the DataDir configuration attribute was set to a user-defined value.

Unlike the case with the get command, you cannot issue a set acting on a “global” scope—that is, you cannot, in a single attribute assignment, set a single value for an attribute such that the new attribute value applies to all processes regardless of process type, even if the attribute having that name can be applied to all process types. Nor can you specify multiple process types in a single attribute assignment. Attempting to do either of these things causes an error, as shown here:

mcm> set DataDir=/var/cluster-data mycluster;
ERROR 3 (00MGR): Illegal syntax

mcm> set DataDir:ndb_mgmd,ndbd,mysqld=/var/cluster-data mycluster;
ERROR 3 (00MGR): Illegal syntax

Instead, you must use a process-level attribute assignment for each process type. However, you are not necessarily required to issue a separate set command for each process type. Instead, you can also make multiple attribute assignments in a single set command, supplying the assignments as a comma-separated list. This set command assigns /var/cdata as the data directory (DataDir) for all MySQL Cluster processes in the cluster named mycluster:

mcm> set DataDir:ndb_mgmd=/var/cdata, \
            DataDir:ndbd=/var/cdata, \
            DataDir:mysqld=/var/cdata mycluster;
+-----------------------------------+
| Command result                    |
+-----------------------------------+
| Cluster reconfigured successfully |
+-----------------------------------+
1 row in set (7.66 sec)

mcm> get DataDir mycluster;
+---------+------------+----------+---------+----------+---------+-------+---------+
| Name    | Value      | Process1 | NodeId1 | Process2 | NodeId2 | Level | Comment |
+---------+------------+----------+---------+----------+---------+-------+---------+
| DataDir | /var/cdata | ndbmtd   | 1       |          |         |       |         |
| DataDir | /var/cdata | ndbmtd   | 2       |          |         |       |         |
| DataDir | /var/cdata | ndb_mgmd | 49      |          |         |       |         |
| datadir | /var/cdata | mysqld   | 50      |          |         |       |         |
| datadir | /var/cdata | mysqld   | 51      |          |         |       |         |
+---------+------------+----------+---------+----------+---------+-------+---------+
5 rows in set (0.08 sec)

As you can see from the get command just shown, the attribute assignments were successful, and took effect on the process level.

Similarly, you cannot reference multiple process IDs in a single attribute assignment, even if they are processes of the same type; the following command does not work:

mcm> set DataMemory:ndbd:1,2=750M mycluster;
ERROR 3 (00MGR): Illegal syntax

Instead, you would need to use the following command:

mcm> set DataMemory:ndbd:1=750M,DataMemory:ndbd:2=750M mycluster;
+-----------------------------------+
| Command result                    |
+-----------------------------------+
| Cluster reconfigured successfully |
+-----------------------------------+
1 row in set (7.70 sec)

(Of course, if these are the only two data nodes in mycluster, then the command set DataMemory:ndbd=750M mycluster also accomplishes the same task.)

You also cannot set values for multiple attributes in a single attribute assignment; this means that the following commands do not work:

mcm> set UndoDataBuffer=32M,UndoIndexBuffer=8M:ndbd mycluster;
ERROR 3 (00MGR): Illegal syntax

mcm> set DataMemory,IndexMemory:ndbd=1G mycluster;
ERROR 3 (00MGR): Illegal syntax

However, if you write a complete and valid attribute assignment for each attribute whose value you wish to update, you can rewrite these two commands so that they execute successfully, as shown here:

mcm> set UndoDataBuffer:ndbd=32M,UndoIndexBuffer:ndbd=8M mycluster;
+-----------------------------------+
| Command result                    |
+-----------------------------------+
| Cluster reconfigured successfully |
+-----------------------------------+
1 row in set (6.62 sec)

mcm> set DataMemory:ndbd=1G,IndexMemory:ndbd=1G mycluster;
+-----------------------------------+
| Command result                    |
+-----------------------------------+
| Cluster reconfigured successfully |
+-----------------------------------+
1 row in set (7.04 sec)

In fact, there is no reason that you cannot perform all four assignments in a single set command, using a list of four attribute assignments, like this:

mcm> set UndoDataBuffer:ndbd=32M,UndoIndexBuffer:ndbd=8M, \
          DataMemory:ndbd=1G, IndexMemory:ndbd=1G mycluster;
+-----------------------------------+
| Command result                    |
+-----------------------------------+
| Cluster reconfigured successfully |
+-----------------------------------+
1 row in set (6.24 sec)

However, it a good idea not to perform too many attribute assignments in any single set command, since this makes it more difficult to spot errors.

On Windows, when setting attributes whose values contain paths (such as DataDir), you must replace any backslash characters in the path with forward slashes. Suppose that you want to use C:\temp\node50 for the tmpdir attribute of the mysqld process having node ID 50 in a MySQL Cluster named mycluster which is running on Windows. The original value for this attribute can be seen using the appropriate get command:

mcm> get tmpdir mycluster;
+--------+----------------+----------+-----+----------+-----+-------+---------+
| Name   | Value          | Process1 | Id1 | Process2 | Id2 | Level | Comment |
+--------+----------------+----------+-----+----------+-----+-------+---------+
| tmpdir | c:\c50data\tmp | mysqld   | 50  |          |     |       |         |
+--------+----------------+----------+-----+----------+-----+-------+---------+
1 row in set (0.22 sec)

The correct set command to make the desired configuration change is shown here:

mcm> set tmpdir:mysqld:50=c:/temp/node50 mycluster;
+-----------------------------------+
| Command result                    |
+-----------------------------------+
| Cluster reconfigured successfully |
+-----------------------------------+
1 row in set (2.62 sec)

When you check the value using get—even though it was originally shown using backslashes—the forward slashes are used when displaying the new value:

mcm> get tmpdir mycluster;
+--------+----------------+----------+-----+----------+-----+-------+---------+
| Name   | Value          | Process1 | Id1 | Process2 | Id2 | Level | Comment |
+--------+----------------+----------+-----+----------+-----+-------+---------+
| tmpdir | c:/temp/node50 | mysqld   | 50  |          |     |       |         |
+--------+----------------+----------+-----+----------+-----+-------+---------+
1 row in set (0.22 sec)

However, if you try to use backslashes in the path when issuing the set command, the command fails:

mcm> set tmpdir:mysqld:4=c:\temp\4 mycluster;
Outfile disabled.
ERROR:
Unknown command '\4'.
ERROR 6014 (00MGR): Path name for parameter tmpdir must be absolute.
The value 'c:mp4' is illegal.

Setting TCP Connection Attributes.  For a few attributes that apply only when using TCP connections (such as the SendBufferMemory and ReceiveBufferMemory attributes), it is necessary to use a modified syntax for attribute value assignments. In this case, the attribute assignment contains two process specifications, one for each process type or instance to which the setting applies, joined with a plus sign (+). For the following example, consider the cluster named mycluster2, consisting of the processes shown here:

mcm> list processes mycluster2;
+------+----------+-------------+
| Id   | Name     | Host        |
+------+----------+-------------+
| 49   | ndb_mgmd | grindval    |
| 1    | ndbd     | tonfisk     |
| 2    | ndbd     | flundra     |
| 50   | mysqld   | haj         |
| 51   | mysqld   | torsk       |
+------+----------+-------------+
5 rows in set (0.16 sec)

(See Section 4.6.3, “The list processes Command”, for more information about this command.)

TCP connection attributes are not shown in the output from the get command unless they have been set. This means that, prior to setting SendBufferMemory for the first time, you obtain an empty result if you try to retrieve its value, as shown here:

mcm> get SendBufferMemory mycluster2;
Empty set (0.18 sec)

mcm> get --include-defaults SendBufferMemory mycluster2;
Empty set (0.93 sec)

To set the SendBufferMemory to 4 MB for all TCP connections between data nodes and SQL nodes, you can use the command shown here:

mcm> set SendBufferMemory:ndbd+mysqld=4M mycluster2;
+-----------------------------------+
| Command result                    |
+-----------------------------------+
| Cluster reconfigured successfully |
+-----------------------------------+
1 row in set (6.44 sec)

If you check the attribute's value afterwards using get, you can see that the value is applied to all possible connections between each of the two ndbd processes and each of the two mysqld processes in mycluster2, thus there are four rows in the output:

mcm> get SendBufferMemory mycluster2;
+------------------+-------+----------+-----+----------+-----+---------+---------+
| Name             | Value | Process1 | Id1 | Process2 | Id2 | Level   | Comment |
+------------------+-------+----------+-----+----------+-----+---------+---------+
| SendBufferMemory | 4M    | ndbd     | 2   | mysqld   | 4   | Process |         |
| SendBufferMemory | 4M    | ndbd     | 2   | mysqld   | 5   | Process |         |
| SendBufferMemory | 4M    | ndbd     | 3   | mysqld   | 4   | Process |         |
| SendBufferMemory | 4M    | ndbd     | 3   | mysqld   | 5   | Process |         |
+------------------+-------+----------+-----+----------+-----+---------+---------+
4 rows in set (1.63 sec)

To override this setting for only the connection between the data node with process ID 2 and the mysqld process (process ID 4), you can include the process ID in each of the two parts of the process specification, as shown here:

mcm> set SendBufferMemory:ndbd:2+mysqld:4=8M mycluster2;
+-----------------------------------+
| Command result                    |
+-----------------------------------+
| Cluster reconfigured successfully |
+-----------------------------------+
1 row in set (7.95 sec)

When you check the result using a get command, you can see that the new setting applies on the instance level, and only to the connection between processes having IDs 2 and 4; the process-level setting made previously still applies to the remaining 3 connections:

mcm> get SendBufferMemory mycluster2;
+------------------+-------+----------+-----+----------+-----+---------+---------+
| Name             | Value | Process1 | Id1 | Process2 | Id2 | Level   | Comment |
+------------------+-------+----------+-----+----------+-----+---------+---------+
| SendBufferMemory | 8M    | ndbd     | 2   | mysqld   | 50  |         |         |
| SendBufferMemory | 4M    | ndbd     | 2   | mysqld   | 51  | Process |         |
| SendBufferMemory | 4M    | ndbd     | 3   | mysqld   | 50  | Process |         |
| SendBufferMemory | 4M    | ndbd     | 3   | mysqld   | 51  | Process |         |
+------------------+-------+----------+-----+----------+-----+---------+---------+
4 rows in set (0.24 sec)

You cannot set a connection attribute on the process level in one part of the process specification (that is, for one end of the connection) and on the instance level in the other. Attempting to do so fails with an error, as shown here:

mcm> set SendBufferMemory:ndbd+mysqld:4=2M mycluster2;
ERROR 3 (00MGR): Illegal syntax
mcm> set SendBufferMemory:ndbd:2+mysqld=2M mycluster2;
ERROR 3 (00MGR): Illegal syntax

Setting Attributes for mysqld nodes.  When a dynamic variable is set, mcmd sends out a SET GLOBAL statement to the mysqld to apply the value and also saves the value to the mysqld configuration file, so the value can be applied again at the next mysqld restart; however, an immediate restart is triggered when a non-dynamic variable is set.

Setup for mysqld connection pooling.  Enabling connection pooling for mysqld can be done by setting the ndb-cluster-connection-pool attribute to the desired number of connections, but also requires an extra step in creating the cluster.

Because the mysqld process attempts to make multiple connections to the cluster when connection pooling is enabled, the cluster must be configured with “spare” or “empty” connections. You can do this by adding (otherwise) unused ndbapi entries in the process_host list used in the create cluster command, as shown here:

mcm> create cluster -P mypackage 
   > -R ndb_mgmd@10.100.10.97,ndbd@10.100.10.98,ndbd@10.100.10.99, \
        mysqld@10.100.10.100,ndbapi@10.100.10.100, \
        ndbapi@10.100.10.100,ndbapi@10.100.10.100
   > mycluster;
+------------------------------+
| Command result               |
+------------------------------+
| Cluster created successfully |
+------------------------------+
1 row in set (6.58 sec)

After this, you can use a set command like this one to set the size of the connection pool according to the number of excess connections available in the config.ini file:

mcm> set ndb_cluster_connection_pool:mysqld=4;

user attribute not supported for mysqld.  Trying to set the user attribute for a mysqld process is not currently supported, and results in a warning being written to the MySQL Cluster Manager log.

add process {--processhosts=|-R }process_host_list
    [--set=attribute_assignment_list] [--verbose | -v] cluster_name

process_host_list:
    process_name[:node_id]@host[,process_name@host[,...]]

process_name:
    {ndb_mgmd|ndbd|ndbmtd|mysqld|ndbapi}

attribute_assignment_list:
    attribute_assignment[,attribute_assignment][,...]

attribute_assignment:
    attribute_name:process_name[=value]

This command adds to an existing cluster one or more processes, which are specified using a process_host_list with the --processhosts option, the format of which is the same as that used with the create cluster command. Any hosts referenced in the list must be members of the site to which the cluster belongs. In addition, all hosts must be resolvable.

Any new processes added by this command must be started explicitly using the command start process --added.

For example, the following add process command adds two mysqld processes on hosts tonfisk and flundra to the cluster named mycluster:

mcm> add process --processhosts=mysqld@tonfisk,mysqld@flundra mycluster;
+------------------------------+
| Command result               |
+------------------------------+
| Processes added successfully |
+------------------------------+
1 row in set (2 min 10.39 sec)

With the --verbose option, the command shows an updated process list, after the new processes have been added:

mcm> add process --processhosts=ndbmtd@tonfisk,ndbmtd@flundra --verbose mcluster;
+--------+----------+---------+
| NodeId | Name     | Host    |
+--------+----------+---------+
| 49     | ndb_mgmd | tonfisk |
| 53     | ndb_mgmd | flundra |
| 1      | ndbmtd   | tonfisk |
| 2      | ndbmtd   | flundra |
| 3      | ndbmtd   | tonfisk |
| 4      | ndbmtd   | flundra |
| 50     | mysqld   | tonfisk |
| 51     | mysqld   | flundra |
| 52     | ndbapi   | *       |
+--------+----------+---------+
9 rows in set (2 min 7.57 sec)

You can also manually assign a node ID to the new process you are adding to the cluster by adding “:node_ID.” after the process_name. For MySQL Cluster Manager 1.3.3 and earlier, trying to manually assign node IDs less than 49 for ndb_mgmd, mysqld, or ndbapi fails with an error; the restriction, however, has been lifted since MySQL Cluster Manager 1.3.4. Nevertheless, you are still recommended to follow the best practice of reserving node ID 1 to 48 for data nodes. The following command adds two ndbd processes with node IDs 10 and 11 on hosts tonfisk and flundra, respectively, to mycluster:

mcm> add process --processhosts=ndbd:10@tonfisk,ndbd:11@flundra mycluster;
+------------------------------+
| Command result               |
+------------------------------+
| Processes added successfully |
+------------------------------+
1 row in set (2 min 13.40 sec)

Adding Free Processes

Using the add process command, you can add unmanaged mysqld processes, or ndbapi slots for ndbapi applications such as ndb_restore. To add an unmanaged mysqld process, prefix the hostname with the wildcard * (asterisk character):

mcm> add process --processhosts=mysqld@*tonfisk,mysqld@*flundra mycluster;
+------------------------------+
| Command result               |
+------------------------------+
| Processes added successfully |
+------------------------------+
1 row in set (2 min 3.14 sec)

To allow the unmanaged mysqld nodes to connect from any host, use the wildcard * (asterisk character) in place of the hostname or IP address:

mcm> add process --processhosts=mysqld@*,mysqld@* mycluster;
+------------------------------+
| Command result               |
+------------------------------+
| Processes added successfully |
+------------------------------+
1 row in set (2 min 3.14 sec)

The same applies to ndbapi slots for ndbapi applications such as ndb_restore: prefix the hostname with the wildcard character to limit connectivity to a specific host, or use only a wildcard, without hostname, to allow ndbapi applications from any host:

mcm> add process --processhosts=ndbapi@*tonfisk,ndbapi@* mycluster;
+------------------------------+
| Command result               |
+------------------------------+
| Processes added successfully |
+------------------------------+
1 row in set (2 min 8.13 sec)

Because “free” processes are not managed by MySQL Cluster Manager, there is no need to run the start process --added command after they have been successfully added to the cluster.

Using add process to Simplify create cluster Commands

Processes added before the cluster is started for the first time are started with the cluster. This makes it possible to use this command to break down what would otherwise be very long create cluster commands. Consider the following set of commands which creates and then starts a cluster named mycluster:

create cluster --processhosts=ndb_mgmd@host1,ndbd@host1,ndbd@host2, \
  mysqld@host3,mysqld@host4 mycluster;
start cluster mycluster;

The long create cluster command can be divided into a shorter (and more manageable) version of itself, plus several add process commands. This set of commands performs the same task as the previous set, creating mycluster with exactly the same processes and hosts as before, and then starting it:

create cluster --processhosts=ndb_mgmd@host1 mycluster;
add process --processhosts=ndbd@host1,ndbd@host2 mycluster;
add process --processhosts=mysqld@host3,mysqld@host4 mycluster;
start cluster mycluster;

Because mycluster was never started before the ndbd and mysqld processes were added to it using the add process commands shown, it is not necessary to use the --added option with the start cluster command in this case; all 5 processes are started.

A process that is added to a cluster that was created using create cluster --import and before the import takes place is added with status import, which means it cannot be started or stopped using start process or stop process before an import has taken place.

Configuring a New Process when Adding it

A newly added process inherits its configuration attribute settings from those in effect for its process type on the parent cluster, or assume the default settings for that process type if none apply. Existing attribute settings in the cluster must have process-level scope to be inherited by new processes added later; instance-level settings set for existing process instances prior to adding any new ones do not apply to any of the added processes. (See Configuration attributes, for more information about the scope of attribute settings.)

Inherited attribute settings can be overridden when adding processes; to do this, use the add process command's --set option. This option takes as its argument an attribute assignment list similar in format to that used with the get and set commands. Suppose that the current ndbd process-level setting in the cluster named mycluster for the DataDir attribute is /home/users/ndb/cluster-data, but you wish to add two new ndbd processes that use /tmp/cluster/data instead. You can do this using the following command:

mcm> add process --set=ndbd:DataDir=/tmp/cluster/data
   > --processhosts=mysqld@tonfisk,mysqld@flundra
   > mycluster;

When setting attributes in this way which contain paths for processes running on Windows, you must replace any backslashes (\) used with forward slashes (/), just as with the set command. See Setting Attributes Containing Paths on Windows, for more information.

After a process has been added using add process, you can also use the set command to modify its configuration attribute settings (or specify additional ones) as you would with any other cluster process being managed with MySQL Cluster Manager.

change process old_proc_type[:proc-id]=new_proc_type cluster_name

old_proc_type | new_proc_type:
    {ndbd|ndbmtd}

This command is used (MySQL Cluster NDB 7.0 and later) to change the process type for a given MySQL Cluster process or group of MySQL Cluster processes from one process type (old-process-type) to another process type (new-process-type).

Currently, the only two process types available for use with this command are ndbd and ndbmtd. This means that change process can be used to change the data node process running on one or more data nodes from the single-threaded data node daemon (ndbd) to the multi-threaded data node daemon (ndbmtd) or vice versa.

By default, change process affects all data nodes running the old-process-type. By specifying an optional process_id, its action can be restricted to the data node having that process ID.

Suppose you have a cluster which is named mycluster and which has two data nodes using ndbd processes, as reflected in the output of the following show status command:

mcm> show status --process mycluster;
+--------+----------+----------+----------+-----------+
| NodeId | Process  | Host     | Status   | Nodegroup |
+--------+----------+----------+----------+-----------+
| 49     | ndb_mgmd | flundra  | running  |           |
| 1      | ndbd     | tonfisk  | running  | n/a       |
| 2      | ndbd     | grindval | running  | n/a       |
| 50     | mysqld   | haj      | running  |           |
| 51     | mysqld   | torsk    | running  |           |
| 52     | ndbapi   | *        | running  |           |
+--------+----------+----------+----------+-----------+
6 rows in set (0.06 sec)

To change both data nodes to so that they use multi-threaded (ndbmtd) processes, issue the command shown here, without any process_id specifier:

mcm> change process ndbd=ndbmtd mycluster;
+------------------------------+
| Command result               |
+------------------------------+
| Process changed successfully |
+------------------------------+
1 row in set (2 min 17.51 sec)

After the command has executed, you can verify that both data nodes are now using ndbmtd by checking the output of the appropriate show status command, as shown here:

mcm> show status --process mycluster;
+--------+----------+----------+----------+-----------+
| NodeId | Process  | Host     | Status   | Nodegroup |
+--------+----------+----------+----------+-----------+
| 49     | ndb_mgmd | flundra  | running  |           |
| 1      | ndbmtd   | tonfisk  | running  | n/a       |
| 2      | ndbmtd   | grindval | running  | n/a       |
| 50     | mysqld   | haj      | running  |           |
| 51     | mysqld   | torsk    | running  |           |
| 52     | ndbapi   | *        | running  |           |
+--------+----------+----------+----------+-----------+
6 rows in set (0.09 sec)

It is possible (and sometimes desirable) to use ndbd and ndbmtd data node processes concurrently; thus, it is also possible using the change process command to change a single data node process from single-threaded to multi-threaded, or from multi-threaded to single-threaded. To do this, you must specify the data node process using its process ID.

First, we stop the cluster and verify that all processes are no longer running, as shown here:

mcm> stop cluster mycluster;
+------------------------------+
| Command result               |
+------------------------------+
| Cluster stopped successfully |
+------------------------------+
1 row in set (22.93 sec)

mcm> show status --process mycluster;
+--------+----------+----------+----------+-----------+
| NodeId | Process  | Host     | Status   | Nodegroup |
+--------+----------+----------+----------+-----------+
| 49     | ndb_mgmd | flundra  | stopped  |           |
| 1      | ndbmtd   | tonfisk  | stopped  | n/a       |
| 2      | ndbmtd   | grindval | stopped  | n/a       |
| 50     | mysqld   | haj      | stopped  |           |
| 51     | mysqld   | torsk    | stopped  |           |
| 52     | ndbapi   | *        | stopped  |           |
+--------+----------+----------+----------+-----------+
6 rows in set (0.05 sec)

The following command changes only the node having the process ID 2 from using the multi-threaded data node daemon to the single-threaded version:

mcm> change process ndbmtd:2=ndbd mycluster;
+------------------------------+
| Command result               |
+------------------------------+
| Process changed successfully |
+------------------------------+
1 row in set (6.52 sec)

As you can see, change process operates much more quickly when the process to be changed is not running. As before, you can verify that the command succeeded using show status:

mcm> show status --process mycluster;
+--------+----------+----------+----------+-----------+
| NodeId | Process  | Host     | Status   | Nodegroup |
+--------+----------+----------+----------+-----------+
| 49     | ndb_mgmd | flundra  | stopped  |           |
| 1      | ndbmtd   | tonfisk  | stopped  | n/a       |
| 2      | ndbd     | grindval | stopped  | n/a       |
| 50     | mysqld   | haj      | stopped  |           |
| 51     | mysqld   | torsk    | stopped  |           |
| 52     | ndbapi   | *        | stopped  |           |
+--------+----------+----------+----------+-----------+
6 rows in set (0.07 sec)

To complete the example, we start the cluster again, using start cluster, then change node number 2 back from ndbd (single-threaded) to ndbmtd (multi-threaded) using change process, then verify the change using show status:

mcm> start cluster mycluster;
+------------------------------+
| Command result               |
+------------------------------+
| Cluster started successfully |
+------------------------------+
1 row in set (36.43 sec)

mcm> change process ndbd:2=ndbmtd mycluster;
+------------------------------+
| Command result               |
+------------------------------+
| Process changed successfully |
+------------------------------+
1 row in set (2 min 10.41 sec)

mcm> show status --process mycluster;
+--------+----------+----------+----------+-----------+
| NodeId | Process  | Host     | Status   | Nodegroup |
+--------+----------+----------+----------+-----------+
| 49     | ndb_mgmd | flundra  | running  |           |
| 1      | ndbmtd   | tonfisk  | running  | n/a       |
| 2      | ndbmtd   | grindval | running  | n/a       |
| 50     | mysqld   | haj      | running  |           |
| 51     | mysqld   | torsk    | running  |           |
| 52     | ndbapi   | *        | running  |           |
+--------+----------+----------+----------+-----------+
6 rows in set (0.11 sec)

You can see that it can require much less time to stop the cluster, change a data node process, and then start the cluster again than it is to change the process while the cluster is running. However, if you do this, the cluster is not available while it is stopped.

As noted previously, change process works only with ndbd and ndbmtd processes; attempting to use any other process type causes the command to fail with an error, as shown here:

mcm> change process ndb_mgmd=mysqld mycluster;
ERROR 7009 (00MGR): Processes ndb_mgmd and mysqld are not interchangeable in this package
mcm> change process ndbd=mysqld mycluster;
ERROR 7009 (00MGR): Processes ndbd and mysqld are not interchangeable in this package

list processes cluster_name

This command displays all processes making up a given cluster. The following example demonstrates how to list all processes that are part of the cluster named mycluster:

mcm> list processes mycluster;
+--------+----------+----------+
| NodeId | Name     | Host     |
+--------+----------+----------+
| 49     | ndb_mgmd | flundra  |
| 1      | ndbd     | tonfisk  |
| 2      | ndbd     | grindval |
| 50     | mysqld   | haj      |
| 51     | mysqld   | torsk    |
| 52     | ndbapi   | *        |
+--------+----------+----------+
6 rows in set (0.03 sec)

The cluster_name argument is required. If this argument is omitted, the command fails with an error, as shown here:

mcm> list processes;
ERROR 6 (00MGR): Illegal number of operands

start process {[--initial|-i] process_id | --added} cluster_name

This command starts the MySQL Cluster process having the process ID process_id in the cluster named cluster_name. The status of the process to be started, as shown by show status --process, must be added or stopped.

This example demonstrates how to start the process having the process ID 1 belonging to the cluster mycluster:

mcm> start process 1 mycluster;
+------------------------------+
| Command result               |
+------------------------------+
| Process started successfully |
+------------------------------+
1 row in set (13.93 sec)

When the --initial option (short form: -i) is used, MySQL Cluster Manager starts a data node process with the --initial option, causing the data node to rebuild its file system.

Invoking this command with the --added option rather than with a process ID starts all nodes previously added to the cluster using add process, but not yet started.

You can obtain process IDs for all processes in a given cluster using show status --process or list processes. These are the same as the node IDs for these processes as shown in the output of other mcm client commands such as get or in the output of ndb_mgm -e "show" (see ndb_mgm — The NDB Cluster Management Client).

You cannot use this command to start a mysqld process in a cluster that is stopped or otherwise unavailable; trying to do so fails with an error. This includes a cluster created for import where the import has not yet been completed (see Section 4.4.1, “The create cluster Command”, and Section 3.5, “Importing MySQL Clusters into MySQL Cluster Manager”).

stop process process_id cluster_name

This command stops the running MySQL Cluster process with the process ID process_id in the cluster named cluster_name. The status of the process as shown by show status --process must be running.

Suppose that the process ID of a data node in the cluster named mycluster is 3. Then this data node can be stopped as shown here:

mcm> stop process 3 mycluster;
+------------------------------+
| Command result               |
+------------------------------+
| Process stopped successfully |
+------------------------------+
1 row in set (33.07 sec)

You can use show status --process or list processes to obtain process IDs for all processes in a given cluster.

In the event of a disk failure where MySQL Cluster Manager loses its manager directory (including its repository), the agent is able to recover information from other agents, but it does not actually control processes any longer, although it can detect them. This is due to the fact that the MySQL Cluster Manager agent cannot access the PID files. In this case, stop process no longer works, and you must kill such processes manually. Keep in mind that, if StopOnError is set to 0, the MySQL Cluster Manager agent restarts the data node process automatically; if StopOnError is 1 (the default), then you must execute the start process command manually.

This command does not work with processes in a cluster created for import where the import has not yet actually been completed. See Section 4.4.1, “The create cluster Command”, and Section 3.5, “Importing MySQL Clusters into MySQL Cluster Manager”, for more information.

remove process [--removedirs] process_id_list cluster_name

process_id_list:
    process_id[, process_id[, ...]]

This command removes permanently the processes in the process_id_list from the cluster named cluster_name. It provides a means to scale down a cluster offline.

If the --removedirs option is used, all data for the specified processes will be deleted.

The following restrictions apply when using this command:

You can use the show status --process or list processes command to obtain the process IDs for all the processes in a given cluster:

mcm> show status --process mycluster;
+--------+----------+---------+--------+-----------+-----------+
| NodeId | Process  | Host    | Status | Nodegroup | Package   |
+--------+----------+---------+--------+-----------+-----------+
| 49     | ndb_mgmd | flundra | added  |           | mypackage |
| 1      | ndbmtd   | flundra | added  | n/a       | mypackage |
| 2      | ndbmtd   | flundra | added  | n/a       | mypackage |
| 50     | mysqld   | flundra | added  |           | mypackage |
| 51     | mysqld   | flundra | added  |           | mypackage |
| 52     | ndbapi   | *       | added  |           |           |
| 53     | ndbapi   | *       | added  |           |           |
+--------+----------+---------+--------+-----------+-----------+
7 rows in set (0.03 sec)

The process IDs are the same as the node IDs for the processes shown in the output of the above or some other mcm client commands, or in the output of the ndb_mgm -e "show" command (see ndb_mgm — The NDB Cluster Management Client). In the above example, the SQL node with the process ID 50 in mycluster can be removed by the following command:

mcm> remove process 50 mycluster;
+------------------------------+
| Command result               |
+------------------------------+
| Process removed successfully |
+------------------------------+
1 row in set (0.48 sec)

And in this case, since the cluster was never started, we may also remove both data nodes:

mcm> remove process 1,2 mycluster;
+------------------------------+
| Command result               |
+------------------------------+
| Process removed successfully |
+------------------------------+
1 row in set (0.40 sec)

abort backup --backupid=backup_id cluster_name

This command aborts a backup of cluster cluster_name having the ID backup_id specified with the --backupid option. You can obtain a list of backups and their IDs known to this MySQL Cluster Manager instance using the list backups. If the backup is not actually in progress, the command has no effect.

backup cluster [--backupid=backup_id]
    [--snapshotstart | --snapshotend]
    [--waitstarted | --waitcompleted]
    cluster_name

This command creates a backup of the MySQL Cluster named cluster_name. backup cluster takes a backup of the cluster's NDB tables only; tables using other MySQL storage engines (such as InnoDB or MyISAM) are ignored.

By default, this command uses the backup ID assigned and returned by ndb_mgmd (see the discussions on backup_id in Using The NDB Cluster Management Client to Create a Backup for more information); you can override this behavior by specifying a backup ID using the --backupid option.

The --snapshotstart option causes the backup to match the state of the cluster when the backup began.

The --snapshotend option causes the backup to reflect the state of the cluster when the backup was finished. If neither option is specified, the MySQL Cluster Manager client acts as though --snapshotend had been used.

When the --waitstarted option is used, the MySQL Cluster Manager client waits until the backup has started before returning control to the user, after which the user can check the backup process' status with the show status command and the --backup option.

When the --waitcompleted option is used, the MySQL Cluster Manager client waits until the backup process is complete before returning control to the user. If neither --waitstarted or --waitcompleted is specified, the client behaves as if --waitcompleted had been used.

mcm> backup cluster mycluster;
+-------------------------------+
| Command result                |
+-------------------------------+
| Backup completed successfully |
+-------------------------------+
1 row in set (33.50 sec)

You can verify that the backup was performed by checking the output of list backups, as shown here:

mcm> list backups mycluster;
+----------+--------+---------+----------------------+---------+
| BackupId | NodeId | Host    | Timestamp            | Comment |
+----------+--------+---------+----------------------+---------+
| 1        | 1      | tonfisk | 2016-10-24 22:24:54Z |         |
| 1        | 2      | tonfisk | 2016-10-24 22:24:54Z |         |
| 2        | 1      | tonfisk | 2016-10-24 22:24:54Z |         |
| 2        | 2      | tonfisk | 2016-10-24 22:24:54Z |         |
+----------+--------+---------+----------------------+---------+
4 rows in set (0.02 sec)

Each row in the output represents a backup image—that is, a set of backup files specific to a given backup of a named cluster on a given data node. Timestamp values are in UTC. The backup image is saved in the folder BackupDataDir/BACKUP/BACKUP-Id, where BackupDataDir is a cluster parameter. If BackupDataDir is not specified, it takes up the value of DataDir, so that the image is stored in the directory Datadir/BACKUP/BACKUP-backup_id.

It is possible to remove an unwanted backup from a given node by deleting this image directory and its contents. To remove a given backup completely, you must remove the corresponding image from each data node's BACKUP directory. You can do this as long as a backup or restore operation is not in progress. It is not necessary to stop the cluster or MySQL Cluster Manager agent prior to removing the images.

The BackupId is used with abort backup and restore cluster.

Logical Backup for NDB Table Metadata

To allow more flexibility for cluster reconfiguration during a restore, starting with release 1.4.1, the backup cluster command also creates a logical backup for the metadata of the NDB tables in the cluster. Use the --all option with the list backups command to list all backups, including the logical backups for the NDB tables' metadata, which are marked by the comment “Schema”:

mcm> list backups --all newcluster;
+----------+--------+---------+----------------------+---------+
| BackupId | NodeId | Host    | Timestamp            | Comment |
+----------+--------+---------+----------------------+---------+
| 1        | 1      | tonfisk | 2016-08-12 16:55:52Z |         |
| 1        | 2      | tonfisk | 2016-08-12 16:55:52Z |         |
| 1        | 3      | tonfisk | 2016-08-12 16:55:52Z |         |
| 1        | 4      | tonfisk | 2016-08-12 16:55:52Z |         |
| 1        | 50     | tonfisk | 2016-08-12 16:55:55Z | Schema  |
+----------+--------+---------+----------------------+---------+
5 rows in set (0.02 sec)

The logical backup was created using the mysqldump utility. The backup is saved with the file name BACKUP-BackupID.mysql_nodeid.schema.sql extension, to be found in the folder backupdatadir/BACKUP/BACKUP-id, where backupdatadir (notice that the name is in lowercase) is a mysqld parameter used only for specifying the location of the logical backup created by MySQL Cluster Manager. If backupdatadir is not specified using the set command with the mcm client, the default value of /mcm_data_repository/clusters/clustername/mysqld_nodeid/ is used, so that the logical backup is saved in the folder /mcm_data_repository/clusters/clustername/mysqld_nodeid/BACKUP/BACKUP-Id.

The following restrictions apply for the creation of the logical backups for NDB table metadata:

The backup for the NDB table metadata is helpful for restoring data from a cluster to another one with a different configuration (for example, when the target cluster for restore has a different number of data nodes); see Section 3.6.2.4, “Partial restore—data nodes added” and Section 3.6.2.5, “Restoring a Backup to a Cluster with Fewer Data Nodes” for some use cases.

list backups [{--backupid=|-I }backup_id] [-all|-a] cluster_name

This command lists all backups of the MySQL Cluster named cluster_name that are known to this instance of MySQL Cluster Manager. The output includes the backup and node ID as well as a UTC timestamp for each backup, as shown here:

mcm> list backups mycluster;
+----------+--------+---------+----------------------+---------+
| BackupId | NodeId | Host    | Timestamp            | Comment |
+----------+--------+---------+----------------------+---------+
| 1        | 1      | tonfisk | 2016-10-24 22:24:54Z |         |
| 1        | 2      | tonfisk | 2016-10-24 22:24:54Z |         |
| 2        | 1      | tonfisk | 2016-10-24 22:24:54Z |         |
| 2        | 2      | tonfisk | 2016-10-24 22:24:54Z |         |
+----------+--------+---------+----------------------+---------+
4 rows in set (0.02 sec)

With the --backupid option used, the commands only list backups with the specified ID:

mcm> list backups --backupid=2 mycluster;
+----------+--------+---------+----------------------+---------+
| BackupId | NodeId | Host    | Timestamp            | Comment |
+----------+--------+---------+----------------------+---------+
| 2        | 1      | tonfisk | 2016-10-24 22:24:54Z |         |
| 2        | 2      | tonfisk | 2016-10-24 22:24:54Z |         |
+----------+--------+---------+----------------------+---------+
2 rows in set (0.02 sec)

For MySQL Cluster Manager 1.4.1 and later: The backup cluster command also creates backups of the metadata for a cluster's NDB tables, which are listed by the list backups command when the --all option is used. The metadata backups are marked by the comment Schema in the backup listing:

mcm> list backups --all newcluster;
+----------+--------+---------+----------------------+---------+
| BackupId | NodeId | Host    | Timestamp            | Comment |
+----------+--------+---------+----------------------+---------+
| 1        | 1      | tonfisk | 2016-08-12 16:55:52Z |         |
| 1        | 2      | tonfisk | 2016-08-12 16:55:52Z |         |
| 1        | 3      | tonfisk | 2016-08-12 16:55:52Z |         |
| 1        | 4      | tonfisk | 2016-08-12 16:55:52Z |         |
| 1        | 50     | tonfisk | 2016-08-12 16:55:55Z | Schema  |
+----------+--------+---------+----------------------+---------+
5 rows in set (0.02 sec)

See Logical Backup for NDB Table Metadata for details about the metadata backup.

restore cluster
    {--backupid=|-I }backup_id
    [--disable-indexes|-x]
    [--disable-metadata|-M]
    [--epoch|-e]
    [--exclude-databases=db_name]
    [--exclude-intermediate-sql-tables]
    [--exclude-missing-columns]
    [--exclude-missing-tables]
    [--exclude-tables=db_name.tbl_name[,db_name.tbl_name][,...]]
    [--include-databases=db_name]
    [--include-tables=db_name.tbl_name[,db_name.tbl_name][,...]]
    [--lossy-conversions]      
    [--no-binlog|-l]
    [--no-restore-disk-objects]
    [{--parallelism=|-p }#]
    [--privilege-tables|-P]
    [--progress-frequency]
    [--promote-attributes]
    [--rewrite-database]
    [--skip-broken-objects]
    [{--skip-nodeid=|-s }id_list]
    [--skip-table-check]                                    
    [--skip-unknown-objects]
    cluster_name

This command restores a cluster from a backup having the specified backup ID (--backupid option; short form: -I) to the MySQL Cluster named cluster_name. In its simplest form, it can be used as shown here, to restore the cluster named mycluster to the state saved in the backup having backup ID 3:

mcm> restore cluster --backupid=3 mycluster;
+--------------------------------+
| Command result                 |
+--------------------------------+
| Restore completed successfully |
+--------------------------------+
1 row in set (18.60 sec)

If you are restoring an existing cluster to a known good state, you must wipe any existing data first. Stop the cluster using stop cluster, then restart it using start cluster with the --initial option, which causes the data node file systems to be cleared. (Note that Disk Data files must be removed manually.) Following this, you can restore the cluster from the desired backup using restore cluster.

Additional options that can be employed with this command include:

--disable-indexes and --disable-metadata.  To cause indexes to be ignored when restoring the table data, use the --disable-indexes option (short form: -x). Doing this can decrease the time required to restore a large data set, particularly where many indexes were in use. Similarly, you can cause metadata to be ignored during the restoration process by using the --disable-metadata option (short form: -M).

--epoch.  When the --epoch option (short form: -e) is used, epoch information is restored to the cluster replication status table (mysql.ndb_apply_status), which can be useful for MySQL Cluster replication slaves.

--exclude-databases and --exclude-tables.  Prevent one or more databases or tables from being restored using the options --exclude-databases and --exclude-tables. --exclude-databases takes a comma-delimited list of one or more databases which should not be restored. --exclude-tables takes a comma-delimited list of one or more tables (using the database.table format) which should not be restored. When --exclude-databases or --exclude-tables is used, only those databases or tables named by the option are excluded; all other databases and tables are restored.

--exclude-missing-columns.  When this option is used, restore cluster ignores any columns missing from tables being restored as compared to the versions of those tables found in the backup.

--exclude-missing-tables.  When this option is used, restore cluster ignores any tables from the backup that are not found in the target database.

--exclude-intermediate-sql-tables[=TRUE|FALSE].  When performing ALTER TABLE operations, mysqld creates intermediate tables (whose names are prefixed with #sql-). When TRUE, the --exclude-intermediate-sql-tables option keeps restore cluster from restoring such tables that may have been left over from such operations. This option is TRUE by default.

--include-databases and --include-tables.  Use the --include-databases option or the --include-tables option for restoring only specific databases or tables, respectively. --include-databases takes a comma-delimited list of databases to be restored. --include-tables takes a comma-delimited list of tables (in the database.table format) to be restored. When --include-databases or --include-tables is used, only those databases or tables named by the option are restored; all other databases and tables are excluded by restore cluster, and are not restored.

--lossy-conversions.  Using --lossy-conversions allows lossy conversions of column values (type demotions or changes in sign) when restoring data from backup. With some exceptions, the rules governing demotion are the same as for MySQL replication; see Replication of Columns Having Different Data Types, for information about specific type conversions currently supported by attribute demotion. restore cluster reports any truncation of data that it performs during lossy conversions once per attribute and column.

--no-binlog.  The --no-binlog option (short form: -l) stops any SQL nodes (mysqld processes) in the cluster from writing data from the restore into their binary logs.

--no-restore-disk-objects.  This option stops restore cluster from restoring any MySQL Cluster Disk Data objects, such as tablespaces and log file groups; see NDB Cluster Disk Data Tables, for more information about these objects.

--parallelism=#.  The --parallelism option (short form: -p) sets the maximum number of parallel transactions that the restore cluster command attempts to use. The default value is 128; the maximum is 1024, and the minimum is 1.

--privilege-tables.  The --privilege-tables option (short form: -P) causes restoration of tables required for distributed grants (see Distributed MySQL Privileges for NDB Cluster).

--progress-frequency=N.  Print a status report each N seconds to a temporary stdout dump file mcm creates at mcm_data/clusters/cluster_name/nodeid/tmp while the backup is in progress. 0 (the default) causes no status reports to be printed. The maximum is 65535.

--promote-attributes.  Allow attributes to be promoted when MySQL Cluster Manager restores data from a backup. See the discussion on attribute promotion in the MySQL Cluster manual for more details.

--rewrite-database=old_dbname,new_dbname.  This option causes a database with the name old_dbname in the backup to be restored under the name new_dbname.

--skip-nodeid.  The --skip-nodeid option (short form: -s) takes a comma-separated list of node IDs. The nodes whose IDs are listed may include of data nodes, SQL nodes, or both. Nodes having these IDs are skipped by the restoration process.

--skip-broken-objects.  This option causes restore cluster to ignore corrupt tables while reading a backup, and to continue restoring any remaining tables (that are not also corrupted). Currently, the --skip-broken-objects option works only in the case of missing blob parts tables.

--skip-table-check.  It is possible to restore data without restoring table metadata. The default behavior when doing this is for restore cluster to fail with an error if table data do not match the table schema; this can be overridden using the --skip-table-check option.

--skip-unknown-objects.  This option causes restore cluster to ignore any schema objects it does not recognize while reading a backup. This can be used for restoring, for example, a backup made from a newer version of MySQL Cluster to an older version.

backup agents [--hosts=host_list] [site_name]

host_list:
    host[, host[, ...]]

This command backs up the configuration data for the mcmd agents on the hosts specified in host_list with the --hosts option (short form: -h) for the site named site_name. If no host names are specified, all agents of the site are backed up. If no site_name is given, only the agent that the mcm client is connected to is backed up.

The backup for each agent is created in a subfolder named rep_backup/timestamp under the agent repository (the mcm_data folder), with timestamp reflecting the time the backup began. If you want the backup to be at another place, create a soft link from mcm_data/rep_backup to your desired storage location.

Notice that the backup agents command works differently from the backup cluster command, which backs up cluster data; the backup agents command, on the other hand, backs up agent configuration data. Using together the backups created by both commands, you can restore not just the cluster, but the complete cluster-plus-manager setup. See Section 3.7, “Backing Up and Restoring MySQL Cluster Manager Agents” for more details about backing up and restoring mcmd agents.

import cluster [--dryrun|-y] cluster_name

This command imports a MySQL Cluster created independently of MySQL Cluster Manager into a cluster named cluster_name that has been created in MySQL Cluster Manager. You are strongly advised to create cluster_name using the create cluster command's --import option; see that command's description for more information about the --import option and its effects.

import cluster requires a single argument, the name of the cluster created using MySQL Cluster Manager (cluster_name) into which you wish to import a MySQL Cluster created externally into MySQL Cluster Manager and bring it under MySQL Cluster Manager control. The cluster named in the command must already exist in MySQL Cluster Manager.

import cluster also supports a --dryrun option. When this option is used, only the checks required for importation are performed against the existing cluster. This makes it possible to test a given configuration without actually placing any cluster processes under MCM control. -y is supported as a short form of this option.

For more information about importing clusters into MySQL Cluster Manager, including examples, see Section 3.5, “Importing MySQL Clusters into MySQL Cluster Manager”.

import config [--dryrun|-y] cluster_name

This command imports the configuration of an autonomous or “wild” cluster into the cluster named cluster_name.

import config requires a single argument, cluster_name, which is the name of the cluster created using MySQL Cluster Manager into which you wish to import the configuration of a MySQL Cluster created externally. The cluster named in the command must already exist in MySQL Cluster Manager; you are also strongly advised to use create cluster --import when creating cluster_name.

import config also supports a --dryrun option (short form: -y). When this option is used, the checks required for importing the configuration data are performed, and the set commands for performing the actual import are written to the file /path-to-mcm-data-repository/clusters/clustername/tmp/import_config.message_id.mcm for your examination. This makes it possible to test the configuration import without actually copying any of the settings into the cluster controlled by MySQL Cluster Manager. You can then import all the settings using the import config command (without the --dryrun option), or adjust some of the settings in the /path-to-mcm-data-repository/clusters/clustername/tmp/import_config.message_id.mcm file and then import the settings by executing the file with the mcm agent. See Section 3.5.2.3, “Creating and Configuring the Target Cluster” for examples on using the import config command.