Author: jstephens
Date: 2007-06-29 14:21:15 +0200 (Fri, 29 Jun 2007)
New Revision: 6951
Log:
Remainder of Start Phases doc.
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 23:02:31 UTC (rev 6950)
+++ trunk/ndbapi/ndb-internals-start-phases.xml 2007-06-29 12:21:15 UTC (rev 6951)
Changed blocks: 5, Lines Added: 202, Lines Deleted: 8; 9350 bytes
@@ -1127,14 +1127,15 @@
</para>
</section>
-
-<!-- STOP POINT -->
<section id="ndb-internals-start-phases-sttor-8">
<title><literal>STTOR</literal> Phase 8</title>
- <para></para>
+ <para>
+ <literal>NDB_STTOR</literal> executes <literal>NDB_STTOR</literal>
+ phase 7; no other <literal>NDBCNTR</literal> activity takes place.
+ </para>
</section>
@@ -1142,15 +1143,27 @@
<title><literal>NDB_STTOR</literal> Phase 7</title>
- <para></para>
+ <para>
+ If this is a system restart, the master node initiates a rebuild
+ of all indexes from <literal>DBDICT</literal> during this phase.
+ </para>
+ <para>
+ The <literal>CMVMI</literal> kernel block opens communication
+ channels to the API nodes (including MySQL servers acting as SQL
+ nodes). Indicate in <literal>globalData</literal> that the node is
+ started.
+ </para>
+
</section>
<section id="ndb-internals-start-phases-sttor-9">
<title><literal>STTOR</literal> Phase 9</title>
- <para></para>
+ <para>
+ <literal>NDBCNTR</literal> resets some start variables.
+ </para>
</section>
@@ -1158,7 +1171,9 @@
<title><literal>STTOR</literal> Phase 101</title>
- <para></para>
+ <para>
+ This is the <literal>SUMA</literal> handover phase.
+ </para>
</section>
@@ -1166,8 +1181,158 @@
<title>System Restart Handling in Phase 4</title>
- <para></para>
+ <para>
+ This consists of the following steps:
+ <orderedlist>
+
+ <listitem>
+ <para>
+ The master sets the latest GCI as the restart GCI, and then
+ synchronizes its system file to all other nodes involved in
+ the system restart.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ The next step is to synchronize the schema of all the nodes
+ in the system restart. This is performed in 15 passes. The
+ problem we are trying to solve here occurs when a schema
+ object has been created while the node was up but was
+ dropped while the node was down, and possibly a new object
+ was even created with the same schema ID while that node was
+ unavailable. In order to handle this situation, it is
+ necessary first to re-create all objects that are supposed
+ to exist from the viewpoint of the starting node. After
+ this, any objects that were dropped by other nodes in the
+ cluster while this node was <quote>dead</quote> are dropped;
+ this also applies to any tables that were dropped during the
+ outage. Finally, any tables that have been created by other
+ nodes while the starting node was unavailable are re-created
+ on the starting node. All these operations are local to the
+ starting node. As part of this process, is it also necessary
+ to ensure that all tables that need to be re-created have
+ been created locally and that the proper data structures
+ have been set up for them in all kernel blocks.
+ </para>
+
+ <para>
+ After performing the procedure described previously for the
+ master node the new schema file is sent to all other
+ participants in the system restart, and they perform the
+ same synchronization.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ All fragments involved in the restart must have proper
+ parameters as derived from <literal>DBDIH</literal>. This
+ causes a number of <literal>START_FRAGREQ</literal> signals
+ to be sent from <literal>DBDIH</literal> to
+ <literal>DBLQH</literal>. This also starts the restoration
+ of the fragments, which are restored one by one and one
+ record at a time in the course of reading the restore data
+ from disk and applying in parallel the restore data read
+ from disk into main memory. This restores only the main
+ memory parts of the tables.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ Once all fragments have been restored, a
+ <literal>START_RECREQ</literal> message is sent to all nodes
+ in the starting cluster, and then all undo logs for any Disk
+ Data parts of the tables are applied.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ After applying the undo logs in <literal>LGMAN</literal>, it
+ is necessary to perform some restore work in
+ <literal>TSMAN</literal> that requires scanning the extent
+ headers of the tablespaces.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ Next, it is necessary to prepare for execution of the redo
+ log, which log can be performed in up to four phases. For
+ each fragment, execution of redo logs from several different
+ nodes may be required. This is handled by executing the redo
+ logs in different phases for a specific fragment, as decided
+ in <literal>DBDIH</literal> when sending the
+ <literal>START_FRAGREQ</literal> signal. An
+ <literal>EXEC_FRAGREQ</literal> signal is sent for each
+ phase and fragment that requires execution in this phase.
+ After these signals are sent, an
+ <literal>EXEC_SRREQ</literal> signal is sent to all nodes to
+ tell them that they can start executing the redo log.
+
+ <note>
+ <para>
+ Before starting execution of the first redo log, it is
+ necessary to make sure that the setup which was started
+ earlier (in Phase 4) by <literal>DBLQH</literal> has
+ finished, or to wait until it does before continuing.
+ </para>
+ </note>
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ Prior to executing the redo log, it is necessary to
+ calculate where to start reading and where the end of the
+ REDO log should have been reached. The end of the REDO log
+ should be found when the last GCI to restore has been
+ reached.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ After completing the execution of the redo logs, all redo
+ log pages that have been written beyond the last GCI to be
+ restore are invalidated. Given the cyclic nature of the redo
+ logs, this could carry the invalidation into new redo log
+ files past the last one executed.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ After the completion of the previous step,
+ <literal>DBLQH</literal> report this back to
+ <literal>DBDIH</literal> using a
+ <literal>START_RECCONF</literal> message.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ When the master has received this message back from all
+ starting nodes, it sends a <literal>NDB_STARTCONF</literal>
+ signal back to <literal>NDBCNTR</literal>.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ The <literal>NDB_STARTCONF</literal> message signals the end
+ of <literal>STTOR</literal> phase 4 to
+ <literal>NDBCNTR</literal>, which is the only block involved
+ to any significant degree in this phase.
+ </para>
+ </listitem>
+
+ </orderedlist>
+ </para>
+
</section>
<!--
@@ -1188,8 +1353,37 @@
<title>START_MEREQ Handling</title>
- <para></para>
+ <para>
+ The first step in handling <literal>START_MEREQ</literal> is to
+ ensure that no local checkpoint is currently taking place;
+ otherwise, it is necessary to wait until it is completed. The next
+ step is to copy all distribution information from the master
+ <literal>DBDIH</literal> to the starting <literal>DBDIH</literal>.
+ After this, all metadata is synchronised in
+ <literal>DBDICT</literal> (see
+ <xref linkend="ndb-internals-start-phases-system-restart-phase-4"/>).
+ </para>
+ <para>
+ After blocking local checkpoints, and then synchronising
+ distribution information and metadata information, global
+ checkpoints are blocked.
+ </para>
+
+ <para>
+ The next step is to integrate the starting node in the global
+ checkpoint protocol, local checkpoint protocol, and all other
+ distributed protocols. As part of this the node status is also
+ updated.
+ </para>
+
+ <para>
+ After completing this step the global checkpoint protocol is
+ permitted to start again, the <literal>START_MECONF</literal>
+ signal is sent to indicate to the starting node that the next
+ phase may proceed.
+ </para>
+
</section>
</section>
| Thread |
|---|
| • svn commit - mysqldoc@docsrva: r6951 - trunk/ndbapi | jon | 29 Jun |
