- 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
In QMGR the president starts an arbitrator
(unless this feature has been disabled by setting the value of
the ArbitrationRank configuration parameter
to 0 for all nodes — see
Defining a MySQL Cluster Management Server, and
Defining SQL and Other API Nodes in a MySQL Cluster, for more
information; note that this currently can be done only when
using MySQL Cluster Carrier Grade Edition). In addition,
checking of API nodes through heartbeats is activated.
Also during this phase, the BACKUP block sets
the disk write speed to the value used following the completion
of the restart. The master node during initial start also
inserts the record keeping track of which backup ID is to be
used next. The SUMA and
DBTUX blocks set variables indicating start
phase 7 has been completed, and that requests to
DBTUX that occurs when running the redo log
should no longer be ignored.
