Oracle 5.0 Reference Manual page 1674

This section provides a simplified outline of the steps involved when MySQL Cluster data nodes are
started. More complete information can be found in
These phases are the same as those reported in the output from the
the management client. (See
for more information about this command.)
Start types. There are several different startup types and modes, as shown here:
• Initial Start. The cluster starts with a clean file system on all data nodes. This occurs either when
the cluster started for the very first time, or when all data nodes are restarted using the
option.
Note
Disk Data files are not removed when restarting a node using --initial.
• System Restart.
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.
started with a clean file system.
Setup and initialization (Phase -1).
initialized. Initialization consists of the following steps:
1. Obtain a node ID
2. Fetch configuration data
3. Allocate ports to be used for inter-node communications
4. Allocate memory according to settings obtained from the configuration file
When a data node or SQL node first connects to the management node, it reserves a cluster node
ID. To make sure that no other node allocates the same node ID, this ID is retained until the node has
managed to connect to the cluster and at least one
retention of the node ID is guarded by the connection between the node in question and ndb_mgmd.
Normally, in the event of a problem with the node, the node disconnects from the management server,
the socket used for the connection is closed, and the reserved node ID is freed. However, if a node is
disconnected abruptly—for example, due to a hardware failure in one of the cluster hosts, or because
of network issues—the normal closing of the socket by the operating system may not take place. In
this case, the node ID continues to be reserved and not released until a TCP timeout occurs 10 or so
minutes later.
To take care of this problem, you can use
all reserved node IDs to be checked; any that are not being used by nodes actually connected to the
cluster are then freed.
Beginning with MySQL 5.1.11, timeout handling of node ID assignments is implemented. This performs
the ID usage checks automatically after approximately 20 seconds, so that
should no longer be necessary in a normal Cluster start.
After each data node has been initialized, the cluster startup process can proceed. The stages which
the cluster goes through during this process are listed here:
Summary of MySQL Cluster Start Phases
Section 17.5.2, "Commands in the MySQL Cluster Management
The cluster starts and reads data stored in the data nodes. This occurs when
This is the same as a node restart, except that the node is reinitialized and
Prior to startup, each data node
PURGE STALE
1654
MySQL Cluster Start Phases.
node_id STATUS
(ndbd
reports that this node is connected. This
ndbd
SESSIONS. Running this statement forces
command in
Client",
--initial
process) must be
PURGE STALE SESSIONS