Most NDB kernel blocks begin their start
        phases at STTOR Phase 1, with the exception
        of NDBFS and
        NDBCNTR, which begin with
        Phase 0, as can be seen by inspecting the first value for each
        element in the ALL_BLOCKS array (defined in
        src/kernel/blocks/ndbcntr/NdbcntrMain.cpp).
        In addition, when the STTOR signal is sent to
        a block, the return signal STTORRY always
        contains a list of the start phases in which the block has an
        interest. Only in those start phases does the block actually
        receive a STTOR signal.
      
        STTOR signals are sent out in the order in
        which the kernel blocks are listed in the
        ALL_BLOCKS array. While
        NDBCNTR goes through start phases 0 to 255,
        most of these are empty.
      
        Both activities in Phase 0 have to do with initialization of the
        NDB file system. First, if necessary,
        NDBFS creates the file
        system directory for the data node. In the case of an initial
        start, NDBCNTR clears any
        existing files from the directory of the data node to ensure
        that the DBDIH block does
        not subsequently discover any system files (if
        DBDIH were to find any system files, it would
        not interpret the start correctly as an initial start).
      
        Each time that NDBCNTR completes the sending
        of one start phase to all kernel blocks, it sends a
        NODE_STATE_REP signal to all blocks, which
        effectively updates the NodeState in all
        blocks.
      
        Each time that NDBCNTR completes a nonempty
        start phase, it reports this to the management server; in most
        cases this is recorded in the cluster log.
      
        Finally, after completing all start phases,
        NDBCNTR updates the node state in all blocks
        using a NODE_STATE_REP signal; it also sends
        an event report advising that all start phases are complete. In
        addition, all other cluster data nodes are notified that this
        node has completed all its start phases to ensure all nodes are
        aware of one another's state. Each data node sends a
        NODE_START_REP to all blocks; however, this
        is significant only for
        DBDIH, so that it knows when
        it can unlock the lock for schema changes on
        DBDICT.
      
          In the following table, and throughout this text, we sometimes
          refer to STTOR start phases simply as
          “start phases” or “Phase
          N” (where
          N is some number).
          NDB_STTOR start phases are always qualified
          as such, and so referred to as
          “NDB_STTOR start phases” or
          “NDB_STTOR phases”.
        
Table 5.1 NDB kernel blocks and start phases
| Kernel Block | Receptive Start Phases | 
|---|---|
NDBFS | 
            0 | 
DBTC | 
            1 | 
DBDIH | 
            1 | 
DBLQH | 
            1, 4 | 
DBACC | 
            1 | 
DBTUP | 
            1 | 
DBDICT | 
            1, 3 | 
NDBCNTR | 
            0, 1, 2, 3, 4, 5, 6, 8, 9 | 
CMVMI | 
            1 (prior to QMGR), 3, 8 | 
          
QMGR | 
            1, 7 | 
TRIX | 
            1 | 
BACKUP | 
            1, 3, 7 | 
DBUTIL | 
            1, 6 | 
SUMA | 
            1, 3, 5, 7, 100 (empty), 101 | 
DBTUX | 
            1,3,7 | 
TSMAN | 
            1, 3 (both ignored) | 
LGMAN | 
            1, 2, 3, 4, 5, 6 (all ignored) | 
PGMAN | 
            1, 3, 7 (Phase 7 currently empty) | 
RESTORE | 
            1,3 (only in Phase 1 is any real work done) | 
This table was current at the time this text was written, but is likely to change over time. The latest information can be found in the source code.