Author: jstephens
Date: 2007-06-28 13:03:36 +0200 (Thu, 28 Jun 2007)
New Revision: 6941
Log:
Another chunk of the 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 08:25:23 UTC (rev 6940)
+++ trunk/ndbapi/ndb-internals-start-phases.xml 2007-06-28 11:03:36 UTC (rev 6941)
Changed blocks: 1, Lines Added: 103, Lines Deleted: 1; 4020 bytes
@@ -523,14 +523,116 @@
the president.
</para>
+ <para>
+ As a final step, <literal>QMGR</literal> also starts the timer
+ handling for which it is responsible. This means that it generates
+ a signal to blocks that have requested it. This signal is sent 100
+ times per second even if any one instance of the signal is
+ delayed..
+ </para>
+
+ <para>
+ The <literal>BACKUP</literal> kernel block also begins sending a
+ signal periodically. This is to ensure that excessive amounts of
+ data are not written to disk, and that data writes are kept within
+ the limits of what has been specified in the cluster configuration
+ file during and after restarts. The <literal>DBUTIL</literal>
+ block initializes the transaction identity, and
+ <literal>DBTUX</literal> creates a reference to the
+ <literal>DBTUP</literal> block, while <literal>PGMAN</literal>
+ initialises pointers to the <literal>LGMAN</literal> and
+ <literal>DBTUP</literal> blocks. The <literal>RESTORE</literal>
+ kernel block creates references to the <literal>DBLQH</literal>
+ and <literal>DBTUP</literal> blocks to enable quick access to
+ those blocks when needed.
+ </para>
+
</section>
<section id="ndb-internals-start-phases-sttor-2">
<title><literal>STTOR</literal> Phase 2</title>
- <para></para>
+ <para>
+ The only kernel block that participates in this phase to any real
+ effect is <literal>NDBCNTR</literal>.
+ </para>
+ <para>
+ In this phase <literal>NDBCNTR</literal> obtains the current state
+ of each configured cluster data node. Messages are sent to
+ <literal>NDBCNTR</literal> from <literal>QMGR</literal> reporting
+ the changes in status of any the nodes. <literal>NDBCNTR</literal>
+ also sets timers corresponding to the
+ <literal>StartPartialTimeout</literal>,
+ <literal>StartPartitionTimeout</literal>, and
+ <literal>StartFailureTimeout</literal> configuration parameters.
+ </para>
+
+ <para>
+ The next step is for a <literal>CNTR_START_REQ</literal> signal to
+ be sent to the proposed master node. Normally the president is
+ also chosen as master. However, during a system restart where the
+ starting node has a newer global checkpoint than that which has
+ survived on the president, then this node will take over as master
+ node, even though it is not recognised as the president by
+ <literal>QMGR</literal>. If the starting node is chosen as the new
+ master, then the other nodes are informed of this via a
+ <literal>CNTR_START_REF</literal> signal.
+ </para>
+
+ <para>
+ The master withholds the <literal>CNTR_START_REQ</literal> signal
+ until it is ready to start a new node, or to start the cluster for
+ an initial restart or system restart.
+ </para>
+
+ <para>
+ When the starting node receives
+ <literal>CNTR_START_CONF</literal>, it starts the
+ <literal>NDB_STTOR</literal> phases, in the following order:
+
+ <orderedlist>
+
+ <listitem>
+ <para>
+ DBLQH
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ DBDICT
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ DBTUP
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ DBACC
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ DBTC
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ DBDIH
+ </para>
+ </listitem>
+
+ </orderedlist>
+ </para>
+
</section>
<section id="ndb-internals-start-phases-ndb-sttor-1">
| Thread |
|---|
| • svn commit - mysqldoc@docsrva: r6941 - trunk/ndbapi | jon | 28 Jun |
