Author: jstephens
Date: 2007-06-28 18:25:40 +0200 (Thu, 28 Jun 2007)
New Revision: 6942
Log:
More of the Start Phases doc (committing and taking a break)
Modified:
trunk/ndbapi/ndb-internals-start-phases.xml
Modified: trunk/ndbapi/ndb-internals-start-phases.xml
===================================================================
--- trunk/ndbapi/ndb-internals-start-phases.xml 2007-06-28 11:03:36 UTC (rev 6941)
+++ trunk/ndbapi/ndb-internals-start-phases.xml 2007-06-28 16:25:40 UTC (rev 6942)
Changed blocks: 4, Lines Added: 154, Lines Deleted: 5; 7758 bytes
@@ -639,7 +639,13 @@
<title><literal>NDB_STTOR</literal> Phase 1</title>
- <para></para>
+ <para>
+ <literal>DBDICT</literal>, if necessary, initializes the schema
+ file. <literal>DBIDH</literal>, <literal>DBTC</literal>,
+ <literal>DBTUP</literal>, and <literal>DBLQH</literal> initialize
+ variables. <literal>DBLQH</literal> also initializes the sending
+ of statistics on database operations.
+ </para>
</section>
@@ -647,23 +653,91 @@
<title><literal>STTOR</literal> Phase 3</title>
- <para></para>
+ <para>
+ <literal>DBDICT</literal> initialises a variable that keeps track
+ of the type of restart being performed.
+ </para>
+ <para>
+ <literal>NDBCNTR</literal> executes phase 2 of the
+ <literal>NDB_STTOR</literal> startphases, with no other
+ <literal>NDBCNTR</literal> activity taking place during this
+ <literal>STTOR</literal> phase.
+ </para>
+
</section>
<section id="ndb-internals-start-phases-ndb-sttor-2">
<title><literal>NDB_STTOR</literal> Phase 2</title>
- <para></para>
+ <para>
+ The <literal>DBLQH</literal> block enables its exchange of
+ internal records with <literal>DBTUP</literal> and
+ <literal>DBACC</literal>, while <literal>DBTC</literal> allows its
+ internal records to be exchanged with <literal>DBDIH</literal>.
+ The <literal>DBDIH</literal> kernel block creates the mutexes used
+ by the <literal>NDB</literal> kernel and reads nodes using the
+ <literal>READ_NODESREQ</literal> signal. With the data from the
+ response to this signal, <literal>DBDIH</literal> can create node
+ lists, node groups, and so forth. For node restarts and initial
+ node restarts, <literal>DBDIH</literal> also asks the master for
+ permission to perform the restart. The master will ask all
+ <quote>live</quote> nodes if they are prepared to permit the new
+ node to join the cluster. If an initial node restart is to be
+ performed, then all LCPs are invalidated as part of this phase.
+ </para>
+ <para>
+ LCPs from nodes that are not part of the cluster at the time of
+ the initial node restart are not invalidated. The reason for this
+ is that there is never any chance for a node to become master of a
+ system restart using any of the LCPs that have been invalidated,
+ since this node must complete a node restart — including a
+ local checkpoint — before it can join the cluster and
+ possibly become a master node.
+ </para>
+
+ <para>
+ The <literal>CMVMI</literal> kernel block activates the sending of
+ packed signals, which occurs only as part of database operations.
+ Packing must be enabled prior to beginning any such operations
+ during the execution of the redo log or node recovery phases.
+ </para>
+
+ <para>
+ The <literal>DBTUX</literal> block sets the type of start
+ currently taking place, while the <literal>BACKUP</literal> block
+ sets the type of restart to be performed, if any (in each case,
+ the block actually sets a variable whose value reflects the type
+ of start or restart). The <literal>SUMA</literal> block remains
+ inactive during this phase.
+ </para>
+
+ <para>
+ The <literal>PGMAN</literal> kernel block starts the generation of
+ two repeated signals, the first handles cleanup. This signal is
+ sent every 200 milliseconds. The other signal handles statistics,
+ and is sent once per second.
+ </para>
+
</section>
<section id="ndb-internals-start-phases-sttor-4">
<title><literal>STTOR</literal> Phase 4</title>
- <para></para>
+ <para>
+ Only the <literal>DBLQH</literal> and <literal>NDBCNTR</literal>
+ kernel blocks are directly involved in this phase.
+ <literal>DBLQH</literal> allocates a record in the
+ <literal>BACKUP</literal> block, used in the execution of local
+ checkpoints via the <literal>DEFINE_BACKUP_REQ</literal> signal.
+ <literal>NDBCNTR</literal> causes <literal>NDB_STTOR</literal> to
+ execute NDB_STTOR phase 3; there is otherwise no other
+ <literal>NDBCNTR</literal> activity during this
+ <literal>STTOR</literal> phase.
+ </para>
</section>
@@ -671,8 +745,75 @@
<title><literal>NDB_STTOR</literal> Phase 3</title>
- <para></para>
+ <para>
+ The <literal>DBLQH</literal> block initiates checking of the log
+ files here. Then it obtains the states of the data nodes using the
+ <literal>READ_NODESREQ</literal> signal. Unless an initial start
+ or an initial node restart is being performed, the checking of log
+ files is handled in parallel with a number of other start phases.
+ For initial starts, the log files must be initialised; this can be
+ a lengthy process and should have some progress status attached to
+ it.
+ </para>
+ <note>
+ <para>
+ From this point, there are two parallel paths, one continuing
+ restart and another reading and determining the state of the
+ redo log files.
+ </para>
+ </note>
+
+ <para>
+ The <literal>DBDICT</literal> block requests information about the
+ cluster data nodes via the <literal>READ_NODESREQ</literal>
+ signal. <literal>DBACC</literal> resets the system restart flag if
+ this is not a system restart; this is used only to verify that no
+ requests are received from <literal>DBTUX</literal> during system
+ restart. <literal>DBTC</literal> requests information about all
+ nodes by means of the <literal>READ_NODESREQ</literal> signal.
+ </para>
+
+ <para>
+ <literal>DBDIH</literal> sets an internal master state and makes
+ other preparations exclusive to initial starts. In the case of an
+ initial start, the non-master nodes perform some initial tasks,
+ the master node doing once all non-master nodes have reported that
+ their tasks are completed. (This delay is actually unnecessary
+ since there is no reason to wait while initializing the master
+ node.)
+ </para>
+
+<!-- STOP POINT -->
+
+ <para>
+ For node restarts and initial node restarts no more work is done
+ in this phase. For initial starts the work is done when all nodes
+ have created the initial restart information and initialised the
+ system file.
+ </para>
+
+ <para>
+ For system restarts this is where most of the work is performed
+ activated by sending the NDB_STARTREQ signal from NDBCNTR to DBDIH
+ in the master. This signal is sent when all nodes in the system
+ restart have reached to this point in the restart. Thus we first
+ have a synchronisation point. For a description of the system
+ restart version of phase 4, see
+ <xref linkend="ndb-internals-start-phases-system-restart-phase-4"/>.
+ </para>
+
+ <para>
+ SYNCHRONISATION POINT for system restarts: WAITPOINT_4_1
+ </para>
+
+ <para>
+ After completing execution of the NDB_STARTREQ signal the master
+ will send CNTR_WAITREP with WAITPOINT_4_2 to all nodes, this will
+ end the NDB_STTOR phase 3 and will also be last activity in
+ startphase 4.
+ </para>
+
</section>
<section id="ndb-internals-start-phases-sttor-5">
@@ -755,4 +896,12 @@
</section>
+ <section id="ndb-internals-start-phases-system-restart-phase-4">
+
+ <title>System Restart Handling in Phase 4</title>
+
+ <para></para>
+
+ </section>
+
</section>
| Thread |
|---|
| • svn commit - mysqldoc@docsrva: r6942 - trunk/ndbapi | jon | 28 Jun |
