- 6.5 MySQL Cluster Start Phases
- 6.5.1 Initialization Phase (Phase -1)
- 6.5.2 Configuration Read Phase (STTOR Phase -1)
- 6.5.3 STTOR Phase 0
- 6.5.4 STTOR Phase 1
- 6.5.5 STTOR Phase 2
- 6.5.6 NDB_STTOR Phase 1
- 6.5.7 STTOR Phase 3
- 6.5.8 NDB_STTOR Phase 2
- 6.5.9 STTOR Phase 4
- 6.5.10 NDB_STTOR Phase 3
- 6.5.11 STTOR Phase 5
- 6.5.12 NDB_STTOR Phase 4
- 6.5.13 NDB_STTOR Phase 5
- 6.5.14 NDB_STTOR Phase 6
- 6.5.15 STTOR Phase 6
- 6.5.16 STTOR Phase 7
- 6.5.17 STTOR Phase 8
- 6.5.18 NDB_STTOR Phase 7
- 6.5.19 STTOR Phase 9
- 6.5.20 STTOR Phase 101
- 6.5.21 System Restart Handling in Phase 4
- 6.5.22 START_MEREQ Handling
The only kernel block that participates in this phase to any
real effect is NDBCNTR.
In this phase NDBCNTR obtains the current
state of each configured cluster data node. Messages are sent to
NDBCNTR from QMGR
reporting the changes in status of any the nodes.
NDBCNTR also sets timers corresponding to the
StartPartialTimeout,
StartPartitionTimeout, and
StartFailureTimeout configuration parameters.
The next step is for a CNTR_START_REQ signal
to be sent to the proposed master node. Normally the president
is also chosen as master. However, during a system restart where
the starting node has a newer global checkpoint than that which
has survived on the president, then this node will take over as
master node, even though it is not recognized as the president
by QMGR. If the starting node is chosen as
the new master, then the other nodes are informed of this via a
CNTR_START_REF signal.
The master withholds the CNTR_START_REQ
signal until it is ready to start a new node, or to start the
cluster for an initial restart or system restart.
When the starting node receives
CNTR_START_CONF, it starts the
NDB_STTOR phases, in the following order:
DBLQH
DBDICT
DBTUP
DBACC
DBTC
DBDIH
