Initial Start.  The cluster starts with a clean filesystem on all data nodes. This occurs either when the cluster started for the very first time, or when it is restarted using the --initial option.

System Restart.  The cluster starts and reads data stored in the data nodes. This occurs when the cluster has been shut down after having been in use, when it is desired for the cluster to resume operations from the point where it left off.

Node Restart.  This is the online restart of a cluster node while the cluster itself is running.

Initial Node Restart.  This is the same as a node restart, except that the node is reinitialized and started with a clean filesystem.

Phase 0.  The NDBFS and NDBCNTR blocks start (see NDB Kernel Blocks). The cluster filesystem is cleared, if the cluster was started with the --initial option.

Phase 1.  In this stage, all remaining NDB kernel blocks are started. Cluster connections are set up, inter-block communications are established, and Cluster heartbeats are started. In the case of a node restart, API node connections are also checked.

Phase 2.  The NDBCNTR kernel block checks the states of all existing nodes. The master node is chosen, and the cluster schema file is initialized.

Phase 3.  The DBLQH and DBTC kernel blocks set up communications between them. The startup type is determined; if this is a restart, the DBDIH block obtains permission to perform the restart.

Phase 4.  For an initial start or initial node restart, the redo log files are created. The number of these files is equal to NoOfFragmentLogFiles.

For a system restart:

For a node restart, find the tail of the redo log.

Phase 5.  Most of the database-related portion of a data node start is perfomed during this phase. For an initial start or system restart, a local checkpoint is executed, followed by a global checkpoint. Periodic checks of memory usage begin during this phase, and any required node takeovers are performed.

Phase 6.  In this phase, node groups are defined and set up.

Phase 7.  The arbitrator node is selected and begins to function. The next backup ID is set, as is the backup disk write speed. Nodes reaching this start phase are marked as Started. It is now possible for API nodes (including SQL nodes) to connect to the cluster. connect.

Phase 8.  If this is a system restart, all indexes are rebuilt (by DBDIH).

Phase 9.  The node internal startup variables are reset.

Phase 100 (OBSOLETE).  Formerly, it was at this point during a node restart or initial node restart that API nodes could connect to the node and begin to receive events. Currently, this phase is empty.

Phase 101.  At this point in a node restart or initial node restart, event delivery is handed over to the node joining the cluster. The newly-joined node takes over responsibility for delivering its primary data to subscribers. This phase is also referred to as SUMA handover phase.

HELP

Displays information on all available commands.

SHOW

Displays information on the cluster's status.

Note: In a cluster where multiple management nodes are in use, this command displays information only for data nodes that are actually connected to the current management server.

node_id START

Brings online the data node identified by node_id (or all data nodes).

Beginning with MySQL 5.0.19, this command can also be used to individual management nodes online. Note: ALL START continues to affect data nodes only.

Important: To use this command to bring a data node online, the data node must have been started using ndbd --nostart or ndbd -n.

node_id STOP

Stops the data node identified by node_id (or all data nodes).

Beginning with MySQL 5.0.19, this command can also be used to stop individual management nodes. Note: ALL STOP continues to affect data nodes only.

A node affected by this command disconnects from the cluster, and its associated ndbd or ndb_mgmd process terminates.

node_id RESTART [-n] [-i] [-a]

Restarts the data node identified by node_id (or all data nodes).

Using the -i option with RESTART causes the data node to perform an initial restart; that is, the node's filesystem 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 --initial from the system shell.

Using the -n option causes the data node process to be restarted, but the data node is not actually brought online until the appropriate START command 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 --nostart or ndbd -n from the system shell.

Using the -a causes all current transactions relying on this node to be aborted. No GCP check is done when the node rejoins the cluster.

node_id STATUS

Displays status information for the data node identified by node_id (or for all data nodes).

ENTER SINGLE USER MODE node_id

Enters single user mode, whereby only the MySQL server identified by the node ID node_id is allowed to access the database.

Important: Do not attempt to have data nodes join the cluster while it is running in single user mode. Doing so can cause subsequent multiple node failures. Beginning with MySQL 5.1.12, it is no longer possible to add nodes while in single user mode. (See Bug#20395 for more information.)

EXIT SINGLE USER MODE

Exits single user mode, allowing all SQL nodes (that is, all running mysqld processes) to access the database.

QUIT, EXIT

Terminates the management client.

This command does not affect any nodes connected to the cluster.

SHUTDOWN

Shuts down all cluster data nodes and management nodes. To exit the management client after this has been done, use EXIT or QUIT.

This command does not shut down any SQL nodes or API nodes that are connected to the cluster.

The cluster log, which includes events generated by all cluster nodes. The cluster log is the log recommended for most uses because it provides logging information for an entire cluster in a single location.

By default, the cluster log is saved to a file named ndb_node_id_cluster.log, (where node_id is the node ID of the management server) in the same directory where the ndb_mgm binary resides.

Cluster logging information can also be sent to stdout or a syslog facility in addition to or instead of being saved to a file, as determined by the values set for the DataDir and LogDestination configuration parameters. See Section 15.3.4.4, “Defining the Management Server”, for more information about these parameters.

Node logs are local to each node.

Output generated by node event logging is written to the file ndb_node_id_out.log (where node_id is the node's node ID) in the node's DataDir. Node event logs are generated for both management nodes and data nodes.

Node logs are intended to be used only during application development, or for debugging application code.

Category: This can be any one of the following values: STARTUP, SHUTDOWN, STATISTICS, CHECKPOINT, NODERESTART, CONNECTION, ERROR, or INFO.

Priority: This is represented by one of the numbers from 1 to 15 inclusive, where 1 indicates “most important” and 15 “least important.”

Severity Level: This can be any one of the following values: ALERT, CRITICAL, ERROR, WARNING, INFO, or DEBUG.

A timestamp in YYYY-MM-DD HH:MM:SS format.

The type of node which is performing the logging. In the cluster log, this is always [MgmSrvr].

The severity of the event.

The ID of the node reporting the event.

A description of the event. The most common types of events to appear in the log are connections and disconnections between different nodes in the cluster, and when checkpoints occur. In some cases, the description may contain status information.

Method 1:

Method 2:

Restart database nodes prior to entering single user mode.

SHOW ENGINE NDB STATUS, SHOW ENGINE NDBCLUSTER STATUS

The output of this statement contains information about the server's connection to the cluster, creation and usage of MySQL Cluster objects, and binary logging for MySQL Cluster replication.

See Section 13.5.4.9, “SHOW ENGINE Syntax”, for a usage example and more detailed information.

SHOW ENGINES [LIKE 'NDB%']

This statement can be used to determine whether or not clustering support is enabled in the MySQL server, and if so, whether it is active.

See Section 13.5.4.10, “SHOW ENGINES Syntax”, for more detailed information.

SHOW VARIABLES LIKE 'NDB%'

This statement provides a list of most server system variables relating to the NDB storage engine, and their values, as shown here:

mysql> SHOW VARIABLES LIKE 'NDB%';
+-------------------------------------+-------+
| Variable_name                       | Value |
+-------------------------------------+-------+
| ndb_autoincrement_prefetch_sz       | 32    |
| ndb_cache_check_time                | 0     |
| ndb_extra_logging                   | 0     |
| ndb_force_send                      | ON    |
| ndb_index_stat_cache_entries        | 32    |
| ndb_index_stat_enable               | OFF   |
| ndb_index_stat_update_freq          | 20    |
| ndb_report_thresh_binlog_epoch_slip | 3     |
| ndb_report_thresh_binlog_mem_usage  | 10    |
| ndb_use_copying_alter_table         | OFF   |
| ndb_use_exact_count                 | ON    |
| ndb_use_transactions                | ON    |
+-------------------------------------+-------+

See Section 5.2.3, “System Variables”, for more information.

SHOW STATUS LIKE 'NDB%'

This statement shows at a glance whether or not the MySQL server is acting as a cluster SQL node, and if so, it provides the MySQL server's cluster node ID, the hostname and port for the cluster management server to which it is connected, and the number of data nodes in the cluster, as shown here:

mysql> SHOW STATUS LIKE 'NDB%';
+--------------------------+---------------+
| Variable_name            | Value         |
+--------------------------+---------------+
| Ndb_cluster_node_id      | 10            |
| Ndb_config_from_host     | 192.168.0.103 |
| Ndb_config_from_port     | 1186          |
| Ndb_number_of_data_nodes | 4             |
+--------------------------+---------------+

If the MySQL server was built with clustering support, but it is not connected to a cluster, all rows in the output of this statement contain a zero or an empty string:

mysql> SHOW STATUS LIKE 'NDB%';
+--------------------------+-------+
| Variable_name            | Value |
+--------------------------+-------+
| Ndb_cluster_node_id      | 0     |
| Ndb_config_from_host     |       |
| Ndb_config_from_port     | 0     |
| Ndb_number_of_data_nodes | 0     |
+--------------------------+-------+

See also Section 13.5.4.23, “SHOW STATUS Syntax”.