List:Commits« Previous MessageNext Message »
From:jon.stephens Date:April 11 2011 4:31pm
Subject:svn commit - mysqldoc@oter02: r25828 - in trunk: refman-5.0 refman-5.1
View as plain text  
Author: js221926
Date: 2011-04-11 18:31:37 +0200 (Mon, 11 Apr 2011)
New Revision: 25828

Log:


De-gunking



Modified:
   trunk/refman-5.0/mysql-cluster-management.xml
   trunk/refman-5.1/mysql-cluster-management.xml


Modified: trunk/refman-5.0/mysql-cluster-management.xml
===================================================================
--- trunk/refman-5.0/mysql-cluster-management.xml	2011-04-11 15:58:04 UTC (rev 25827)
+++ trunk/refman-5.0/mysql-cluster-management.xml	2011-04-11 16:31:37 UTC (rev 25828)
Changed blocks: 28, Lines Added: 1110, Lines Deleted: 1102; 100789 bytes

@@ -97,78 +97,77 @@
       <para>
         There are several different startup types and modes, as shown
         here:
+      </para>
 
-        <itemizedlist>
+    </formalpara>
 
-          <listitem>
-            <formalpara>
+    <itemizedlist>
 
-              <title>Initial Start</title>
+      <listitem>
+        <formalpara>
 
+          <title>Initial Start</title>
+
+          <para>
+            The cluster starts with a clean file system on all data
+            nodes. This occurs either when the cluster started for the
+            very first time, or when all data nodes are restarted using
+            the <option>--initial</option> option.
+
+            <note>
               <para>
-                The cluster starts with a clean file system on all data
-                nodes. This occurs either when the cluster started for
-                the very first time, or when all data nodes are
-                restarted using the <option>--initial</option> option.
-
-                <note>
-                  <para>
-                    Disk Data files are not removed when restarting a
-                    node using <option>--initial</option>.
-                  </para>
-                </note>
+                Disk Data files are not removed when restarting a node
+                using <option>--initial</option>.
               </para>
+            </note>
+          </para>
 
-            </formalpara>
-          </listitem>
+        </formalpara>
+      </listitem>
 
-          <listitem>
-            <formalpara>
+      <listitem>
+        <formalpara>
 
-              <title>System Restart</title>
+          <title>System Restart</title>
 
-              <para>
-                The cluster starts and reads data stored in the data
-                nodes. This occurs when the cluster has been shut down
-                after having been in use, when it is desired for the
-                cluster to resume operations from the point where it
-                left off.
-              </para>
+          <para>
+            The cluster starts and reads data stored in the data nodes.
+            This occurs when the cluster has been shut down after having
+            been in use, when it is desired for the cluster to resume
+            operations from the point where it left off.
+          </para>
 
-            </formalpara>
-          </listitem>
+        </formalpara>
+      </listitem>
 
-          <listitem>
-            <formalpara>
+      <listitem>
+        <formalpara>
 
-              <title>Node Restart</title>
+          <title>Node Restart</title>
 
-              <para>
-                This is the online restart of a cluster node while the
-                cluster itself is running.
-              </para>
+          <para>
+            This is the online restart of a cluster node while the
+            cluster itself is running.
+          </para>
 
-            </formalpara>
-          </listitem>
+        </formalpara>
+      </listitem>
 
-          <listitem>
-            <formalpara>
+      <listitem>
+        <formalpara>
 
-              <title>Initial Node Restart</title>
+          <title>Initial Node Restart</title>
 
-              <para>
-                This is the same as a node restart, except that the node
-                is reinitialized and started with a clean file system.
-              </para>
+          <para>
+            This is the same as a node restart, except that the node is
+            reinitialized and started with a clean file system.
+          </para>
 
-            </formalpara>
-          </listitem>
+        </formalpara>
+      </listitem>
 
-        </itemizedlist>
-      </para>
+    </itemizedlist>
 
-    </formalpara>
-
     <formalpara>
 
       <title>Setup and initialization (Phase -1)</title>

@@ -177,38 +176,38 @@
         Prior to startup, each data node (<command>ndbd</command>
         process) must be initialized. Initialization consists of the
         following steps:
+      </para>
 
-        <orderedlist>
+    </formalpara>
 
-          <listitem>
-            <para>
-              Obtain a node ID
-            </para>
-          </listitem>
+    <orderedlist>
 
-          <listitem>
-            <para>
-              Fetch configuration data
-            </para>
-          </listitem>
+      <listitem>
+        <para>
+          Obtain a node ID
+        </para>
+      </listitem>
 
-          <listitem>
-            <para>
-              Allocate ports to be used for inter-node communications
-            </para>
-          </listitem>
+      <listitem>
+        <para>
+          Fetch configuration data
+        </para>
+      </listitem>
 
-          <listitem>
-            <para>
-              Allocate memory according to settings obtained from the
-              configuration file
-            </para>
-          </listitem>
+      <listitem>
+        <para>
+          Allocate ports to be used for inter-node communications
+        </para>
+      </listitem>
 
-        </orderedlist>
-      </para>
+      <listitem>
+        <para>
+          Allocate memory according to settings obtained from the
+          configuration file
+        </para>
+      </listitem>
 
-    </formalpara>
+    </orderedlist>
 
     <para>
       When a data node or SQL node first connects to the management

@@ -255,237 +254,235 @@
       After each data node has been initialized, the cluster startup
       process can proceed. The stages which the cluster goes through
       during this process are listed here:
+    </para>
 
-      <itemizedlist>
+    <itemizedlist>
 
-        <listitem>
-          <formalpara>
+      <listitem>
+        <formalpara>
 
-            <title>Phase 0</title>
+          <title>Phase 0</title>
 
-            <para>
-              The <literal>NDBFS</literal> and
-              <literal>NDBCNTR</literal> blocks start (see
-              <xref linkend="ndb-internals-kernel-blocks"/>). The
-              cluster file system is cleared, if the cluster was started
-              with the <option>--initial</option> option.
-            </para>
+          <para>
+            The <literal>NDBFS</literal> and <literal>NDBCNTR</literal>
+            blocks start (see
+            <xref linkend="ndb-internals-kernel-blocks"/>). The cluster
+            file system is cleared, if the cluster was started with the
+            <option>--initial</option> option.
+          </para>
 
-          </formalpara>
-        </listitem>
+        </formalpara>
+      </listitem>
 
-        <listitem>
-          <formalpara>
+      <listitem>
+        <formalpara>
 
-            <title>Phase 1</title>
+          <title>Phase 1</title>
 
-            <para>
-              In this stage, all remaining
-              <literal role="se">NDB</literal> kernel blocks are
-              started. Cluster connections are set up, inter-block
-              communications are established, and Cluster heartbeats are
-              started. In the case of a node restart, API node
-              connections are also checked.
+          <para>
+            In this stage, all remaining
+            <literal role="se">NDB</literal> kernel blocks are started.
+            Cluster connections are set up, inter-block communications
+            are established, and Cluster heartbeats are started. In the
+            case of a node restart, API node connections are also
+            checked.
+          </para>
 
-              <note>
-                <para>
-                  When one or more nodes hang in Phase 1 while the
-                  remaining node or nodes hang in Phase 2, this often
-                  indicates network problems. One possible cause of such
-                  issues is one or more cluster hosts having multiple
-                  network interfaces. Another common source of problems
-                  causing this condition is the blocking of TCP/IP ports
-                  needed for communications between cluster nodes. In
-                  the latter case, this is often due to a misconfigured
-                  firewall.
-                </para>
-              </note>
-            </para>
+        </formalpara>
 
-          </formalpara>
-        </listitem>
+        <note>
+          <para>
+            When one or more nodes hang in Phase 1 while the remaining
+            node or nodes hang in Phase 2, this often indicates network
+            problems. One possible cause of such issues is one or more
+            cluster hosts having multiple network interfaces. Another
+            common source of problems causing this condition is the
+            blocking of TCP/IP ports needed for communications between
+            cluster nodes. In the latter case, this is often due to a
+            misconfigured firewall.
+          </para>
+        </note>
+      </listitem>
 
-        <listitem>
-          <formalpara>
+      <listitem>
+        <formalpara>
 
-            <title>Phase 2</title>
+          <title>Phase 2</title>
 
-            <para>
-              The <literal>NDBCNTR</literal> kernel block checks the
-              states of all existing nodes. The master node is chosen,
-              and the cluster schema file is initialized.
-            </para>
+          <para>
+            The <literal>NDBCNTR</literal> kernel block checks the
+            states of all existing nodes. The master node is chosen, and
+            the cluster schema file is initialized.
+          </para>
 
-          </formalpara>
-        </listitem>
+        </formalpara>
+      </listitem>
 
-        <listitem>
-          <formalpara>
+      <listitem>
+        <formalpara>
 
-            <title>Phase 3</title>
+          <title>Phase 3</title>
 
-            <para>
-              The <literal>DBLQH</literal> and <literal>DBTC</literal>
-              kernel blocks set up communications between them. The
-              startup type is determined; if this is a restart, the
-              <literal>DBDIH</literal> block obtains permission to
-              perform the restart.
-            </para>
+          <para>
+            The <literal>DBLQH</literal> and <literal>DBTC</literal>
+            kernel blocks set up communications between them. The
+            startup type is determined; if this is a restart, the
+            <literal>DBDIH</literal> block obtains permission to perform
+            the restart.
+          </para>
 
-          </formalpara>
-        </listitem>
+        </formalpara>
+      </listitem>
 
-        <listitem>
-          <formalpara>
+      <listitem>
+        <formalpara>
 
-            <title>Phase 4</title>
+          <title>Phase 4</title>
 
+          <para>
+            For an initial start or initial node restart, the redo log
+            files are created. The number of these files is equal to
+            <literal>NoOfFragmentLogFiles</literal>.
+          </para>
+
+        </formalpara>
+
+        <para>
+          For a system restart:
+        </para>
+
+        <itemizedlist>
+
+          <listitem>
             <para>
-              For an initial start or initial node restart, the redo log
-              files are created. The number of these files is equal to
-              <literal>NoOfFragmentLogFiles</literal>.
+              Read schema or schemas.
             </para>
+          </listitem>
 
-          </formalpara>
+          <listitem>
+            <para>
+              Read data from the local checkpoint.
+            </para>
+          </listitem>
 
-          <para>
-            For a system restart:
-          </para>
+          <listitem>
+            <para>
+              Apply all redo information until the latest restorable
+              global checkpoint has been reached.
+            </para>
+          </listitem>
 
-          <itemizedlist>
+        </itemizedlist>
 
-            <listitem>
-              <para>
-                Read schema or schemas.
-              </para>
-            </listitem>
+        <para>
+          For a node restart, find the tail of the redo log.
+        </para>
+      </listitem>
 
-            <listitem>
-              <para>
-                Read data from the local checkpoint.
-              </para>
-            </listitem>
+      <listitem>
+        <formalpara>
 
-            <listitem>
-              <para>
-                Apply all redo information until the latest restorable
-                global checkpoint has been reached.
-              </para>
-            </listitem>
+          <title>Phase 5</title>
 
-          </itemizedlist>
-
           <para>
-            For a node restart, find the tail of the redo log.
+            Most of the database-related portion of a data node start is
+            performed during this phase. For an initial start or system
+            restart, a local checkpoint is executed, followed by a
+            global checkpoint. Periodic checks of memory usage begin
+            during this phase, and any required node takeovers are
+            performed.
           </para>
-        </listitem>
 
-        <listitem>
-          <formalpara>
+        </formalpara>
+      </listitem>
 
-            <title>Phase 5</title>
+      <listitem>
+        <formalpara>
 
-            <para>
-              Most of the database-related portion of a data node start
-              is performed during this phase. For an initial start or
-              system restart, a local checkpoint is executed, followed
-              by a global checkpoint. Periodic checks of memory usage
-              begin during this phase, and any required node takeovers
-              are performed.
-            </para>
+          <title>Phase 6</title>
 
-          </formalpara>
-        </listitem>
+          <para>
+            In this phase, node groups are defined and set up.
+          </para>
 
-        <listitem>
-          <formalpara>
+        </formalpara>
+      </listitem>
 
-            <title>Phase 6</title>
+      <listitem>
+        <formalpara>
 
-            <para>
-              In this phase, node groups are defined and set up.
-            </para>
+          <title>Phase 7</title>
 
-          </formalpara>
-        </listitem>
+          <para>
+            The arbitrator node is selected and begins to function. The
+            next backup ID is set, as is the backup disk write speed.
+            Nodes reaching this start phase are marked as
+            <literal>Started</literal>. It is now possible for API nodes
+            (including SQL nodes) to connect to the cluster. connect.
+          </para>
 
-        <listitem>
-          <formalpara>
+        </formalpara>
+      </listitem>
 
-            <title>Phase 7</title>
+      <listitem>
+        <formalpara>
 
-            <para>
-              The arbitrator node is selected and begins to function.
-              The next backup ID is set, as is the backup disk write
-              speed. Nodes reaching this start phase are marked as
-              <literal>Started</literal>. It is now possible for API
-              nodes (including SQL nodes) to connect to the cluster.
-              connect.
-            </para>
+          <title>Phase 8</title>
 
-          </formalpara>
-        </listitem>
+          <para>
+            If this is a system restart, all indexes are rebuilt (by
+            <literal>DBDIH</literal>).
+          </para>
 
-        <listitem>
-          <formalpara>
+        </formalpara>
+      </listitem>
 
-            <title>Phase 8</title>
+      <listitem>
+        <formalpara>
 
-            <para>
-              If this is a system restart, all indexes are rebuilt (by
-              <literal>DBDIH</literal>).
-            </para>
+          <title>Phase 9</title>
 
-          </formalpara>
-        </listitem>
+          <para>
+            The node internal startup variables are reset.
+          </para>
 
-        <listitem>
-          <formalpara>
+        </formalpara>
+      </listitem>
 
-            <title>Phase 9</title>
+      <listitem>
+        <formalpara>
 
-            <para>
-              The node internal startup variables are reset.
-            </para>
+          <title>Phase 100 (<emphasis>OBSOLETE</emphasis>)</title>
 
-          </formalpara>
-        </listitem>
+          <para>
+            Formerly, it was at this point during a node restart or
+            initial node restart that API nodes could connect to the
+            node and begin to receive events. Currently, this phase is
+            empty.
+          </para>
 
-        <listitem>
-          <formalpara>
+        </formalpara>
+      </listitem>
 
-            <title>Phase 100 (<emphasis>OBSOLETE</emphasis>)</title>
+      <listitem>
+        <formalpara>
 
-            <para>
-              Formerly, it was at this point during a node restart or
-              initial node restart that API nodes could connect to the
-              node and begin to receive events. Currently, this phase is
-              empty.
-            </para>
+          <title>Phase 101</title>
 
-          </formalpara>
-        </listitem>
+          <para>
+            At this point in a node restart or initial node restart,
+            event delivery is handed over to the node joining the
+            cluster. The newly joined node takes over responsibility for
+            delivering its primary data to subscribers. This phase is
+            also referred to as <firstterm><literal>SUMA</literal>
+            handover phase</firstterm>.
+          </para>
 
-        <listitem>
-          <formalpara>
+        </formalpara>
+      </listitem>
 
-            <title>Phase 101</title>
+    </itemizedlist>
 
-            <para>
-              At this point in a node restart or initial node restart,
-              event delivery is handed over to the node joining the
-              cluster. The newly joined node takes over responsibility
-              for delivering its primary data to subscribers. This phase
-              is also referred to as <firstterm><literal>SUMA</literal>
-              handover phase</firstterm>.
-            </para>
-
-          </formalpara>
-        </listitem>
-
-      </itemizedlist>
-    </para>
-
     <para>
       After this process is completed for an initial start or system
       restart, transaction handling is enabled. For a node restart or

@@ -606,15 +603,15 @@
         <para>
           Beginning with MySQL 5.0.19, this command can also be used to
           individual management nodes online.
-
-          <note>
-            <para>
-              <literal>ALL START</literal> continues to affect data
-              nodes only.
-            </para>
-          </note>
         </para>
 
+        <note>
+          <para>
+            <literal>ALL START</literal> continues to affect data nodes
+            only.
+          </para>
+        </note>
+
         <important>
           <para>
             To use this command to bring a data node online, the data

@@ -1091,12 +1088,14 @@
           <para>
             If <literal>NOWAIT</literal> is specified, the management
             client displays a prompt immediately, as seen here:
+          </para>
 
 <programlisting>
 ndb_mgm&gt; <userinput>START BACKUP NOWAIT</userinput>
 ndb_mgm&gt;
 </programlisting>
 
+          <para>
             In this case, the management client can be used even while
             it prints progress information from the backup process.
           </para>

@@ -1116,6 +1115,7 @@
             With <literal>WAIT STARTED</literal> the management client
             waits until the backup has started before returning control
             to the user, as shown here:
+          </para>
 
 <programlisting>
 ndb_mgm&gt; <userinput>START BACKUP WAIT STARTED</userinput>

@@ -1123,7 +1123,6 @@
 Node 2: Backup 3 started from node 1
 ndb_mgm&gt;
 </programlisting>
-          </para>
         </listitem>
 
         <listitem>

@@ -1152,21 +1151,23 @@
       <para>
         The procedure for creating a backup consists of the following
         steps:
+      </para>
 
-        <orderedlist>
+      <orderedlist>
 
-          <listitem>
-            <para>
-              Start the management client (<command>ndb_mgm</command>),
-              if it not running already.
-            </para>
-          </listitem>
+        <listitem>
+          <para>
+            Start the management client (<command>ndb_mgm</command>), if
+            it not running already.
+          </para>
+        </listitem>
 
-          <listitem>
-            <para>
-              Execute the <userinput>START BACKUP</userinput> command.
-              This produces several lines of output indicating the
-              progress of the backup, as shown here:
+        <listitem>
+          <para>
+            Execute the <userinput>START BACKUP</userinput> command.
+            This produces several lines of output indicating the
+            progress of the backup, as shown here:
+          </para>
 
 <programlisting>
 ndb_mgm&gt; <userinput>START BACKUP</userinput>

@@ -1178,62 +1179,66 @@
  Data: 453648 bytes Log: 0 bytes
 ndb_mgm&gt;
 </programlisting>
-            </para>
-          </listitem>
+        </listitem>
 
-          <listitem>
-            <indexterm>
-              <primary>native backup and restore</primary>
-              <secondary>backup identifiers</secondary>
-            </indexterm>
+        <listitem>
+          <indexterm>
+            <primary>native backup and restore</primary>
+            <secondary>backup identifiers</secondary>
+          </indexterm>
 
-            <indexterm>
-              <primary>backup identifiers</primary>
-              <secondary>native backup and restore</secondary>
-            </indexterm>
+          <indexterm>
+            <primary>backup identifiers</primary>
+            <secondary>native backup and restore</secondary>
+          </indexterm>
 
-            <para>
-              When the backup has started the management client displays
-              this message:
+          <para>
+            When the backup has started the management client displays
+            this message:
+          </para>
 
 <programlisting>
 Backup <replaceable>backup_id</replaceable> started from node <replaceable>node_id</replaceable>
 </programlisting>
 
-              <replaceable>backup_id</replaceable> is the unique
-              identifier for this particular backup. This identifier is
-              saved in the cluster log, if it has not been configured
-              otherwise. <replaceable>node_id</replaceable> is the
-              identifier of the management server that is coordinating
-              the backup with the data nodes. At this point in the
-              backup process the cluster has received and processed the
-              backup request. It does not mean that the backup has
-              finished. An example of this statement is shown here:
+          <para>
+            <replaceable>backup_id</replaceable> is the unique
+            identifier for this particular backup. This identifier is
+            saved in the cluster log, if it has not been configured
+            otherwise. <replaceable>node_id</replaceable> is the
+            identifier of the management server that is coordinating the
+            backup with the data nodes. At this point in the backup
+            process the cluster has received and processed the backup
+            request. It does not mean that the backup has finished. An
+            example of this statement is shown here:
+          </para>
 
 <programlisting>	
 Node 2: Backup 1 started from node 1
 </programlisting>
-            </para>
-          </listitem>
+        </listitem>
 
-          <listitem>
-            <para>
-              The management client indicates with a message like this
-              one that the backup has started:
+        <listitem>
+          <para>
+            The management client indicates with a message like this one
+            that the backup has started:
+          </para>
 
 <programlisting>
 Backup <replaceable>backup_id</replaceable> started from node <replaceable>node_id</replaceable> completed
 </programlisting>
 
-              As is the case for the notification that the backup has
-              started, <replaceable>backup_id</replaceable> is the
-              unique identifier for this particular backup, and
-              <replaceable>node_id</replaceable> is the node ID of the
-              management server that is coordinating the backup with the
-              data nodes. This output is accompanied by additional
-              information including relevant global checkpoints, the
-              number of records backed up, and the size of the data, as
-              shown here:
+          <para>
+            As is the case for the notification that the backup has
+            started, <replaceable>backup_id</replaceable> is the unique
+            identifier for this particular backup, and
+            <replaceable>node_id</replaceable> is the node ID of the
+            management server that is coordinating the backup with the
+            data nodes. This output is accompanied by additional
+            information including relevant global checkpoints, the
+            number of records backed up, and the size of the data, as
+            shown here:
+          </para>
 
 <programlisting>	
 Node 2: Backup 1 started from node 1 completed

@@ -1241,11 +1246,9 @@
  #Records: 7362 #LogRecords: 0
  Data: 453648 bytes Log: 0 bytes
 </programlisting>
-            </para>
-          </listitem>
+        </listitem>
 
-        </orderedlist>
-      </para>
+      </orderedlist>
 
       <para>
         It is also possible to perform a backup from the system shell by

@@ -2863,251 +2866,248 @@
         <para>
           Each transaction has one transaction coordinator, which is
           chosen by one of the following methods:
+        </para>
 
-          <itemizedlist>
+      </formalpara>
 
-            <listitem>
-              <para>
-                In a round-robin fashion
-              </para>
-            </listitem>
+      <itemizedlist>
 
-            <listitem>
-              <para>
-                By communication proximity
-              </para>
-            </listitem>
+        <listitem>
+          <para>
+            In a round-robin fashion
+          </para>
+        </listitem>
 
-          </itemizedlist>
+        <listitem>
+          <para>
+            By communication proximity
+          </para>
+        </listitem>
 
-          <note>
-            <para>
-              You can determine which TC selection method is used for
-              transactions started from a given SQL node using the
-              <literal role="sysvar">ndb_optimized_node_selection</literal>
-              system variable. For more information, see
-              <xref linkend="mysql-cluster-system-variables"/>.
-            </para>
-          </note>
+      </itemizedlist>
 
-          All operations within the same transaction use the same
-          transaction coordinator, which reports the following
-          statistics:
+      <note>
+        <para>
+          You can determine which TC selection method is used for
+          transactions started from a given SQL node using the
+          <literal role="sysvar">ndb_optimized_node_selection</literal>
+          system variable. For more information, see
+          <xref linkend="mysql-cluster-system-variables"/>.
+        </para>
+      </note>
 
-          <itemizedlist>
+      <para>
+        All operations within the same transaction use the same
+        transaction coordinator, which reports the following statistics:
+      </para>
 
-            <listitem>
-              <formalpara>
+      <itemizedlist>
 
-                <title><literal>Trans count</literal></title>
+        <listitem>
+          <formalpara>
 
+            <title><literal>Trans count</literal></title>
+
+            <para>
+              This is the number transactions started in the last
+              interval using this TC as the transaction coordinator. Any
+              of these transactions may have committed, have been
+              aborted, or remain uncommitted at the end of the reporting
+              interval.
+
+              <note>
                 <para>
-                  This is the number transactions started in the last
-                  interval using this TC as the transaction coordinator.
-                  Any of these transactions may have committed, have
-                  been aborted, or remain uncommitted at the end of the
-                  reporting interval.
-
-                  <note>
-                    <para>
-                      Transactions do not migrate between TCs.
-                    </para>
-                  </note>
+                  Transactions do not migrate between TCs.
                 </para>
+              </note>
+            </para>
 
-              </formalpara>
-            </listitem>
+          </formalpara>
+        </listitem>
 
-            <listitem>
-              <formalpara>
+        <listitem>
+          <formalpara>
 
-                <title><literal>Commit count</literal></title>
+            <title><literal>Commit count</literal></title>
 
-                <para>
-                  This is the number of transactions using this TC as
-                  the transaction coordinator that were committed in the
-                  last reporting interval. Because some transactions
-                  committed in this reporting interval may have started
-                  in a previous reporting interval, it is possible for
-                  <literal>Commit count</literal> to be greater than
-                  <literal>Trans count</literal>.
-                </para>
+            <para>
+              This is the number of transactions using this TC as the
+              transaction coordinator that were committed in the last
+              reporting interval. Because some transactions committed in
+              this reporting interval may have started in a previous
+              reporting interval, it is possible for <literal>Commit
+              count</literal> to be greater than <literal>Trans
+              count</literal>.
+            </para>
 
-              </formalpara>
-            </listitem>
+          </formalpara>
+        </listitem>
 
-            <listitem>
-              <formalpara>
+        <listitem>
+          <formalpara>
 
-                <title><literal>Read count</literal></title>
+            <title><literal>Read count</literal></title>
 
-                <para>
-                  This is the number of primary key read operations
-                  using this TC as the transaction coordinator that were
-                  started in the last reporting interval, including
-                  simple reads. This count also includes reads performed
-                  as part of unique index operations. A unique index
-                  read operation generates 2 primary key read
-                  operations&mdash;1 for the hidden unique index table,
-                  and 1 for the table on which the read takes place.
-                </para>
+            <para>
+              This is the number of primary key read operations using
+              this TC as the transaction coordinator that were started
+              in the last reporting interval, including simple reads.
+              This count also includes reads performed as part of unique
+              index operations. A unique index read operation generates
+              2 primary key read operations&mdash;1 for the hidden
+              unique index table, and 1 for the table on which the read
+              takes place.
+            </para>
 
-              </formalpara>
-            </listitem>
+          </formalpara>
+        </listitem>
 
-            <listitem>
-              <formalpara>
+        <listitem>
+          <formalpara>
 
-                <title><literal>Simple read count</literal></title>
+            <title><literal>Simple read count</literal></title>
 
-                <para>
-                  This is the number of simple read operations using
-                  this TC as the transaction coordinator that were
-                  started in the last reporting interval. This is a
-                  subset of <literal>Read count</literal>. Because the
-                  value of <literal>Simple read count</literal> is
-                  incremented at a different point in time from
-                  <literal>Read count</literal>, it can lag behind
-                  <literal>Read count</literal> slightly, so it is
-                  conceivable that <literal>Simple read count</literal>
-                  is not equal to <literal>Read count</literal> for a
-                  given reporting interval, even if all reads made
-                  during that time were in fact simple reads.
-                </para>
+            <para>
+              This is the number of simple read operations using this TC
+              as the transaction coordinator that were started in the
+              last reporting interval. This is a subset of <literal>Read
+              count</literal>. Because the value of <literal>Simple read
+              count</literal> is incremented at a different point in
+              time from <literal>Read count</literal>, it can lag behind
+              <literal>Read count</literal> slightly, so it is
+              conceivable that <literal>Simple read count</literal> is
+              not equal to <literal>Read count</literal> for a given
+              reporting interval, even if all reads made during that
+              time were in fact simple reads.
+            </para>
 
-              </formalpara>
-            </listitem>
+          </formalpara>
+        </listitem>
 
-            <listitem>
-              <formalpara>
+        <listitem>
+          <formalpara>
 
-                <title><literal>Write count</literal></title>
+            <title><literal>Write count</literal></title>
 
-                <para>
-                  This is the number of primary key write operations
-                  using this TC as the transaction coordinator that were
-                  started in the last reporting interval. This includes
-                  all inserts, updates, writes and deletes, as well as
-                  writes performed as part of unique index operations.
+            <para>
+              This is the number of primary key write operations using
+              this TC as the transaction coordinator that were started
+              in the last reporting interval. This includes all inserts,
+              updates, writes and deletes, as well as writes performed
+              as part of unique index operations.
+            </para>
 
-                  <note>
-                    <para>
-                      A unique index update operation can generate
-                      multiple PK read and write operations on the index
-                      table and on the base table.
-                    </para>
-                  </note>
-                </para>
+          </formalpara>
 
-              </formalpara>
-            </listitem>
+          <note>
+            <para>
+              A unique index update operation can generate multiple PK
+              read and write operations on the index table and on the
+              base table.
+            </para>
+          </note>
+        </listitem>
 
-            <listitem>
-              <formalpara>
+        <listitem>
+          <formalpara>
 
-                <title><literal>AttrInfoCount</literal></title>
+            <title><literal>AttrInfoCount</literal></title>
 
-                <para>
-                  This is the number of 32-bit data words received in
-                  the last reporting interval for primary key operations
-                  using this TC as the transaction coordinator. For
-                  reads, this is proportional to the number of columns
-                  requested. For inserts and updates, this is
-                  proportional to the number of columns written, and the
-                  size of their data. For delete operations, this is
-                  usually zero. Unique index operations generate
-                  multiple PK operations and so increase this count.
-                  However, data words sent to describe the PK operation
-                  itself, and the key information sent, are
-                  <emphasis>not</emphasis> counted here. Attribute
-                  information sent to describe columns to read for
-                  scans, or to describe ScanFilters, is also not counted
-                  in <literal>AttrInfoCount</literal>.
-                </para>
+            <para>
+              This is the number of 32-bit data words received in the
+              last reporting interval for primary key operations using
+              this TC as the transaction coordinator. For reads, this is
+              proportional to the number of columns requested. For
+              inserts and updates, this is proportional to the number of
+              columns written, and the size of their data. For delete
+              operations, this is usually zero. Unique index operations
+              generate multiple PK operations and so increase this
+              count. However, data words sent to describe the PK
+              operation itself, and the key information sent, are
+              <emphasis>not</emphasis> counted here. Attribute
+              information sent to describe columns to read for scans, or
+              to describe ScanFilters, is also not counted in
+              <literal>AttrInfoCount</literal>.
+            </para>
 
-              </formalpara>
-            </listitem>
+          </formalpara>
+        </listitem>
 
-            <listitem>
-              <formalpara>
+        <listitem>
+          <formalpara>
 
-                <title><literal>Concurrent Operations</literal></title>
+            <title><literal>Concurrent Operations</literal></title>
 
-                <para>
-                  This is the number of primary key or scan operations
-                  using this TC as the transaction coordinator that were
-                  started during the last reporting interval but that
-                  were not completed. Operations increment this counter
-                  when they are started and decrement it when they are
-                  completed; this occurs after the transaction commits.
-                  Dirty reads and writes&mdash;as well as failed
-                  operations&mdash;decrement this counter. The maximum
-                  value that <literal>Concurrent Operations</literal>
-                  can have is the maximum number of operations that a TC
-                  block can support; currently, this is <literal>(2 *
-                  MaxNoOfConcurrentOperations) + 16 +
-                  MaxNoOfConcurrentTransactions</literal>. (For more
-                  information about these configuration parameters, see
-                  the <citetitle>Transaction Parameters</citetitle>
-                  section of
-                  <xref linkend="mysql-cluster-ndbd-definition"/>.)
-                </para>
+            <para>
+              This is the number of primary key or scan operations using
+              this TC as the transaction coordinator that were started
+              during the last reporting interval but that were not
+              completed. Operations increment this counter when they are
+              started and decrement it when they are completed; this
+              occurs after the transaction commits. Dirty reads and
+              writes&mdash;as well as failed operations&mdash;decrement
+              this counter. The maximum value that <literal>Concurrent
+              Operations</literal> can have is the maximum number of
+              operations that a TC block can support; currently, this is
+              <literal>(2 * MaxNoOfConcurrentOperations) + 16 +
+              MaxNoOfConcurrentTransactions</literal>. (For more
+              information about these configuration parameters, see the
+              <citetitle>Transaction Parameters</citetitle> section of
+              <xref linkend="mysql-cluster-ndbd-definition"/>.)
+            </para>
 
-              </formalpara>
-            </listitem>
+          </formalpara>
+        </listitem>
 
-            <listitem>
-              <formalpara>
+        <listitem>
+          <formalpara>
 
-                <title><literal>Abort count</literal></title>
+            <title><literal>Abort count</literal></title>
 
-                <para>
-                  This is the number of transactions using this TC as
-                  the transaction coordinator that were aborted during
-                  the last reporting interval. Because some transactions
-                  that were aborted in the last reporting interval may
-                  have started in a previous reporting interval,
-                  <literal>Abort count</literal> can sometimes be
-                  greater than <literal>Trans count</literal>.
-                </para>
+            <para>
+              This is the number of transactions using this TC as the
+              transaction coordinator that were aborted during the last
+              reporting interval. Because some transactions that were
+              aborted in the last reporting interval may have started in
+              a previous reporting interval, <literal>Abort
+              count</literal> can sometimes be greater than
+              <literal>Trans count</literal>.
+            </para>
 
-              </formalpara>
-            </listitem>
+          </formalpara>
+        </listitem>
 
-            <listitem>
-              <formalpara>
+        <listitem>
+          <formalpara>
 
-                <title><literal>Scans</literal></title>
+            <title><literal>Scans</literal></title>
 
-                <para>
-                  This is the number of table scans using this TC as the
-                  transaction coordinator that were started during the
-                  last reporting interval. This does not include range
-                  scans (that is, ordered index scans).
-                </para>
+            <para>
+              This is the number of table scans using this TC as the
+              transaction coordinator that were started during the last
+              reporting interval. This does not include range scans
+              (that is, ordered index scans).
+            </para>
 
-              </formalpara>
-            </listitem>
+          </formalpara>
+        </listitem>
 
-            <listitem>
-              <formalpara>
+        <listitem>
+          <formalpara>
 
-                <title><literal>Range scans</literal></title>
+            <title><literal>Range scans</literal></title>
 
-                <para>
-                  This is the number of ordered index scans using this
-                  TC as the transaction coordinator that were started in
-                  the last reporting interval.
-                </para>
+            <para>
+              This is the number of ordered index scans using this TC as
+              the transaction coordinator that were started in the last
+              reporting interval.
+            </para>
 
-              </formalpara>
-            </listitem>
+          </formalpara>
+        </listitem>
 
-          </itemizedlist>
-        </para>
+      </itemizedlist>
 
-      </formalpara>
-
       <formalpara>
 
         <title>Local query handler statistics (<literal>Operations</literal>)</title>

@@ -3116,39 +3116,31 @@
           There is 1 cluster event per local query handler block (that
           is, 1 per data node process). Operations are recorded in the
           LQH where the data they are operating on resides.
+        </para>
 
-          <remark role="note">
-            [js] Commented out the following sentence because we
-            currently only support 1 type of partitioning on NDB tables.
-          </remark>
+      </formalpara>
 
-<!--
-          Data placement depends on the partitioning or fragmentation
-          scheme used when the table was defined.
--->
-
-          <note>
-            <para>
-              A single transaction may operate on data stored in
-              multiple LQH blocks.
-            </para>
-          </note>
-
-          The <literal>Operations</literal> statistic provides the
-          number of local operations performed by this LQH block in the
-          last reporting interval, and includes all types of read and
-          write operations (insert, update, write, and delete
-          operations). This also includes operations used to replicate
-          writes&mdash;for example, in a 2-replica cluster, the write to
-          the primary replica is recorded in the primary LQH, and the
-          write to the backup will be recorded in the backup LQH. Unique
-          key operations may result in multiple local operations;
-          however, this does <emphasis>not</emphasis> include local
-          operations generated as a result of a table scan or ordered
-          index scan, which are not counted.
+      <note>
+        <para>
+          A single transaction may operate on data stored in multiple
+          LQH blocks.
         </para>
+      </note>
 
-      </formalpara>
+      <para>
+        The <literal>Operations</literal> statistic provides the number
+        of local operations performed by this LQH block in the last
+        reporting interval, and includes all types of read and write
+        operations (insert, update, write, and delete operations). This
+        also includes operations used to replicate writes&mdash;for
+        example, in a 2-replica cluster, the write to the primary
+        replica is recorded in the primary LQH, and the write to the
+        backup will be recorded in the backup LQH. Unique key operations
+        may result in multiple local operations; however, this does
+        <emphasis>not</emphasis> include local operations generated as a
+        result of a table scan or ordered index scan, which are not
+        counted.
+      </para>
 
       <formalpara>
 

@@ -3161,110 +3153,111 @@
           provides useful metrics relating to the performance of a MySQL
           Cluster. This scheduler runs in an infinite loop; during each
           loop the scheduler performs the following tasks:
+        </para>
 
-          <indexterm>
-            <primary>MySQL Cluster</primary>
-            <secondary>ndbd process</secondary>
-          </indexterm>
+      </formalpara>
 
-          <orderedlist>
+      <indexterm>
+        <primary>MySQL Cluster</primary>
+        <secondary>ndbd process</secondary>
+      </indexterm>
 
-            <listitem>
-              <para>
-                Read any incoming messages from sockets into a job
-                buffer.
-              </para>
-            </listitem>
+      <orderedlist>
 
-            <listitem>
-              <para>
-                Check whether there are any timed messages to be
-                executed; if so, put these into the job buffer as well.
-              </para>
-            </listitem>
+        <listitem>
+          <para>
+            Read any incoming messages from sockets into a job buffer.
+          </para>
+        </listitem>
 
-            <listitem>
-              <para>
-                Execute (in a loop) any messages in the job buffer.
-              </para>
-            </listitem>
+        <listitem>
+          <para>
+            Check whether there are any timed messages to be executed;
+            if so, put these into the job buffer as well.
+          </para>
+        </listitem>
 
-            <listitem>
-              <para>
-                Send any distributed messages that were generated by
-                executing the messages in the job buffer.
-              </para>
-            </listitem>
+        <listitem>
+          <para>
+            Execute (in a loop) any messages in the job buffer.
+          </para>
+        </listitem>
 
-            <listitem>
-              <para>
-                Wait for any new incoming messages.
-              </para>
-            </listitem>
+        <listitem>
+          <para>
+            Send any distributed messages that were generated by
+            executing the messages in the job buffer.
+          </para>
+        </listitem>
 
-          </orderedlist>
+        <listitem>
+          <para>
+            Wait for any new incoming messages.
+          </para>
+        </listitem>
 
-          Process scheduler statistics include the following:
+      </orderedlist>
 
-          <itemizedlist>
+      <para>
+        Process scheduler statistics include the following:
+      </para>
 
-            <listitem>
-              <formalpara>
+      <itemizedlist>
 
-                <title><literal>Mean Loop Counter</literal></title>
+        <listitem>
+          <formalpara>
 
-                <para>
-                  This is the number of loops executed in the third step
-                  from the preceding list. This statistic increases in
-                  size as the utilization of the TCP/IP buffer improves.
-                  You can use this to monitor changes in performance as
-                  you add new data node processes.
-                </para>
+            <title><literal>Mean Loop Counter</literal></title>
 
-              </formalpara>
-            </listitem>
+            <para>
+              This is the number of loops executed in the third step
+              from the preceding list. This statistic increases in size
+              as the utilization of the TCP/IP buffer improves. You can
+              use this to monitor changes in performance as you add new
+              data node processes.
+            </para>
 
-            <listitem>
-              <formalpara>
+          </formalpara>
+        </listitem>
 
-                <title><literal>Mean send size</literal> and <literal>Mean receive
-                  size</literal></title>
+        <listitem>
+          <formalpara>
 
-                <para>
-                  These statistics enable you to gauge the efficiency
-                  of, respectively writes and reads between nodes. The
-                  values are given in bytes. Higher values mean a lower
-                  cost per byte sent or received; the maximum value is
-                  64K.
-                </para>
+            <title><literal>Mean send size</literal> and <literal>Mean receive
+              size</literal></title>
 
-              </formalpara>
-            </listitem>
+            <para>
+              These statistics enable you to gauge the efficiency of,
+              respectively writes and reads between nodes. The values
+              are given in bytes. Higher values mean a lower cost per
+              byte sent or received; the maximum value is 64K.
+            </para>
 
-          </itemizedlist>
-        </para>
+          </formalpara>
+        </listitem>
 
-      </formalpara>
+      </itemizedlist>
 
       <para>
         To cause all cluster log statistics to be logged, you can use
         the following command in the <literal role="se">NDB</literal>
         management client:
+      </para>
 
 <programlisting>
 ndb_mgm&gt; <userinput>ALL CLUSTERLOG STATISTICS=15</userinput>
 </programlisting>
 
-        <note>
-          <para>
-            Setting the threshold for <literal>STATISTICS</literal> to
-            15 causes the cluster log to become very verbose, and to
-            grow quite rapidly in size, in direct proportion to the
-            number of cluster nodes and the amount of activity in the
-            MySQL Cluster.
-          </para>
-        </note>
+      <note>
+        <para>
+          Setting the threshold for <literal>STATISTICS</literal> to 15
+          causes the cluster log to become very verbose, and to grow
+          quite rapidly in size, in direct proportion to the number of
+          cluster nodes and the amount of activity in the MySQL Cluster.
+        </para>
+      </note>
 
+      <para>
         For more information about MySQL Cluster management client
         commands relating to logging and reporting, see
         <xref linkend="mysql-cluster-logging-management-commands"/>.

@@ -5336,38 +5329,37 @@
 
                   <para>
                     Any of the following:
+                  </para>
 
-                    <orderedlist>
+                </formalpara>
 
-                      <listitem>
-                        <para>
-                          <literal>Node
-                          <replaceable>node_id</replaceable>: Node
-                          <replaceable>node1_id</replaceable> completed
-                          failure of Node
-                          <replaceable>node2_id</replaceable></literal>
-                        </para>
-                      </listitem>
+                <orderedlist>
 
-                      <listitem>
-                        <para>
-                          <literal>All nodes completed failure of Node
-                          <replaceable>node_id</replaceable></literal>
-                        </para>
-                      </listitem>
+                  <listitem>
+                    <para>
+                      <literal>Node <replaceable>node_id</replaceable>:
+                      Node <replaceable>node1_id</replaceable> completed
+                      failure of Node
+                      <replaceable>node2_id</replaceable></literal>
+                    </para>
+                  </listitem>
 
-                      <listitem>
-                        <para>
-                          <literal>Node failure of
-                          <replaceable>node_id</replaceable><replaceable>block</replaceable>
-                          completed</literal>
-                        </para>
-                      </listitem>
+                  <listitem>
+                    <para>
+                      <literal>All nodes completed failure of Node
+                      <replaceable>node_id</replaceable></literal>
+                    </para>
+                  </listitem>
 
-                    </orderedlist>
-                  </para>
+                  <listitem>
+                    <para>
+                      <literal>Node failure of
+                      <replaceable>node_id</replaceable><replaceable>block</replaceable>
+                      completed</literal>
+                    </para>
+                  </listitem>
 
-                </formalpara>
+                </orderedlist>
 
                 <formalpara>
 

@@ -5376,45 +5368,44 @@
                   <para>
                     One of the following (each corresponding to the
                     same-numbered message listed above):
+                  </para>
 
-                    <orderedlist>
+                </formalpara>
 
-                      <listitem>
-                        <para>
-                          Data node <replaceable>node1_id</replaceable>
-                          has detected the failure of data node
-                          <replaceable>node2_id</replaceable>
-                        </para>
-                      </listitem>
+                <orderedlist>
 
-                      <listitem>
-                        <para>
-                          All (remaining) data nodes have detected the
-                          failure of data node
-                          <replaceable>node_id</replaceable>
-                        </para>
-                      </listitem>
+                  <listitem>
+                    <para>
+                      Data node <replaceable>node1_id</replaceable> has
+                      detected the failure of data node
+                      <replaceable>node2_id</replaceable>
+                    </para>
+                  </listitem>
 
-                      <listitem>
-                        <para>
-                          The failure of data node
-                          <replaceable>node_id</replaceable> has been
-                          detected in the
-                          <replaceable>block</replaceable><literal role="se">NDB</literal>
-                          kernel block, where block is 1 of
-                          <literal>DBTC</literal>,
-                          <literal>DBDICT</literal>,
-                          <literal>DBDIH</literal>, or
-                          <literal>DBLQH</literal>; for more
-                          information, see
-                          <xref linkend="ndb-internals-kernel-blocks"/>
-                        </para>
-                      </listitem>
+                  <listitem>
+                    <para>
+                      All (remaining) data nodes have detected the
+                      failure of data node
+                      <replaceable>node_id</replaceable>
+                    </para>
+                  </listitem>
 
-                    </orderedlist>
-                  </para>
+                  <listitem>
+                    <para>
+                      The failure of data node
+                      <replaceable>node_id</replaceable> has been
+                      detected in the
+                      <replaceable>block</replaceable><literal role="se">NDB</literal>
+                      kernel block, where block is 1 of
+                      <literal>DBTC</literal>,
+                      <literal>DBDICT</literal>,
+                      <literal>DBDIH</literal>, or
+                      <literal>DBLQH</literal>; for more information,
+                      see <xref linkend="ndb-internals-kernel-blocks"/>
+                    </para>
+                  </listitem>
 
-                </formalpara></entry>
+                </orderedlist></entry>
               <entry><formalpara>
 
                   <title>Event Name</title>

@@ -7729,6 +7720,7 @@
           the MySQL server's cluster node ID, the host name and port for
           the cluster management server to which it is connected, and
           the number of data nodes in the cluster, as shown here:
+        </para>
 
 <programlisting>
 mysql&gt; <userinput>SHOW STATUS LIKE 'NDB%';</userinput>

@@ -7742,9 +7734,11 @@
 +--------------------------+---------------+
 </programlisting>
 
+        <para>
           If the MySQL server was built with clustering support, but it
           is not connected to a cluster, all rows in the output of this
           statement contain a zero or an empty string:
+        </para>
 
 <programlisting>
 mysql&gt; <userinput>SHOW STATUS LIKE 'NDB%';</userinput>

@@ -7757,7 +7751,6 @@
 | Ndb_number_of_data_nodes | 0     |
 +--------------------------+-------+
 </programlisting>
-        </para>
 
         <para>
           See also <xref linkend="show-status"/>.

@@ -7783,7 +7776,7 @@
     </para>
 
     <para>
-      Topics to be covered in this chapter include the following:
+      Topics covered in this chapter include the following:
     </para>
 
     <itemizedlist>

@@ -7860,89 +7853,86 @@
       <para>
         In addition, there is no checking of the source IP address for
         either of the following when accessing the cluster:
+      </para>
 
-        <itemizedlist>
+      <itemizedlist>
 
-          <listitem>
-            <para>
-              SQL or API nodes using <quote>free slots</quote> created
-              by empty <literal>[mysqld]</literal> or
-              <literal>[api]</literal> sections in the
-              <filename>config.ini</filename> file
-            </para>
+        <listitem>
+          <para>
+            SQL or API nodes using <quote>free slots</quote> created by
+            empty <literal>[mysqld]</literal> or
+            <literal>[api]</literal> sections in the
+            <filename>config.ini</filename> file
+          </para>
 
+          <para>
+            This means that, if there are any empty
+            <literal>[mysqld]</literal> or <literal>[api]</literal>
+            sections in the <filename>config.ini</filename> file, then
+            any API nodes (including SQL nodes) that know the management
+            server's host name (or IP address) and port can connect to
+            the cluster and access its data without restriction. (See
+            <xref linkend="mysql-cluster-security-mysql-privileges"/>,
+            for more information about this and related issues.)
+          </para>
+
+          <note>
             <para>
-              This means that, if there are any empty
-              <literal>[mysqld]</literal> or <literal>[api]</literal>
-              sections in the <filename>config.ini</filename> file, then
-              any API nodes (including SQL nodes) that know the
-              management server's host name (or IP address) and port can
-              connect to the cluster and access its data without
-              restriction. (See
-              <xref linkend="mysql-cluster-security-mysql-privileges"/>,
-              for more information about this and related issues.)
-            </para>
+              <indexterm>
+                <primary>MySQL Cluster</primary>
+                <secondary>security</secondary>
+                <tertiary>and HostName parameter</tertiary>
+              </indexterm>
 
-            <note>
-              <para>
-                <indexterm>
-                  <primary>MySQL Cluster</primary>
-                  <secondary>security</secondary>
-                  <tertiary>and HostName parameter</tertiary>
-                </indexterm>
+              <indexterm>
+                <primary>MySQL Cluster</primary>
+                <secondary>HostName parameter</secondary>
+                <tertiary>and security</tertiary>
+              </indexterm>
 
-                <indexterm>
-                  <primary>MySQL Cluster</primary>
-                  <secondary>HostName parameter</secondary>
-                  <tertiary>and security</tertiary>
-                </indexterm>
+              <indexterm>
+                <primary>HostName (MySQL Cluster)</primary>
+              </indexterm>
 
-                <indexterm>
-                  <primary>HostName (MySQL Cluster)</primary>
-                </indexterm>
-
-                You can exercise some control over SQL and API node
-                access to the cluster by specifying a
-                <literal>HostName</literal> parameter for all
-                <literal>[mysqld]</literal> and <literal>[api]</literal>
-                sections in the <filename>config.ini</filename> file.
-                However, this also means that, should you wish to
-                connect an API node to the cluster from a previously
-                unused host, you need to add an <literal>[api]</literal>
-                section containing its host name to the
-                <filename>config.ini</filename> file.
-              </para>
-
-              <para>
-                More information is available
-                <link linkend="ndbparam-api-hostname">elsewhere in this
-                chapter</link> about the <literal>HostName</literal>
-                parameter. Also see
-                <xref linkend="mysql-cluster-quick"/>, for configuration
-                examples using <literal>HostName</literal> with API
-                nodes.
-              </para>
-            </note>
-          </listitem>
-
-          <listitem>
-            <para>
-              Any <command>ndb_mgm</command> client
+              You can exercise some control over SQL and API node access
+              to the cluster by specifying a <literal>HostName</literal>
+              parameter for all <literal>[mysqld]</literal> and
+              <literal>[api]</literal> sections in the
+              <filename>config.ini</filename> file. However, this also
+              means that, should you wish to connect an API node to the
+              cluster from a previously unused host, you need to add an
+              <literal>[api]</literal> section containing its host name
+              to the <filename>config.ini</filename> file.
             </para>
 
             <para>
-              This means that any cluster management client that is
-              given the management server's host name (or IP address)
-              and port (if not the standard port) can connect to the
-              cluster and execute any management client command. This
-              includes commands such as <literal>ALL STOP</literal> and
-              <literal>SHUTDOWN</literal>.
+              More information is available
+              <link linkend="ndbparam-api-hostname">elsewhere in this
+              chapter</link> about the <literal>HostName</literal>
+              parameter. Also see <xref linkend="mysql-cluster-quick"/>,
+              for configuration examples using
+              <literal>HostName</literal> with API nodes.
             </para>
-          </listitem>
+          </note>
+        </listitem>
 
-        </itemizedlist>
-      </para>
+        <listitem>
+          <para>
+            Any <command>ndb_mgm</command> client
+          </para>
 
+          <para>
+            This means that any cluster management client that is given
+            the management server's host name (or IP address) and port
+            (if not the standard port) can connect to the cluster and
+            execute any management client command. This includes
+            commands such as <literal>ALL STOP</literal> and
+            <literal>SHUTDOWN</literal>.
+          </para>
+        </listitem>
+
+      </itemizedlist>
+
       <para>
         <indexterm>
           <primary>MySQL Cluster</primary>

@@ -7961,250 +7951,257 @@
         one which isolates connections between Cluster nodes from any
         other network communications. This can be accomplished by any of
         the following methods:
+      </para>
 
-        <orderedlist>
+      <orderedlist>
 
-          <listitem>
-            <para>
-              Keeping Cluster nodes on a network that is physically
-              separate from any public networks. This option is the most
-              dependable; however, it is the most expensive to
-              implement.
-            </para>
+        <listitem>
+          <para>
+            Keeping Cluster nodes on a network that is physically
+            separate from any public networks. This option is the most
+            dependable; however, it is the most expensive to implement.
+          </para>
 
-            <para>
-              We show an example of a MySQL Cluster setup using such a
-              physically segregated network here:
+          <para>
+            We show an example of a MySQL Cluster setup using such a
+            physically segregated network here:
+          </para>
 
-              <mediaobject>
-                <imageobject>
-                  <imagedata contentwidth="550" contentdepth="347" fileref="../refman-common/images/published/cluster-security-network-1.png" format="PNG"/>
-                </imageobject>
-                <textobject>
-                  <phrase lang="en">MySQL Cluster on a private network
-                  protected with a hardware firewall</phrase>
-                </textobject>
-              </mediaobject>
+          <mediaobject>
+            <imageobject>
+              <imagedata contentwidth="550" contentdepth="347" fileref="../refman-common/images/published/cluster-security-network-1.png" format="PNG"/>
+            </imageobject>
+            <textobject>
+              <phrase lang="en">MySQL Cluster on a private network
+              protected with a hardware firewall</phrase>
+            </textobject>
+          </mediaobject>
 
-              This setup has two networks, one private (solid box) for
-              the Cluster management servers and data nodes, and one
-              public (dotted box) where the SQL nodes reside. (We show
-              the management and data nodes connected using a gigabit
-              switch since this provides the best performance.) Both
-              networks are protected from the outside by a hardware
-              firewall, sometimes also known as a
-              <firstterm>network-based firewall</firstterm>.
-            </para>
+          <para>
+            This setup has two networks, one private (solid box) for the
+            Cluster management servers and data nodes, and one public
+            (dotted box) where the SQL nodes reside. (We show the
+            management and data nodes connected using a gigabit switch
+            since this provides the best performance.) Both networks are
+            protected from the outside by a hardware firewall, sometimes
+            also known as a <firstterm>network-based
+            firewall</firstterm>.
+          </para>
 
+          <para>
+            This network setup is safest because no packets can reach
+            the cluster's management or data nodes from outside the
+            network&mdash;and none of the cluster's internal
+            communications can reach the outside&mdash;without going
+            through the SQL nodes, as long as the SQL nodes do not
+            permit any packets to be forwarded. This means, of course,
+            that all SQL nodes must be secured against hacking attempts.
+          </para>
+
+          <important>
             <para>
-              This network setup is safest because no packets can reach
-              the cluster's management or data nodes from outside the
-              network&mdash;and none of the cluster's internal
-              communications can reach the outside&mdash;without going
-              through the SQL nodes, as long as the SQL nodes do not
-              permit any packets to be forwarded. This means, of course,
-              that all SQL nodes must be secured against hacking
-              attempts.
+              With regard to potential security vulnerabilities, an SQL
+              node is no different from any other MySQL server. See
+              <xref linkend="security-against-attack"/>, for a
+              description of techniques you can use to secure MySQL
+              servers.
             </para>
+          </important>
+        </listitem>
 
-            <important>
-              <para>
-                With regard to potential security vulnerabilities, an
-                SQL node is no different from any other MySQL server.
-                See <xref linkend="security-against-attack"/>, for a
-                description of techniques you can use to secure MySQL
-                servers.
-              </para>
-            </important>
-          </listitem>
+        <listitem>
+          <para>
+            <indexterm>
+              <primary>MySQL Cluster</primary>
+              <secondary>security</secondary>
+              <tertiary>and firewalls</tertiary>
+            </indexterm>
 
-          <listitem>
-            <para>
-              <indexterm>
-                <primary>MySQL Cluster</primary>
-                <secondary>security</secondary>
-                <tertiary>and firewalls</tertiary>
-              </indexterm>
+            <indexterm>
+              <primary>firewalls (software)</primary>
+              <secondary>and MySQL Cluster</secondary>
+            </indexterm>
 
-              <indexterm>
-                <primary>firewalls (software)</primary>
-                <secondary>and MySQL Cluster</secondary>
-              </indexterm>
+            Using one or more software firewalls (also known as
+            <firstterm>host-based firewalls</firstterm>) to control
+            which packets pass through to the cluster from portions of
+            the network that do not require access to it. In this type
+            of setup, a software firewall must be installed on every
+            host in the cluster which might otherwise be accessible from
+            outside the local network.
+          </para>
 
-              Using one or more software firewalls (also known as
-              <firstterm>host-based firewalls</firstterm>) to control
-              which packets pass through to the cluster from portions of
-              the network that do not require access to it. In this type
-              of setup, a software firewall must be installed on every
-              host in the cluster which might otherwise be accessible
-              from outside the local network.
-            </para>
+          <para>
+            The host-based option is the least expensive to implement,
+            but relies purely on software to provide protection and so
+            is the most difficult to keep secure.
+          </para>
 
-            <para>
-              The host-based option is the least expensive to implement,
-              but relies purely on software to provide protection and so
-              is the most difficult to keep secure.
-            </para>
+          <para>
+            This type of network setup for MySQL Cluster is illustrated
+            here:
+          </para>
 
-            <para>
-              This type of network setup for MySQL Cluster is
-              illustrated here:
+          <mediaobject>
+            <imageobject>
+              <imagedata contentwidth="550" contentdepth="489" fileref="../refman-common/images/published/cluster-security-network-2.png" format="PNG"/>
+            </imageobject>
+            <textobject>
+              <phrase lang="en">MySQL Cluster deployed on a network
+              using software firewalls to create public and private
+              zones</phrase>
+            </textobject>
+          </mediaobject>
 
-              <mediaobject>
-                <imageobject>
-                  <imagedata contentwidth="550" contentdepth="489" fileref="../refman-common/images/published/cluster-security-network-2.png" format="PNG"/>
-                </imageobject>
-                <textobject>
-                  <phrase lang="en">MySQL Cluster deployed on a network
-                  using software firewalls to create public and private
-                  zones</phrase>
-                </textobject>
-              </mediaobject>
+          <para>
+            Using this type of network setup means that there are two
+            zones of MySQL Cluster hosts. Each cluster host must be able
+            to communicate with all of the other machines in the
+            cluster, but only those hosting SQL nodes (dotted box) can
+            be permitted to have any contact with the outside, while
+            those in the zone containing the data nodes and management
+            nodes (solid box) must be isolated from any machines that
+            are not part of the cluster. Applications using the cluster
+            and user of those applications must <emphasis>not</emphasis>
+            be permitted to have direct access to the management and
+            data node hosts.
+          </para>
 
-              Using this type of network setup means that there are two
-              zones of MySQL Cluster hosts. Each cluster host must be
-              able to communicate with all of the other machines in the
-              cluster, but only those hosting SQL nodes (dotted box) can
-              be permitted to have any contact with the outside, while
-              those in the zone containing the data nodes and management
-              nodes (solid box) must be isolated from any machines that
-              are not part of the cluster. Applications using the
-              cluster and user of those applications must
-              <emphasis>not</emphasis> be permitted to have direct
-              access to the management and data node hosts.
-            </para>
+          <para>
+            To accomplish this, you must set up software firewalls that
+            limit the traffic to the type or types shown in the
+            following table, according to the type of node that is
+            running on each cluster host computer:
+          </para>
 
-            <para>
-              To accomplish this, you must set up software firewalls
-              that limit the traffic to the type or types shown in the
-              following table, according to the type of node that is
-              running on each cluster host computer:
+          <informaltable>
+            <tgroup cols="2">
+              <colspec colwidth="25*"/>
+              <colspec colwidth="75*"/>
+              <thead>
+                <row>
+                  <entry>Type of Node to be Accessed</entry>
+                  <entry>Traffic to Permit</entry>
+                </row>
+              </thead>
+              <tbody>
+                <row>
+                  <entry>SQL or API node</entry>
+                  <entry><itemizedlist>
 
-              <informaltable>
-                <tgroup cols="2">
-                  <colspec colwidth="25*"/>
-                  <colspec colwidth="75*"/>
-                  <thead>
-                    <row>
-                      <entry>Type of Node to be Accessed</entry>
-                      <entry>Traffic to Permit</entry>
-                    </row>
-                  </thead>
-                  <tbody>
-                    <row>
-                      <entry>SQL or API node</entry>
-                      <entry><itemizedlist>
+                      <listitem>
+                        <para>
+                          It originates from the IP address of a
+                          management or data node (using any TCP or UDP
+                          port).
+                        </para>
+                      </listitem>
 
-                          <listitem>
-                            <para>
-                              It originates from the IP address of a
-                              management or data node (using any TCP or
-                              UDP port).
-                            </para>
-                          </listitem>
+                      <listitem>
+                        <para>
+                          It originates from within the network in which
+                          the cluster resides and is on the port that
+                          your application is using.
+                        </para>
+                      </listitem>
 
-                          <listitem>
-                            <para>
-                              It originates from within the network in
-                              which the cluster resides and is on the
-                              port that your application is using.
-                            </para>
-                          </listitem>
+                    </itemizedlist></entry>
+                </row>
+                <row>
+                  <entry>Data node or Management node</entry>
+                  <entry><itemizedlist>
 
-                        </itemizedlist></entry>
-                    </row>
-                    <row>
-                      <entry>Data node or Management node</entry>
-                      <entry><itemizedlist>
+                      <listitem>
+                        <para>
+                          It originates from the IP address of a
+                          management or data node (using any TCP or UDP
+                          port).
+                        </para>
+                      </listitem>
 
-                          <listitem>
-                            <para>
-                              It originates from the IP address of a
-                              management or data node (using any TCP or
-                              UDP port).
-                            </para>
-                          </listitem>
+                      <listitem>
+                        <para>
+                          It originates from the IP address of an SQL or
+                          API node.
+                        </para>
+                      </listitem>
 
-                          <listitem>
-                            <para>
-                              It originates from the IP address of an
-                              SQL or API node.
-                            </para>
-                          </listitem>
+                    </itemizedlist></entry>
+                </row>
+              </tbody>
+            </tgroup>
+          </informaltable>
 
-                        </itemizedlist></entry>
-                    </row>
-                  </tbody>
-                </tgroup>
-              </informaltable>
+          <para>
+            Any traffic other than that shown in the table for a given
+            node type should be denied.
+          </para>
 
-              Any traffic other than that shown in the table for a given
-              node type should be denied.
-            </para>
+          <para>
+            The specifics of configuring a firewall vary from firewall
+            application to firewall application, and are beyond the
+            scope of this Manual. <command>iptables</command> is a very
+            common and reliable firewall application, which is often
+            used with <command>APF</command> as a front end to make
+            configuration easier. You can (and should) consult the
+            documentation for the software firewall that you employ,
+            should you choose to implement a MySQL Cluster network setup
+            of this type, or of a <quote>mixed</quote> type as discussed
+            under the next item.
+          </para>
+        </listitem>
 
-            <para>
-              The specifics of configuring a firewall vary from firewall
-              application to firewall application, and are beyond the
-              scope of this Manual. <command>iptables</command> is a
-              very common and reliable firewall application, which is
-              often used with <command>APF</command> as a front end to
-              make configuration easier. You can (and should) consult
-              the documentation for the software firewall that you
-              employ, should you choose to implement a MySQL Cluster
-              network setup of this type, or of a <quote>mixed</quote>
-              type as discussed under the next item.
-            </para>
-          </listitem>
+        <listitem>
+          <para>
+            <indexterm>
+              <primary>MySQL Cluster</primary>
+              <secondary>security</secondary>
+              <tertiary>and firewalls</tertiary>
+            </indexterm>
 
-          <listitem>
-            <para>
-              <indexterm>
-                <primary>MySQL Cluster</primary>
-                <secondary>security</secondary>
-                <tertiary>and firewalls</tertiary>
-              </indexterm>
+            <indexterm>
+              <primary>firewalls (software)</primary>
+              <secondary>and MySQL Cluster</secondary>
+            </indexterm>
 
-              <indexterm>
-                <primary>firewalls (software)</primary>
-                <secondary>and MySQL Cluster</secondary>
-              </indexterm>
+            It is also possible to employ a combination of the first two
+            methods, using both hardware and software to secure the
+            cluster&mdash;that is, using both network-based and
+            host-based firewalls. This is between the first two schemes
+            in terms of both security level and cost. This type of
+            network setup keeps the cluster behind the hardware
+            firewall, but permits incoming packets to travel beyond the
+            router connecting all cluster hosts to reach the SQL nodes.
+          </para>
 
-              It is also possible to employ a combination of the first
-              two methods, using both hardware and software to secure
-              the cluster&mdash;that is, using both network-based and
-              host-based firewalls. This is between the first two
-              schemes in terms of both security level and cost. This
-              type of network setup keeps the cluster behind the
-              hardware firewall, but permits incoming packets to travel
-              beyond the router connecting all cluster hosts to reach
-              the SQL nodes.
-            </para>
+          <para>
+            One possible network deployment of a MySQL Cluster using
+            hardware and software firewalls in combination is shown
+            here:
+          </para>
 
-            <para>
-              One possible network deployment of a MySQL Cluster using
-              hardware and software firewalls in combination is shown
-              here:
+          <mediaobject>
+            <imageobject>
+              <imagedata contentwidth="550" contentdepth="410" fileref="../refman-common/images/published/cluster-security-network-3.png" format="PNG"/>
+            </imageobject>
+            <textobject>
+              <phrase lang="en">Network setup for MySQL Cluster using a
+              combination of hardware and software firewalls to provide
+              protection</phrase>
+            </textobject>
+          </mediaobject>
 
-              <mediaobject>
-                <imageobject>
-                  <imagedata contentwidth="550" contentdepth="410" fileref="../refman-common/images/published/cluster-security-network-3.png" format="PNG"/>
-                </imageobject>
-                <textobject>
-                  <phrase lang="en">Network setup for MySQL Cluster
-                  using a combination of hardware and software firewalls
-                  to provide protection</phrase>
-                </textobject>
-              </mediaobject>
+          <para>
+            In this case, you can set the rules in the hardware firewall
+            to deny any external traffic except to SQL nodes and API
+            nodes, and then permit traffic to them only on the ports
+            required by your application.
+          </para>
+        </listitem>
 
-              In this case, you can set the rules in the hardware
-              firewall to deny any external traffic except to SQL nodes
-              and API nodes, and then permit traffic to them only on the
-              ports required by your application.
-            </para>
-          </listitem>
+      </orderedlist>
 
-        </orderedlist>
-
+      <para>
         Whatever network configuration you use, remember that your
         objective from the viewpoint of keeping the cluster secure
         remains the same&mdash;to prevent any unessential traffic from

@@ -8324,12 +8321,14 @@
         on server <emphasis role="bold">A</emphasis> that creates a new
         user <literal>jon@localhost</literal> and grants this user the
         <literal role="priv">SELECT</literal> privilege on that table:
+      </para>
 
 <programlisting>
 mysql&gt; <userinput>GRANT SELECT ON mydb.mytable</userinput>
     -&gt;   <userinput>TO jon@localhost IDENTIFIED BY 'mypass';</userinput>
 </programlisting>
 
+      <para>
         This user is <emphasis>not</emphasis> created on server
         <emphasis role="bold">B</emphasis>. For this to take place, the
         statement must also be run on server

@@ -8374,177 +8373,182 @@
         of the <filename>config.ini</filename> file, this account can be
         especially dangerous. To understand why, consider the following
         scenario:
+      </para>
 
-        <itemizedlist>
+      <itemizedlist>
 
-          <listitem>
-            <para>
-              The <filename>config.ini</filename> file contains at least
-              one empty <literal>[mysqld]</literal> or
-              <literal>[api]</literal> section. This means that the
-              Cluster management server performs no checking of the host
-              from which a MySQL Server (or other API node) accesses the
-              MySQL Cluster.
-            </para>
-          </listitem>
+        <listitem>
+          <para>
+            The <filename>config.ini</filename> file contains at least
+            one empty <literal>[mysqld]</literal> or
+            <literal>[api]</literal> section. This means that the
+            Cluster management server performs no checking of the host
+            from which a MySQL Server (or other API node) accesses the
+            MySQL Cluster.
+          </para>
+        </listitem>
 
-          <listitem>
-            <para>
-              There is no firewall, or the firewall fails to protect
-              against access to the Cluster from hosts external to the
-              network.
-            </para>
-          </listitem>
+        <listitem>
+          <para>
+            There is no firewall, or the firewall fails to protect
+            against access to the Cluster from hosts external to the
+            network.
+          </para>
+        </listitem>
 
-          <listitem>
-            <para>
-              The host name or IP address of the Cluster's management
-              server is known or can be determined from outside the
-              network.
-            </para>
-          </listitem>
+        <listitem>
+          <para>
+            The host name or IP address of the Cluster's management
+            server is known or can be determined from outside the
+            network.
+          </para>
+        </listitem>
 
-        </itemizedlist>
+      </itemizedlist>
 
+      <para>
         If these conditions are true, then anyone, anywhere can start a
         MySQL Server with <option>--ndbcluster
         --ndb-connectstring=<replaceable>management_host</replaceable></option>
         and access the Cluster. Using the MySQL <literal>root</literal>
         account, this person can then perform the following actions:
+      </para>
 
-        <itemizedlist>
+      <itemizedlist>
 
-          <listitem>
-            <para>
-              Execute a <literal role="stmt">SHOW DATABASES</literal>
-              statement to obtain a list of all databases that exist in
-              the cluster
-            </para>
-          </listitem>
+        <listitem>
+          <para>
+            Execute a <literal role="stmt">SHOW DATABASES</literal>
+            statement to obtain a list of all databases that exist in
+            the cluster
+          </para>
+        </listitem>
 
-          <listitem>
-            <para>
-              Execute a <literal>SHOW TABLES FROM
-              <replaceable>some_database</replaceable></literal>
-              statement to obtain a list of all
-              <literal role="se">NDB</literal> tables in a given
-              database
-            </para>
-          </listitem>
+        <listitem>
+          <para>
+            Execute a <literal>SHOW TABLES FROM
+            <replaceable>some_database</replaceable></literal> statement
+            to obtain a list of all <literal role="se">NDB</literal>
+            tables in a given database
+          </para>
+        </listitem>
 
-          <listitem>
-            <para>
-              <indexterm>
-                <primary>malicious SQL statements</primary>
-                <secondary>and MySQL Cluster</secondary>
-              </indexterm>
+        <listitem>
+          <para>
+            <indexterm>
+              <primary>malicious SQL statements</primary>
+              <secondary>and MySQL Cluster</secondary>
+            </indexterm>
 
-              <indexterm>
-                <primary>security</primary>
-                <secondary>and malicious SQL statements</secondary>
-              </indexterm>
+            <indexterm>
+              <primary>security</primary>
+              <secondary>and malicious SQL statements</secondary>
+            </indexterm>
 
-              Run any legal MySQL statements on any of those tables,
-              such as:
+            Run any legal MySQL statements on any of those tables, such
+            as:
+          </para>
 
-              <itemizedlist>
+          <itemizedlist>
 
-                <listitem>
-                  <para>
-                    <literal>SELECT * FROM
-                    <replaceable>some_table</replaceable></literal> to
-                    read all the data from any table
-                  </para>
-                </listitem>
+            <listitem>
+              <para>
+                <literal>SELECT * FROM
+                <replaceable>some_table</replaceable></literal> to read
+                all the data from any table
+              </para>
+            </listitem>
 
-                <listitem>
-                  <para>
-                    <literal>DELETE FROM
-                    <replaceable>some_table</replaceable></literal> to
-                    delete all the data from a table
-                  </para>
-                </listitem>
+            <listitem>
+              <para>
+                <literal>DELETE FROM
+                <replaceable>some_table</replaceable></literal> to
+                delete all the data from a table
+              </para>
+            </listitem>
 
-                <listitem>
-                  <para>
-                    <literal>DESCRIBE
-                    <replaceable>some_table</replaceable></literal> or
-                    <literal>SHOW CREATE TABLE
-                    <replaceable>some_table</replaceable></literal> to
-                    determine the table schema
-                  </para>
-                </listitem>
+            <listitem>
+              <para>
+                <literal>DESCRIBE
+                <replaceable>some_table</replaceable></literal> or
+                <literal>SHOW CREATE TABLE
+                <replaceable>some_table</replaceable></literal> to
+                determine the table schema
+              </para>
+            </listitem>
 
-                <listitem>
-                  <para>
-                    <literal>UPDATE
-                    <replaceable>some_table</replaceable> SET
-                    <replaceable>column1</replaceable> =
-                    <replaceable>any_value1</replaceable></literal> to
-                    fill a table column with <quote>garbage</quote>
-                    data; this could actually cause much greater damage
-                    than simply deleting all the data
-                  </para>
+            <listitem>
+              <para>
+                <literal>UPDATE <replaceable>some_table</replaceable>
+                SET <replaceable>column1</replaceable> =
+                <replaceable>any_value1</replaceable></literal> to fill
+                a table column with <quote>garbage</quote> data; this
+                could actually cause much greater damage than simply
+                deleting all the data
+              </para>
 
-                  <para>
-                    Even more insidious variations might include
-                    statements like these:
+              <para>
+                Even more insidious variations might include statements
+                like these:
+              </para>
 
 <programlisting>
 UPDATE <replaceable>some_table</replaceable> SET <replaceable>an_int_column</replaceable> = <replaceable>an_int_column</replaceable> + 1
 </programlisting>
 
-                    or
+              <para>
+                or
+              </para>
 
 <programlisting>
 UPDATE <replaceable>some_table</replaceable> SET <replaceable>a_varchar_column</replaceable> = REVERSE(<replaceable>a_varchar_column</replaceable>)
 </programlisting>
 
-                    Such malicious statements are limited only by the
-                    imagination of the attacker.
-                  </para>
-                </listitem>
+              <para>
+                Such malicious statements are limited only by the
+                imagination of the attacker.
+              </para>
+            </listitem>
 
-              </itemizedlist>
+          </itemizedlist>
 
-              The only tables that would be safe from this sort of
-              mayhem would be those tables that were created using
-              storage engines other than
-              <literal role="se">NDB</literal>, and so not visible to a
-              <quote>rogue</quote> SQL node.
-            </para>
+          <para>
+            The only tables that would be safe from this sort of mayhem
+            would be those tables that were created using storage
+            engines other than <literal role="se">NDB</literal>, and so
+            not visible to a <quote>rogue</quote> SQL node.
+          </para>
 
-            <note>
-              <para>
-                <indexterm>
-                  <primary>INFORMATION_SCHEMA</primary>
-                  <secondary>and security issues</secondary>
-                </indexterm>
+          <note>
+            <para>
+              <indexterm>
+                <primary>INFORMATION_SCHEMA</primary>
+                <secondary>and security issues</secondary>
+              </indexterm>
 
-                <indexterm>
-                  <primary>MySQL Cluster</primary>
-                  <secondary>and INFORMATION_SCHEMA</secondary>
-                </indexterm>
+              <indexterm>
+                <primary>MySQL Cluster</primary>
+                <secondary>and INFORMATION_SCHEMA</secondary>
+              </indexterm>
 
-                A user who can log in as <literal>root</literal> can
-                also access the <literal>INFORMATION_SCHEMA</literal>
-                database and its tables, and so obtain information about
-                databases, tables, stored routines, scheduled events,
-                and any other database objects for which metadata is
-                stored in <literal>INFORMATION_SCHEMA</literal>.
-              </para>
-            </note>
-
-            <para>
-              It is also a very good idea to use different passwords for
-              the <literal>root</literal> accounts on different cluster
-              SQL nodes.
+              A user who can log in as <literal>root</literal> can also
+              access the <literal>INFORMATION_SCHEMA</literal> database
+              and its tables, and so obtain information about databases,
+              tables, stored routines, scheduled events, and any other
+              database objects for which metadata is stored in
+              <literal>INFORMATION_SCHEMA</literal>.
             </para>
-          </listitem>
+          </note>
 
-        </itemizedlist>
-      </para>
+          <para>
+            It is also a very good idea to use different passwords for
+            the <literal>root</literal> accounts on different cluster
+            SQL nodes.
+          </para>
+        </listitem>
 
+      </itemizedlist>
+
       <para>
         In sum, you cannot have a safe MySQL Cluster if it is directly
         accessible from outside your local network.

@@ -8590,37 +8594,37 @@
         <para>
           The two most important points to remember regarding the MySQL
           privilege system with regard to MySQL Cluster are:
+        </para>
 
-          <orderedlist>
+      </formalpara>
 
-            <listitem>
-              <para>
-                Users and privileges established on one SQL node do not
-                automatically exist or take effect on other SQL nodes in
-                the cluster.
-              </para>
+      <orderedlist>
 
-              <para>
-                Conversely, removing a user or privilege on one SQL node
-                in the cluster does not remove the user or privilege
-                from any other SQL nodes.
-              </para>
-            </listitem>
+        <listitem>
+          <para>
+            Users and privileges established on one SQL node do not
+            automatically exist or take effect on other SQL nodes in the
+            cluster.
+          </para>
 
-            <listitem>
-              <para>
-                Once a MySQL user is granted privileges on an
-                <literal role="se">NDB</literal> table from one SQL node
-                in a MySQL Cluster, that user can <quote>see</quote> any
-                data in that table regardless of the SQL node from which
-                the data originated.
-              </para>
-            </listitem>
+          <para>
+            Conversely, removing a user or privilege on one SQL node in
+            the cluster does not remove the user or privilege from any
+            other SQL nodes.
+          </para>
+        </listitem>
 
-          </orderedlist>
-        </para>
+        <listitem>
+          <para>
+            Once a MySQL user is granted privileges on an
+            <literal role="se">NDB</literal> table from one SQL node in
+            a MySQL Cluster, that user can <quote>see</quote> any data
+            in that table regardless of the SQL node from which the data
+            originated.
+          </para>
+        </listitem>
 
-      </formalpara>
+      </orderedlist>
 
     </section>
 

@@ -8654,6 +8658,7 @@
         that the <command>mysqld</command> process is running as the
         system user <literal>mysql</literal> by using the system command
         such as the one shown here:
+      </para>
 
 <programlisting>
 shell&gt; <userinput>ps aux | grep mysql</userinput>

@@ -8667,6 +8672,7 @@
 jon      10579  0.0  0.0   2736   688 pts/0    S+   11:54   0:00 grep mysql
 </programlisting>
 
+      <para>
         If the <command>mysqld</command> process is running as any other
         user than <literal>mysql</literal>, you should immediately shut
         it down and restart it as the <literal>mysql</literal> user. If

@@ -8708,6 +8714,7 @@
         as you have it running. You should also delete the anonymous
         user account that is installed by default. You can accomplish
         these tasks using the following statements:
+      </para>
 
 <programlisting>
 shell&gt; <userinput>mysql -u root</userinput>

@@ -8722,6 +8729,7 @@
 mysql&gt; <userinput>FLUSH PRIVILEGES;</userinput>
 </programlisting>
 
+      <para>
         Be very careful when executing the
         <literal role="stmt">DELETE</literal> statement not to omit the
         <literal>WHERE</literal> clause, or you risk deleting


Modified: trunk/refman-5.1/mysql-cluster-management.xml
===================================================================
--- trunk/refman-5.1/mysql-cluster-management.xml	2011-04-11 15:58:04 UTC (rev 25827)
+++ trunk/refman-5.1/mysql-cluster-management.xml	2011-04-11 16:31:37 UTC (rev 25828)
Changed blocks: 7, Lines Added: 68, Lines Deleted: 63; 7574 bytes

@@ -1115,7 +1115,7 @@
           <literal>DROP NODEGROUP</literal> works only when all data
           nodes in the node group to be dropped are completely empty of
           any table data and table definitions. Since there is currently
-          no way using <command>ndb_mgm</command> or in the
+          no way using <command>ndb_mgm</command> or the
           <command>mysql</command> client to remove all data from a
           specific data node or node group, this means that the command
           succeeds only in the two following cases:

@@ -4738,9 +4738,8 @@
                     <xref linkend="mysql-cluster-start-phases"/>.
                     (<replaceable>type</replaceable> is one of
                     <literal>initial</literal>,
-                    <literal role="jointype">system</literal>,
-                    <literal>node</literal>, <literal>initial
-                    node</literal>, or
+                    <literal>system</literal>, <literal>node</literal>,
+                    <literal>initial node</literal>, or
                     <literal>&lt;Unknown&gt;</literal>.)
                   </para>
 

@@ -8471,27 +8470,27 @@
         views generated from internal <literal role="se">NDB</literal>
         tables not visible to the MySQL Server.
       </para>
+    </note>
 
-      <para>
-        All <literal>ndbinfo</literal> tables are read-only.
-      </para>
+    <para>
+      All <literal>ndbinfo</literal> tables are read-only.
+    </para>
 
-      <indexterm>
-        <primary>ndbinfo database</primary>
-        <secondary>and query cache</secondary>
-      </indexterm>
+    <indexterm>
+      <primary>ndbinfo database</primary>
+      <secondary>and query cache</secondary>
+    </indexterm>
 
-      <indexterm>
-        <primary>query cache</primary>
-        <secondary>and ndbinfo database tables</secondary>
-      </indexterm>
+    <indexterm>
+      <primary>query cache</primary>
+      <secondary>and ndbinfo database tables</secondary>
+    </indexterm>
 
-      <para>
-        Beginning with MySQL Cluster NDB 7.0.22 and MySQL Cluster NDB
-        7.1.11, <literal>ndbinfo</literal> tables are not included in
-        the query cache. (Bug#59831)
-      </para>
-    </note>
+    <para>
+      Beginning with MySQL Cluster NDB 7.0.22 and MySQL Cluster NDB
+      7.1.11, <literal>ndbinfo</literal> tables are not included in the
+      query cache. (Bug#59831)
+    </para>
 
     <para>
       You can select the <literal>ndbinfo</literal> database with a

@@ -10738,66 +10737,68 @@
 
             Run any legal MySQL statements on any of those tables, such
             as:
+          </para>
 
-            <itemizedlist>
+          <itemizedlist>
 
-              <listitem>
-                <para>
-                  <literal>SELECT * FROM
-                  <replaceable>some_table</replaceable></literal> to
-                  read all the data from any table
-                </para>
-              </listitem>
+            <listitem>
+              <para>
+                <literal>SELECT * FROM
+                <replaceable>some_table</replaceable></literal> to read
+                all the data from any table
+              </para>
+            </listitem>
 
-              <listitem>
-                <para>
-                  <literal>DELETE FROM
-                  <replaceable>some_table</replaceable></literal> to
-                  delete all the data from a table
-                </para>
-              </listitem>
+            <listitem>
+              <para>
+                <literal>DELETE FROM
+                <replaceable>some_table</replaceable></literal> to
+                delete all the data from a table
+              </para>
+            </listitem>
 
-              <listitem>
-                <para>
-                  <literal>DESCRIBE
-                  <replaceable>some_table</replaceable></literal> or
-                  <literal>SHOW CREATE TABLE
-                  <replaceable>some_table</replaceable></literal> to
-                  determine the table schema
-                </para>
-              </listitem>
+            <listitem>
+              <para>
+                <literal>DESCRIBE
+                <replaceable>some_table</replaceable></literal> or
+                <literal>SHOW CREATE TABLE
+                <replaceable>some_table</replaceable></literal> to
+                determine the table schema
+              </para>
+            </listitem>
 
-              <listitem>
-                <para>
-                  <literal>UPDATE <replaceable>some_table</replaceable>
-                  SET <replaceable>column1</replaceable> =
-                  <replaceable>any_value1</replaceable></literal> to
-                  fill a table column with <quote>garbage</quote> data;
-                  this could actually cause much greater damage than
-                  simply deleting all the data
-                </para>
+            <listitem>
+              <para>
+                <literal>UPDATE <replaceable>some_table</replaceable>
+                SET <replaceable>column1</replaceable> =
+                <replaceable>any_value1</replaceable></literal> to fill
+                a table column with <quote>garbage</quote> data; this
+                could actually cause much greater damage than simply
+                deleting all the data
+              </para>
 
-                <para>
-                  Even more insidious variations might include
-                  statements like these:
+              <para>
+                Even more insidious variations might include statements
+                like these:
 
 <programlisting>
 UPDATE <replaceable>some_table</replaceable> SET <replaceable>an_int_column</replaceable> = <replaceable>an_int_column</replaceable> + 1
 </programlisting>
 
-                  or
+                or
 
 <programlisting>
 UPDATE <replaceable>some_table</replaceable> SET <replaceable>a_varchar_column</replaceable> = REVERSE(<replaceable>a_varchar_column</replaceable>)
 </programlisting>
 
-                  Such malicious statements are limited only by the
-                  imagination of the attacker.
-                </para>
-              </listitem>
+                Such malicious statements are limited only by the
+                imagination of the attacker.
+              </para>
+            </listitem>
 
-            </itemizedlist>
+          </itemizedlist>
 
+          <para>
             The only tables that would be safe from this sort of mayhem
             would be those tables that were created using storage
             engines other than <literal role="se">NDB</literal>, and so

@@ -11783,6 +11784,7 @@
           <para>
             Under the data node file system create symbolic links
             pointing to the other drives:
+          </para>
 
 <programlisting>
 shell&gt; <userinput>cd /data0/ndb_2_fs</userinput>

@@ -11792,7 +11794,9 @@
 shell&gt; <userinput>ln -s /data1 dndata</userinput>
 </programlisting>
 
+          <para>
             You should now have two symbolic links:
+          </para>
 
 <programlisting>
 shell&gt; <userinput>ls -l --hide=D*</userinput>

@@ -11800,6 +11804,7 @@
 lrwxrwxrwx 1 user group   30 2007-03-19 13:59 dnlogs -> /data2
 </programlisting>
 
+          <para>
             We show this only for the data node with node ID 2; however,
             you must do this for <emphasis>each</emphasis> data node.
           </para>


Thread
svn commit - mysqldoc@oter02: r25828 - in trunk: refman-5.0 refman-5.1jon.stephens11 Apr