In addition to the central configuration file, a cluster may also be controlled through a command-line interface available through the management client ndb_mgm. This is the primary administrative interface to a running cluster.
Commands for the event logs are given in Section 7.6, “Event Reports Generated in MySQL Cluster”; commands for creating backups and restoring from them are provided in Section 7.3, “Online Backup of MySQL Cluster”.
Using ndb_mgm with MySQL Cluster Manager.
MySQL Cluster Manager handles starting and stopping processes and tracks their
states internally, so it is not necessary to use
ndb_mgm for these tasks for a MySQL Cluster
that is under MySQL Cluster Manager control. it is recommended
not to use the ndb_mgm
command-line client that comes with the MySQL Cluster
distribution to perform operations that involve starting or
stopping nodes. These include but are not limited to the
SHUTDOWN commands. For more
information, see MySQL Cluster Manager Process Commands.
The management client has the following basic commands. In the
listing that follows,
either a database node ID or the keyword
which indicates that the command should be applied to all of the
cluster's data nodes.
Displays information on all available commands.
Connects to the management server indicated by the connection string. If the client is already connected to this server, the client reconnects.
Displays information on the cluster's status. Possible node status values include
Beginning with MySQL Cluster NDB 6.2.8 and MySQL Cluster NDB 6.3.6, the output from this command indicates when the cluster is in single user mode (status
SINGLE USER MODE).
Prior to MySQL Cluster NDB 7.0.26 and MySQL Cluster NDB 7.1.5, in a cluster having multiple management nodes, this command displayed information only for data nodes that were actually connected to the current management server; in addition, management servers could not find each other until all nodes had been started. Beginning with these versions, such issues are fixed (see Bug #12352191), and management nodes can be additionally be reported with status
Brings online the data node identified by
node_id(or all data nodes).
ALL STARTworks on all data nodes only, and does not affect management nodes.Important
To use this command to bring a data node online, the data node must have been started using
Stops the data or management node identified by
ALL STOPworks to stop all data nodes only, and does not affect management nodes.
-aoption causes the node to be stopped immediately, without waiting for the completion of any pending transactions.
STOPfails if the result would cause an incomplete cluster. The
-foption, added in MySQL Cluster NDB 7.0.19 and MySQL Cluster NDB 7.1.8, forces the node to shut down without checking for this. If this option is used and the result is an incomplete cluster, the cluster immediately shuts down.Warning
Use of the
-aoption also disables the safety check otherwise performed when
STOPis invoked to insure that stopping the node does not cause an incomplete cluster. In other words, you should exercise extreme care when using the
-aoption with the
STOPcommand, due to the fact that this option makes it possible for the cluster to undergo a forced shutdown because it no longer has a complete copy of all data stored in
Restarts the data node identified by
node_id(or all data nodes).
RESTARTcauses the data node to perform an initial restart; that is, the node's file system is deleted and recreated. The effect is the same as that obtained from stopping the data node process and then starting it again using ndbd
--initialfrom the system shell.Note
Backup files and Disk Data files are not removed when this option is used.
-noption causes the data node process to be restarted, but the data node is not actually brought online until the appropriate
STARTcommand is issued. The effect of this option is the same as that obtained from stopping the data node and then starting it again using ndbd
-nfrom the system shell.
-acauses all current transactions relying on this node to be aborted. No GCP check is done when the node rejoins the cluster.
RESTARTfails if taking the node offline would result in an incomplete cluster. The
-foption, added in MySQL Cluster NDB 7.0.19 and MySQL Cluster NDB 7.1.8, forces the node to restart without checking for this. If this option is used and the result is an incomplete cluster, the entire cluster is restarted.
Displays status information for the data node identified by
node_id(or for all data nodes).
Beginning with MySQL Cluster NDB 6.2.8 and MySQL Cluster NDB 6.3.6, the output from this command indicates when the cluster is in single user mode.
Displays a report of type
report-typefor the data node identified by
node_id, or for all data nodes using
Currently, there are three accepted values for
BackupStatusprovides a status report on a cluster backup in progress
MemoryUsagedisplays how much data memory and index memory is being used by each data node as shown in this example:
ALL REPORT MEMORYNode 1: Data usage is 5%(177 32K pages of total 3200) Node 1: Index usage is 0%(108 8K pages of total 12832) Node 2: Data usage is 5%(177 32K pages of total 3200) Node 2: Index usage is 0%(108 8K pages of total 12832)
In MySQL Cluster NDB 7.1.1 and later, this information is also available from the
EventLogreports events from the event log buffers of one or more data nodes.
report-typeis case-insensitive and “fuzzy”; for
MemoryUsage, you can use
MEMORY(as shown in the prior example),
memory, or even simply
mem). You can abbreviate
BackupStatusin a similar fashion.
Prior to MySQL Cluster NDB 7.0.37 and MySQL Cluster NDB 7.1.26,
ALL REPORT BackupStatusdid not work correctly with multi-threaded data nodes. (Bug #15908907)
REPORTcommand was introduced in MySQL Cluster NDB 6.2.3 and MySQL Cluster NDB 6.3.0.
Enters single user mode, whereby only the MySQL server identified by the node ID
node_idis permitted to access the database.
Currently, it is not possible for data nodes to join a MySQL Cluster while it is running in single user mode. (Bug #20395)
Exits single user mode, enabling all SQL nodes (that is, all running mysqld processes) to access the database.Note
It is possible to use
EXIT SINGLE USER MODEeven when not in single user mode, although the command has no effect in this case.
Terminates the management client.
This command does not affect any nodes connected to the cluster.
This command does not shut down any SQL nodes or API nodes that are connected to the cluster.
Creates a new MySQL Cluster node group and causes data nodes to join it.
This command is used after adding new data nodes online to a MySQL Cluster, and causes them to join a new node group and thus to begin participating fully in the cluster. The command takes as its sole parameter a comma-separated list of node IDs—these are the IDs of the nodes just added and started that are to join the new node group. The number of nodes must be the same as the number of nodes in each node group that is already part of the cluster (each MySQL Cluster node group must have the same number of nodes). In other words, if the MySQL Cluster has 2 node groups of 2 data nodes each, then the new node group must also have 2 data nodes.
The node group ID of the new node group created by this command is determined automatically, and always the next highest unused node group ID in the cluster; it is not possible to set it manually.
This command was introduced in MySQL Cluster NDB 6.4.0. For more information, see Section 7.13, “Adding MySQL Cluster Data Nodes Online”.
Drops the MySQL Cluster node group with the given
This command can be used to drop a node group from a MySQL Cluster.
DROP NODEGROUPtakes as its sole argument the node group ID of the node group to be dropped.
DROP NODEGROUPacts only to remove the data nodes in the effected node group from that node group. It does not stop data nodes, assign them to a different node group, or remove them from the cluster's configuration. A data node that does not belong to a node group is indicated in the output of the management client
no nodegroupin place of the node group ID, like this (indicated using bold text):
id=3 @10.100.2.67 (5.1.77-ndb-7.1.37, no nodegroup)
Prior to MySQL Cluster NDB 7.0.4, the
SHOWoutput was not updated correctly following
DROP NODEGROUP. (Bug #43413)
DROP NODEGROUPworks only when all data nodes in the node group to be dropped are completely empty of any table data and table definitions. Since there is currently no way using ndb_mgm or the mysql client to remove all data from a specific data node or node group, this means that the command succeeds only in the two following cases:
TRUNCATE TABLEdoes not work for this purpose because this removes only the table data; the data nodes continue to store an
NDBCLUSTERtable's definition until a
DROP TABLEstatement is issued that causes the table metadata to be dropped.
DROP NODEGROUPwas introduced in MySQL Cluster NDB 6.4.0. For more information, see Section 7.13, “Adding MySQL Cluster Data Nodes Online”.
Additional commands. A number of other commands available in the ndb_mgm client are described elsewhere, as shown in the following list:
START BACKUPis used to perform an online backup in the ndb_mgm client; the
ABORT BACKUPcommand is used to cancel a backup already in progress. For more information, see Section 7.3, “Online Backup of MySQL Cluster”.
CLUSTERLOGcommand is used to perform various logging functions. See Section 7.6, “Event Reports Generated in MySQL Cluster”, for more information and examples.
For testing and diagnostics work, the client also supports a
DUMPcommand which can be used to execute internal commands on the cluster. It should never be used in a production setting unless directed to do so by MySQL Support. For more information, see MySQL Cluster Internals.
In older versions of MySQL Cluster (prior to MySQL 5.1.11), it could sometimes be necessary to force the management server to check connections to the data nodes to ensure that dropped connections were not missed. This could be done using the
PURGE STALE SESSIONScommand. Newer versions now perform this check automatically, so that the command is no longer needed. See Section 7.1, “Summary of MySQL Cluster Start Phases”, for more information.