Date: 2007-06-28 08:11:55 +0200 (Thu, 28 Jun 2007)
New Revision: 6939
More work on Start Phases doc.
--- trunk/ndbapi/ndb-internals-start-phases.xml 2007-06-27 23:24:02 UTC (rev 6938)
+++ trunk/ndbapi/ndb-internals-start-phases.xml 2007-06-28 06:11:55 UTC (rev 6939)
Changed blocks: 1, Lines Added: 114, Lines Deleted: 1; 6193 bytes
@@ -408,8 +408,121 @@
<title><literal>STTOR</literal> Phase 1</title>
+ This is one of the phases in which most kernel blocks participate
+ (see the table in
+ <xref linkend="ndb-internals-start-phases-sttor-0"/>). Otherwise,
+ most blocks are involved primarily in the initialization of data
+ — for example, this is all that <literal>DBTC</literal>
+ Many blocks initialize references to other blocks in Phase 1.
+ <literal>DBLQH</literal> initialises block references to
+ <literal>DBTUP</literal>, and <literal>DBACC</literal> initialises
+ block references to <literal>DBTUP</literal> and
+ <literal>DBLQH</literal>. <literal>DBTUP</literal> initialises
+ references to the blocks <literal>DBLQH</literal>,
+ <literal>TSMAN</literal>, and <literal>LGMAN</literal>.
+ <literal>NDBCNTR</literal> initialises some variables and sets up
+ block references to <literal>DBTUP</literal>,
+ <literal>DBLQH</literal>, <literal>DBACC</literal>,
+ <literal>DBTC</literal>, <literal>DBDIH</literal>, and
+ <literal>DBDICT</literal>; these are needed in the special
+ startphase handling of these blocks using
+ <literal>NDB_STTOR</literal> signals, where the bulk of the node
+ startup process actually takes place.
+ If the cluster is configured to lock pages (that is, if the
+ <literal>LockPagesInMainMemory</literal> configuration parameter
+ has been set), <literal>CMVMI</literal> handles this locking.
+ The <literal>QMGR</literal> block calls the
+ <literal>initData()</literal> method (defined in
+ whose output is handled by all other blocks in the
+ <literal>READ_CONFIG_REQ</literal> phase (see
+ <xref linkend="ndb-internals-start-phases-read-config"/>).
+ Following these initializations, <literal>QMGR</literal> sends the
+ <literal>DIH_RESTARTREQ</literal> signal to
+ <literal>DBDIH</literal>, which determines whether a proper system
+ file exists; if it does, an initial start is not being performed.
+ After the reception of this signal comes the process of
+ integrating the node among the other data nodes in the cluster,
+ where data nodes enter the cluster one at a time. The first one to
+ enter becomes the master; whenever the master dies the new master
+ is always the node that has been running for the longest time from
+ those remaining.
+ <literal>QMGR</literal> sets up timers to ensure that inclusion in
+ the cluster does not take longer than what the cluster's
+ configuration is set to allow (see
+ <link linkend="mysql-cluster-timeouts-intervals-disk-paging">Controlling
+ Timeouts, Intervals, and Disk Paging</link> for the relevant
+ configuration parameters), after which communication to all other
+ data nodes is established. At this point, a
+ <literal>CM_REGREQ</literal> signal is sent to all data nodes.
+ Only the president of the cluster responds to this signal; the
+ president allows one node at a time to enter the cluster. If no
+ node responds within 3 seconds then the president becomes the
+ master. If several nodes start up simultaneously, then the node
+ with the lowest node ID becomes president. The president sends
+ <literal>CM_REGCONF</literal> in response to this signal, but also
+ sends a <literal>CM_ADD</literal> singal to all nodes that are
+ currently alive.
+ Next, the starting node sends a <literal>CM_NODEINFOREQ</literal>
+ signal to all current <quote>live</quote> data nodes. When these
+ nodes receive that signal they send a
+ <literal>NODE_VERSION_REP</literal> signal to all API nodes that
+ have connected to them. Each data node also sends a
+ <literal>CM_ACKADD</literal> to the president to inform the
+ president that it has heard the <literal>CM_NODEINFOREQ</literal>
+ signal from the new node. Finally, each of the current data nodes
+ sends the <literal>CM_NODEINFOCONF</literal> signal in response to
+ the starting node. When the starting node has received all these
+ signals, it also sends the <literal>CM_ACKADD</literal> signal to
+ the president.
+ When the president has received all of the expected
+ <literal>CM_ACKADD</literal> signals, it knows that all data nodes
+ (including the newest one to start) have replied to the
+ <literal>CM_NODEINFOREQ</literal> signal. When the president
+ receives the final <literal>CM_ACKADD</literal>, it sends a
+ <literal>CM_ADD</literal> signal to all current data nodes (that
+ is, except for the node that just started). Upon receiving this
+ signal, the existing data nodes enable communication with the new
+ node; they begin sending heartbeats to it and including in the
+ list of neighbors used by the heartbeat protocol.
+ The <literal>start</literal> struct is reset, so that it can
+ handle new starting nodes, and then each data node sends a
+ <literal>CM_ACKADD</literal> to the president, which then sends a
+ <literal>CM_ADD</literal> to the starting node after all such
+ <literal>CM_ACKADD</literal> signals have been received. The new
+ node then opens all of its communication channels to the data
+ nodes that were already connected to the cluster; it also sets up
+ its own heartbeat structures and starts sending heartbeats. It
+ alsos send a <literal>CM_ACKADD</literal> message in response to
+ the president.
--- trunk/ndbapi/start-phases-tmp.txt 2007-06-27 23:24:02 UTC (rev 6938)
+++ trunk/ndbapi/start-phases-tmp.txt 2007-06-28 06:11:55 UTC (rev 6939)
Changed blocks: 2, Lines Added: 2, Lines Deleted: 2; 652 bytes
@@ -129,8 +129,6 @@
PGMAN: Phase 1,3,7 (Phase 7 currently empty)
RESTORE: Phase 1,3 (Only Phase 1 does any real work)
STTOR PHASE 1
@@ -194,6 +192,8 @@
sending heartbeats. It will also send a response message CM_ACKADD to
PROTOCOL TO INCLUDE STARTING NODE IN CLUSTER
[CHART GOES HERE when we have one that's legible]
|• svn commit - mysqldoc@docsrva: r6939 - trunk/ndbapi||jon||28 Jun|