Performing a Rolling Restart of an NDB Cluster Another common source of problems causing this condition is the blocking of TCP/IP ports needed for communications between cluster nodes. In the latter case, this is often due to a misconfigured firewall. For a system restart: For a node restart, find the tail of the redo log. After this process is completed for an initial start or system restart, transaction handling is enabled. For a node restart or initial node restart, completion of the startup process means that the node may now act as a transaction coordinator. This section discusses how to perform a  rolling restart  of an NDB Cluster installation, so called because it involves stopping and starting (or restarting) each node in turn, so that the cluster itself remains operational. This is often done as part of a  rolling upgrade  or  rolling downgrade , where high availability of the cluster is mandatory and no downtime of the cluster as a whole is permissible. Where we refer to upgrades, the information provided here also generally applies to downgrades as well. There are a number of reasons why a rolling restart might be desirable. These are described in the next few paragraphs. 23.5.5 Performing a Rolling Restart of an NDB Cluster 4476 • 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 . • 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 9.   The node internal startup variables are reset. • Phase 8.   If this is a system restart, all indexes are rebuilt (by  DBDIH ). • 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. • Phase 6.   In this phase, node groups are defined and set up. • Phase 5.   Most of the database-related portion of a data node start is performed 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. •Apply all redo information until the latest restorable global checkpoint has been reached. •Read data from the local checkpoint. •Read schema or schemas. • 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 . • 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 2.   The  NDBCNTR  kernel block checks the states of all existing nodes. The master node is chosen, and the cluster schema file is initialized.