svn commit - mysqldoc@docsrva: r6939 - trunk/ndbapi

[jon]

Author: jstephens
Date: 2007-06-28 08:11:55 +0200 (Thu, 28 Jun 2007)
New Revision: 6939

Log:

More work on Start Phases doc.



Modified:
   trunk/ndbapi/ndb-internals-start-phases.xml
   trunk/ndbapi/start-phases-tmp.txt


Modified: trunk/ndbapi/ndb-internals-start-phases.xml
===================================================================
--- 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>
 
-    <para></para>
+    <para>
+      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
+      &mdash; for example, this is all that <literal>DBTC</literal>
+      does.
+    </para>
 
+    <para>
+      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>.
+    </para>
+
+    <para>
+      <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.
+    </para>
+
+    <para>
+      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.
+    </para>
+
+    <para>
+      The <literal>QMGR</literal> block calls the
+      <literal>initData()</literal> method (defined in
+      <filename>storage/ndb/src/kernel/blocks/qmgr/QmgrMain.cpp</filename>)
+      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.
+    </para>
+
+    <para>
+      <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.
+    </para>
+
+    <para>
+      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.
+    </para>
+
+    <para>
+      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.
+    </para>
+
+    <para>
+      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.
+    </para>
+
   </section>
 
   <section id="ndb-internals-start-phases-sttor-2">


Modified: trunk/ndbapi/start-phases-tmp.txt
===================================================================
--- 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)
 
-[***STOP POINT***]
-
 STTOR PHASE 1
 -----------------------
 

@@ -194,6 +192,8 @@
 sending heartbeats. It will also send a response message CM_ACKADD to
 the president.
 
+[***STOP POINT***]
+
 PROTOCOL TO INCLUDE STARTING NODE IN CLUSTER
 
 [CHART GOES HERE when we have one that's legible]