List:Commits« Previous MessageNext Message »
From:jon Date:January 15 2006 5:29am
Subject:svn commit - mysqldoc@docsrva: r842 - in trunk: refman-4.1 refman-5.0 refman-5.1
View as plain text  
Author: jstephens
Date: 2006-01-15 06:29:22 +0100 (Sun, 15 Jan 2006)
New Revision: 842

Log:

Reformat.



Modified:
   trunk/refman-4.1/ndbcluster.xml
   trunk/refman-5.0/ndbcluster.xml
   trunk/refman-5.1/ndbcluster.xml

Modified: trunk/refman-4.1/ndbcluster.xml
===================================================================
--- trunk/refman-4.1/ndbcluster.xml	2006-01-15 05:24:34 UTC (rev 841)
+++ trunk/refman-4.1/ndbcluster.xml	2006-01-15 05:29:22 UTC (rev 842)
@@ -256,11 +256,11 @@
       </listitem>
 
     </itemizedlist>
-    
+
     <para>
       For a brief introduction to the relationships between nodes, node
-      groups, replicas, and partitions in MySQL Cluster, see 
-      <xref linkend="mysql-cluster-nodes-groups"/>. 
+      groups, replicas, and partitions in MySQL Cluster, see
+      <xref linkend="mysql-cluster-nodes-groups"/>.
     </para>
 
     <para>
@@ -361,171 +361,176 @@
     </remark>
 
     <section id="mysql-cluster-nodes-groups">
+
       <title>&title-mysql-cluster-nodes-groups;</title>
-  
-  <remark role="note">
-    Author: Jon Stephens, with valuable assistance from Tomas Ulin, Jeb
-    Miller, and Hartmut Holzgraefe
-  </remark>
-  
-  <para>
-    This section discusses the manner in which MySQL Cluster divides
-    and duplicates data for storage and its implications for CLuster
-    memory requirements.
-  </para>
-  
-  <para>
-    <emphasis role="bold">Concepts</emphasis>
-  </para>
-  
-  <para>
-    Central to an understanding of this topic are the following
-    concepts, listed here with brief definitions:
-  </para>
-  
-  <itemizedlist>
-    <listitem>
+
+      <remark role="note">
+        Author: Jon Stephens, with valuable assistance from Tomas Ulin,
+        Jeb Miller, and Hartmut Holzgraefe
+      </remark>
+
       <para>
-        <emphasis role="bold">(Data) Node</emphasis>: An
-        <command>ndbd</command> process, which stores a
-        <firstterm>replica</firstterm> &mdash;that is, a copy of the
-        <firstterm>partition</firstterm> (see below) assigned to the
-        node group of which the node is a member.
+        This section discusses the manner in which MySQL Cluster divides
+        and duplicates data for storage and its implications for CLuster
+        memory requirements.
       </para>
-      
+
       <para>
-        Each data node is usually located on a separate computer.
-        However, it is also possible to host multiple data nodes on a
-        single computer having more than one processor. In such cases,
-        it is feasible to run one instance of <command>ndbd</command>
-        per physical CPU. (Note that a processor with multiple cores is
-        still a single processor.)
+        <emphasis role="bold">Concepts</emphasis>
       </para>
-      
+
       <para>
-        It is common for the terms <quote>node</quote> and <quote>data
-          node</quote> to be used interchangeably when referring to an
-        <command>ndbd</command> process; where mentioned, management
-        nodes (<command>ndb_mgmd</command> processes) and SQL nodes
-        (<command>mysqld</command> processes) are specified as such in
-        this discussion.
+        Central to an understanding of this topic are the following
+        concepts, listed here with brief definitions:
       </para>
-    </listitem>
-    
-    <listitem>
+
+      <itemizedlist>
+
+        <listitem>
+          <para>
+            <emphasis role="bold">(Data) Node</emphasis>: An
+            <command>ndbd</command> process, which stores a
+            <firstterm>replica</firstterm> &mdash;that is, a copy of the
+            <firstterm>partition</firstterm> (see below) assigned to the
+            node group of which the node is a member.
+          </para>
+
+          <para>
+            Each data node is usually located on a separate computer.
+            However, it is also possible to host multiple data nodes on
+            a single computer having more than one processor. In such
+            cases, it is feasible to run one instance of
+            <command>ndbd</command> per physical CPU. (Note that a
+            processor with multiple cores is still a single processor.)
+          </para>
+
+          <para>
+            It is common for the terms <quote>node</quote> and
+            <quote>data node</quote> to be used interchangeably when
+            referring to an <command>ndbd</command> process; where
+            mentioned, management nodes (<command>ndb_mgmd</command>
+            processes) and SQL nodes (<command>mysqld</command>
+            processes) are specified as such in this discussion.
+          </para>
+        </listitem>
+
+        <listitem>
+          <para>
+            <emphasis role="bold">Node Group</emphasis>: A node group
+            consists of one or more nodes, and stores a partition, or
+            set of <firstterm>replicas</firstterm> (see next item).
+          </para>
+
+          <para>
+            <emphasis role="bold">Note</emphasis>: Currently, all node
+            groups in a cluster must have the same number of nodes.
+          </para>
+        </listitem>
+
+        <listitem>
+          <para>
+            <emphasis role="bold">Partition</emphasis>: This is a
+            portion of the data stored by the cluster. There are as many
+            cluster partitions as node groups participating in the
+            cluster, and each node group is responible for keeping at
+            least one copy of the partition assigned to it (that, at
+            least one replica) available to the cluster.
+          </para>
+        </listitem>
+
+        <listitem>
+          <para>
+            <emphasis role="bold">Replica</emphasis>: This is a copy of
+            a cluster partition. Each node in a node group stores a
+            replica. Also sometimes known as a <firstterm>partition
+            replica</firstterm>.
+          </para>
+        </listitem>
+
+      </itemizedlist>
+
       <para>
-        <emphasis role="bold">Node Group</emphasis>: A node group
-        consists of one or more nodes, and stores a partition, or set of
-        <firstterm>replicas</firstterm> (see next item). 
+        The following diagram illustrates a MySQL Cluster with four data
+        nodes, arranged in two node groups of two nodes each. Note that
+        no nodes other than data nodes are shown here, although a
+        working cluster requires an <command>ndb_mgm</command> process
+        for cluster management and at least one SQL node in order to
+        access the data stored by the cluster.
       </para>
-      
+
+      <mediaobject>
+        <imageobject>
+          <imagedata fileref="images/replicas-groups-1-1.png" format="PNG"/>
+        </imageobject>
+        <textobject>
+          <phrase lang="en">A MySQL Cluster, with 2 node groups having 2
+          nodes each</phrase>
+        </textobject>
+      </mediaobject>
+
       <para>
-        <emphasis role="bold">Note</emphasis>: Currently, all node
-        groups in a cluster must have the same number of nodes.
+        The data stored by the cluster is divided into two partitions,
+        labeled <emphasis role="bold">A</emphasis> and
+        <emphasis role="bold">B</emphasis> in the diagram. Each
+        partition is stored &mdash; in multiple copies &mdash; on a node
+        group. The data making up Partition
+        <emphasis role="bold">A</emphasis> is stored on Node
+        <emphasis role="bold">A-1</emphasis>, and this data is identical
+        to that stored by Node <emphasis role="bold">A-2</emphasis>. The
+        data stored by Nodes <emphasis role="bold">B-1</emphasis> and
+        <emphasis role="bold">B-2</emphasis> is also the same &mdash;
+        these two nodes store identical copies of the data making up
+        Partition <emphasis role="bold">B</emphasis>.
       </para>
-    </listitem>
-    
-    <listitem>
+
       <para>
-        <emphasis role="bold">Partition</emphasis>: This is a portion of
-        the data stored by the cluster. There are as many cluster
-        partitions as node groups participating in the cluster, and each
-        node group is responible for keeping at least one copy of the
-        partition assigned to it (that, at least one replica) available
-        to the cluster.
+        What this means so far as the continued operation of a MySQL
+        Cluster is this: so long as each node group participating in the
+        cluster has at least one <quote>live</quote> node, the cluster
+        has a complete copy of all data and remains viable. This is
+        illustrated in the next diagram.
       </para>
-    </listitem>
-    
-    <listitem>
+
+      <remark role="todo">
+        [js] Not a very good caption; think of a better one.
+      </remark>
+
+      <mediaobject>
+        <imageobject>
+          <imagedata fileref="images/replicas-groups-1-2.png" format="PNG"/>
+        </imageobject>
+        <textobject>
+          <phrase lang="en">Nodes required to keep a 2x2 cluster
+          viable</phrase>
+        </textobject>
+      </mediaobject>
+
       <para>
-        <emphasis role="bold">Replica</emphasis>: This is a copy of a
-        cluster partition. Each node in a node group stores a replica.
-        Also sometimes known as a <firstterm>partition
-          replica</firstterm>.
+        In this example, where the cluster consists of two node groups
+        of two nodes each, any combination of at least one node in Node
+        Group <emphasis role="bold">A</emphasis> and at least one node
+        in Node Group <emphasis role="bold">B</emphasis> is sufficient
+        to keep the cluster <quote>alive</quote> (indicated by arrows in
+        the diagram). However, if both nodes from either node group
+        fail, the remaining two nodes are not sufficient (shown by
+        arrows marked out with an <emphasis role="bold">X</emphasis>);
+        in either case, the cluster has lost an entire partition and so
+        can no longer provide access to a complete set of all cluster
+        data.
       </para>
-    </listitem>
-  </itemizedlist>
-  
-  <para>
-    The following diagram illustrates a MySQL Cluster with four data
-    nodes, arranged in two node groups of two nodes each. Note that no
-    nodes other than data nodes are shown here, although a working
-    cluster requires an <command>ndb_mgm</command> process for cluster
-    management and at least one SQL node in order to access the data
-    stored by the cluster.
-  </para>
 
-  <mediaobject>
-    <imageobject>
-      <imagedata fileref="images/replicas-groups-1-1.png" format="PNG"/>
-    </imageobject>
-    <textobject>
-      <phrase lang="en">A MySQL Cluster, with 2 node groups having 2
-        nodes each</phrase>
-    </textobject>
-  </mediaobject>
-  
-  <para>
-    The data stored by the cluster is divided into two partitions,
-    labeled <emphasis role="bold">A</emphasis> and 
-    <emphasis role="bold">B</emphasis> in the diagram. Each partition is
-    stored &mdash; in multiple copies &mdash; on a node group. The data
-    making up Partition <emphasis role="bold">A</emphasis> is stored on
-    Node <emphasis role="bold">A-1</emphasis>, and this data is
-    identical to that stored by Node 
-    <emphasis role="bold">A-2</emphasis>. The data stored by Nodes
-    <emphasis role="bold">B-1</emphasis> and 
-    <emphasis role="bold">B-2</emphasis> is also the same &mdash; these
-    two nodes store identical copies of the data making up Partition
-    <emphasis role="bold">B</emphasis>.
-  </para>
-  
-  <para>
-    What this means so far as the continued operation of a MySQL
-    Cluster is this: so long as each node group participating in the
-    cluster has at least one <quote>live</quote> node, the cluster has a
-    complete copy of all data and remains viable. This is illustrated in
-    the next diagram.
-  </para>
-  
-  <remark role="todo">
-    [js] Not a very good caption; think of a better one.
-  </remark>
-
-  <mediaobject>
-    <imageobject>
-      <imagedata fileref="images/replicas-groups-1-2.png" format="PNG"/>
-    </imageobject>
-    <textobject>
-      <phrase lang="en">Nodes required to keep a 2x2 cluster viable</phrase>
-    </textobject>
-  </mediaobject>
-  
-  <para>
-    In this example, where the cluster consists of two node groups of
-    two nodes each, any combination of at least one node in Node Group
-    <emphasis role="bold">A</emphasis> and at least one node in Node
-    Group <emphasis role="bold">B</emphasis> is sufficient to keep the
-    cluster <quote>alive</quote> (indicated by arrows in the diagram).
-    However, if both nodes from either node group fail, the remaining
-    two nodes are not sufficient (shown by arrows marked out with an
-    <emphasis role="bold">X</emphasis>); in either case, the cluster has    
-    lost an entire partition and so can no longer provide access to a
-    complete set of all cluster data.
-  </para>
-      
       <remark role="todo">
         [js] Add discussion of application of the above to hosts running
         multiple CPUs.
       </remark>
-      
+
       <remark role="todo">
         [js] Add description of memory requirements based on Hartmut's
         example scripts.
       </remark>
+
     </section>
-    
-    
+
   </section>
 
   <section id="multi-computer">
@@ -2604,7 +2609,7 @@
                       old logfile is renamed by appending
                       <filename>.x</filename> to the filename, where
                       <literal>x</literal> is the next number not yet
-                      used with this name. 
+                      used with this name.
                     </para>
                   </listitem>
 

Modified: trunk/refman-5.0/ndbcluster.xml
===================================================================
--- trunk/refman-5.0/ndbcluster.xml	2006-01-15 05:24:34 UTC (rev 841)
+++ trunk/refman-5.0/ndbcluster.xml	2006-01-15 05:29:22 UTC (rev 842)
@@ -258,8 +258,8 @@
 
     <para>
       For a brief introduction to the relationships between nodes, node
-      groups, replicas, and partitions in MySQL Cluster, see 
-      <xref linkend="mysql-cluster-nodes-groups"/>. 
+      groups, replicas, and partitions in MySQL Cluster, see
+      <xref linkend="mysql-cluster-nodes-groups"/>.
     </para>
 
     <para>
@@ -359,172 +359,177 @@
       @subsection How MySQL Cluster Avoids Network Partitioning
     </remark>
 
-  <section id="mysql-cluster-nodes-groups">
+    <section id="mysql-cluster-nodes-groups">
+
       <title>&title-mysql-cluster-nodes-groups;</title>
-  
-  <remark role="note">
-    Author: Jon Stephens, with valuable assistance from Tomas Ulin, Jeb
-    Miller, and Hartmut Holzgraefe
-  </remark>
-  
-  <para>
-    This section discusses the manner in which MySQL Cluster divides
-    and duplicates data for storage and its implications for CLuster
-    memory requirements.
-  </para>
-  
-  <para>
-    <emphasis role="bold">Concepts</emphasis>
-  </para>
-  
-  <para>
-    Central to an understanding of this topic are the following
-    concepts, listed here with brief definitions:
-  </para>
-  
-  <itemizedlist>
-    <listitem>
+
+      <remark role="note">
+        Author: Jon Stephens, with valuable assistance from Tomas Ulin,
+        Jeb Miller, and Hartmut Holzgraefe
+      </remark>
+
       <para>
-        <emphasis role="bold">(Data) Node</emphasis>: An
-        <command>ndbd</command> process, which stores a
-        <firstterm>replica</firstterm> &mdash;that is, a copy of the
-        <firstterm>partition</firstterm> (see below) assigned to the
-        node group of which the node is a member.
+        This section discusses the manner in which MySQL Cluster divides
+        and duplicates data for storage and its implications for CLuster
+        memory requirements.
       </para>
-      
+
       <para>
-        Each data node is usually located on a separate computer.
-        However, it is also possible to host multiple data nodes on a
-        single computer having more than one processor. In such cases,
-        it is feasible to run one instance of <command>ndbd</command>
-        per physical CPU. (Note that a processor with multiple cores is
-        still a single processor.)
+        <emphasis role="bold">Concepts</emphasis>
       </para>
-      
+
       <para>
-        It is common for the terms <quote>node</quote> and <quote>data
-          node</quote> to be used interchangeably when referring to an
-        <command>ndbd</command> process; where mentioned, management
-        nodes (<command>ndb_mgmd</command> processes) and SQL nodes
-        (<command>mysqld</command> processes) are specified as such in
-        this discussion.
+        Central to an understanding of this topic are the following
+        concepts, listed here with brief definitions:
       </para>
-    </listitem>
-    
-    <listitem>
+
+      <itemizedlist>
+
+        <listitem>
+          <para>
+            <emphasis role="bold">(Data) Node</emphasis>: An
+            <command>ndbd</command> process, which stores a
+            <firstterm>replica</firstterm> &mdash;that is, a copy of the
+            <firstterm>partition</firstterm> (see below) assigned to the
+            node group of which the node is a member.
+          </para>
+
+          <para>
+            Each data node is usually located on a separate computer.
+            However, it is also possible to host multiple data nodes on
+            a single computer having more than one processor. In such
+            cases, it is feasible to run one instance of
+            <command>ndbd</command> per physical CPU. (Note that a
+            processor with multiple cores is still a single processor.)
+          </para>
+
+          <para>
+            It is common for the terms <quote>node</quote> and
+            <quote>data node</quote> to be used interchangeably when
+            referring to an <command>ndbd</command> process; where
+            mentioned, management nodes (<command>ndb_mgmd</command>
+            processes) and SQL nodes (<command>mysqld</command>
+            processes) are specified as such in this discussion.
+          </para>
+        </listitem>
+
+        <listitem>
+          <para>
+            <emphasis role="bold">Node Group</emphasis>: A node group
+            consists of one or more nodes, and stores a partition, or
+            set of <firstterm>replicas</firstterm> (see next item).
+          </para>
+
+          <para>
+            <emphasis role="bold">Note</emphasis>: Currently, all node
+            groups in a cluster must have the same number of nodes.
+          </para>
+        </listitem>
+
+        <listitem>
+          <para>
+            <emphasis role="bold">Partition</emphasis>: This is a
+            portion of the data stored by the cluster. There are as many
+            cluster partitions as node groups participating in the
+            cluster, and each node group is responible for keeping at
+            least one copy of the partition assigned to it (that, at
+            least one replica) available to the cluster.
+          </para>
+        </listitem>
+
+        <listitem>
+          <para>
+            <emphasis role="bold">Replica</emphasis>: This is a copy of
+            a cluster partition. Each node in a node group stores a
+            replica. Also sometimes known as a <firstterm>partition
+            replica</firstterm>.
+          </para>
+        </listitem>
+
+      </itemizedlist>
+
       <para>
-        <emphasis role="bold">Node Group</emphasis>: A node group
-        consists of one or more nodes, and stores a partition, or set of
-        <firstterm>replicas</firstterm> (see next item). 
+        The following diagram illustrates a MySQL Cluster with four data
+        nodes, arranged in two node groups of two nodes each. Note that
+        no nodes other than data nodes are shown here, although a
+        working cluster requires an <command>ndb_mgm</command> process
+        for cluster management and at least one SQL node in order to
+        access the data stored by the cluster.
       </para>
-      
+
+      <mediaobject>
+        <imageobject>
+          <imagedata fileref="images/replicas-groups-1-1.png" format="PNG"/>
+        </imageobject>
+        <textobject>
+          <phrase lang="en">A MySQL Cluster, with 2 node groups having 2
+          nodes each</phrase>
+        </textobject>
+      </mediaobject>
+
       <para>
-        <emphasis role="bold">Note</emphasis>: Currently, all node
-        groups in a cluster must have the same number of nodes.
+        The data stored by the cluster is divided into two partitions,
+        labeled <emphasis role="bold">A</emphasis> and
+        <emphasis role="bold">B</emphasis> in the diagram. Each
+        partition is stored &mdash; in multiple copies &mdash; on a node
+        group. The data making up Partition
+        <emphasis role="bold">A</emphasis> is stored on Node
+        <emphasis role="bold">A-1</emphasis>, and this data is identical
+        to that stored by Node <emphasis role="bold">A-2</emphasis>. The
+        data stored by Nodes <emphasis role="bold">B-1</emphasis> and
+        <emphasis role="bold">B-2</emphasis> is also the same &mdash;
+        these two nodes store identical copies of the data making up
+        Partition <emphasis role="bold">B</emphasis>.
       </para>
-    </listitem>
-    
-    <listitem>
+
       <para>
-        <emphasis role="bold">Partition</emphasis>: This is a portion of
-        the data stored by the cluster. There are as many cluster
-        partitions as node groups participating in the cluster, and each
-        node group is responible for keeping at least one copy of the
-        partition assigned to it (that, at least one replica) available
-        to the cluster.
+        What this means so far as the continued operation of a MySQL
+        Cluster is this: so long as each node group participating in the
+        cluster has at least one <quote>live</quote> node, the cluster
+        has a complete copy of all data and remains viable. This is
+        illustrated in the next diagram.
       </para>
-    </listitem>
-    
-    <listitem>
+
+      <remark role="todo">
+        [js] Not a very good caption; think of a better one.
+      </remark>
+
+      <mediaobject>
+        <imageobject>
+          <imagedata fileref="images/replicas-groups-1-2.png" format="PNG"/>
+        </imageobject>
+        <textobject>
+          <phrase lang="en">Nodes required to keep a 2x2 cluster
+          viable</phrase>
+        </textobject>
+      </mediaobject>
+
       <para>
-        <emphasis role="bold">Replica</emphasis>: This is a copy of a
-        cluster partition. Each node in a node group stores a replica.
-        Also sometimes known as a <firstterm>partition
-          replica</firstterm>.
+        In this example, where the cluster consists of two node groups
+        of two nodes each, any combination of at least one node in Node
+        Group <emphasis role="bold">A</emphasis> and at least one node
+        in Node Group <emphasis role="bold">B</emphasis> is sufficient
+        to keep the cluster <quote>alive</quote> (indicated by arrows in
+        the diagram). However, if both nodes from either node group
+        fail, the remaining two nodes are not sufficient (shown by
+        arrows marked out with an <emphasis role="bold">X</emphasis>);
+        in either case, the cluster has lost an entire partition and so
+        can no longer provide access to a complete set of all cluster
+        data.
       </para>
-    </listitem>
-  </itemizedlist>
-  
-  <para>
-    The following diagram illustrates a MySQL Cluster with four data
-    nodes, arranged in two node groups of two nodes each. Note that no
-    nodes other than data nodes are shown here, although a working
-    cluster requires an <command>ndb_mgm</command> process for cluster
-    management and at least one SQL node in order to access the data
-    stored by the cluster.
-  </para>
 
-  <mediaobject>
-    <imageobject>
-      <imagedata fileref="images/replicas-groups-1-1.png" format="PNG"/>
-    </imageobject>
-    <textobject>
-      <phrase lang="en">A MySQL Cluster, with 2 node groups having 2
-        nodes each</phrase>
-    </textobject>
-  </mediaobject>
-  
-  <para>
-    The data stored by the cluster is divided into two partitions,
-    labeled <emphasis role="bold">A</emphasis> and 
-    <emphasis role="bold">B</emphasis> in the diagram. Each partition is
-    stored &mdash; in multiple copies &mdash; on a node group. The data
-    making up Partition <emphasis role="bold">A</emphasis> is stored on
-    Node <emphasis role="bold">A-1</emphasis>, and this data is
-    identical to that stored by Node 
-    <emphasis role="bold">A-2</emphasis>. The data stored by Nodes
-    <emphasis role="bold">B-1</emphasis> and 
-    <emphasis role="bold">B-2</emphasis> is also the same &mdash; these
-    two nodes store identical copies of the data making up Partition
-    <emphasis role="bold">B</emphasis>.
-  </para>
-  
-  <para>
-    What this means so far as the continued operation of a MySQL
-    Cluster is this: so long as each node group participating in the
-    cluster has at least one <quote>live</quote> node, the cluster has a
-    complete copy of all data and remains viable. This is illustrated in
-    the next diagram.
-  </para>
-  
-  <remark role="todo">
-    [js] Not a very good caption; think of a better one.
-  </remark>
-
-  <mediaobject>
-    <imageobject>
-      <imagedata fileref="images/replicas-groups-1-2.png" format="PNG"/>
-    </imageobject>
-    <textobject>
-      <phrase lang="en">Nodes required to keep a 2x2 cluster viable</phrase>
-    </textobject>
-  </mediaobject>
-  
-  <para>
-    In this example, where the cluster consists of two node groups of
-    two nodes each, any combination of at least one node in Node Group
-    <emphasis role="bold">A</emphasis> and at least one node in Node
-    Group <emphasis role="bold">B</emphasis> is sufficient to keep the
-    cluster <quote>alive</quote> (indicated by arrows in the diagram).
-    However, if both nodes from either node group fail, the remaining
-    two nodes are not sufficient (shown by arrows marked out with an
-    <emphasis role="bold">X</emphasis>); in either case, the cluster has    
-    lost an entire partition and so can no longer provide access to a
-    complete set of all cluster data.
-  </para>
-      
       <remark role="todo">
         [js] Add discussion of application of the above to hosts running
         multiple CPUs.
       </remark>
-      
+
       <remark role="todo">
         [js] Add description of memory requirements based on Hartmut's
         example scripts.
       </remark>
+
     </section>
-    
-    
+
   </section>
 
   <section id="multi-computer">
@@ -2594,7 +2599,7 @@
                       old logfile is renamed by appending
                       <filename>.x</filename> to the filename, where
                       <literal>x</literal> is the next number not yet
-                      used with this name. 
+                      used with this name.
                     </para>
                   </listitem>
 

Modified: trunk/refman-5.1/ndbcluster.xml
===================================================================
--- trunk/refman-5.1/ndbcluster.xml	2006-01-15 05:24:34 UTC (rev 841)
+++ trunk/refman-5.1/ndbcluster.xml	2006-01-15 05:29:22 UTC (rev 842)
@@ -258,8 +258,8 @@
 
     <para>
       For a brief introduction to the relationships between nodes, node
-      groups, replicas, and partitions in MySQL Cluster, see 
-      <xref linkend="mysql-cluster-nodes-groups"/>. 
+      groups, replicas, and partitions in MySQL Cluster, see
+      <xref linkend="mysql-cluster-nodes-groups"/>.
     </para>
 
     <para>
@@ -359,172 +359,177 @@
       @subsection How MySQL Cluster Avoids Network Partitioning
     </remark>
 
-  <section id="mysql-cluster-nodes-groups">
+    <section id="mysql-cluster-nodes-groups">
+
       <title>&title-mysql-cluster-nodes-groups;</title>
-  
-  <remark role="note">
-    Author: Jon Stephens, with valuable assistance from Tomas Ulin, Jeb
-    Miller, and Hartmut Holzgraefe
-  </remark>
-  
-  <para>
-    This section discusses the manner in which MySQL Cluster divides
-    and duplicates data for storage and its implications for CLuster
-    memory requirements.
-  </para>
-  
-  <para>
-    <emphasis role="bold">Concepts</emphasis>
-  </para>
-  
-  <para>
-    Central to an understanding of this topic are the following
-    concepts, listed here with brief definitions:
-  </para>
-  
-  <itemizedlist>
-    <listitem>
+
+      <remark role="note">
+        Author: Jon Stephens, with valuable assistance from Tomas Ulin,
+        Jeb Miller, and Hartmut Holzgraefe
+      </remark>
+
       <para>
-        <emphasis role="bold">(Data) Node</emphasis>: An
-        <command>ndbd</command> process, which stores a
-        <firstterm>replica</firstterm> &mdash;that is, a copy of the
-        <firstterm>partition</firstterm> (see below) assigned to the
-        node group of which the node is a member.
+        This section discusses the manner in which MySQL Cluster divides
+        and duplicates data for storage and its implications for CLuster
+        memory requirements.
       </para>
-      
+
       <para>
-        Each data node is usually located on a separate computer.
-        However, it is also possible to host multiple data nodes on a
-        single computer having more than one processor. In such cases,
-        it is feasible to run one instance of <command>ndbd</command>
-        per physical CPU. (Note that a processor with multiple cores is
-        still a single processor.)
+        <emphasis role="bold">Concepts</emphasis>
       </para>
-      
+
       <para>
-        It is common for the terms <quote>node</quote> and <quote>data
-          node</quote> to be used interchangeably when referring to an
-        <command>ndbd</command> process; where mentioned, management
-        nodes (<command>ndb_mgmd</command> processes) and SQL nodes
-        (<command>mysqld</command> processes) are specified as such in
-        this discussion.
+        Central to an understanding of this topic are the following
+        concepts, listed here with brief definitions:
       </para>
-    </listitem>
-    
-    <listitem>
+
+      <itemizedlist>
+
+        <listitem>
+          <para>
+            <emphasis role="bold">(Data) Node</emphasis>: An
+            <command>ndbd</command> process, which stores a
+            <firstterm>replica</firstterm> &mdash;that is, a copy of the
+            <firstterm>partition</firstterm> (see below) assigned to the
+            node group of which the node is a member.
+          </para>
+
+          <para>
+            Each data node is usually located on a separate computer.
+            However, it is also possible to host multiple data nodes on
+            a single computer having more than one processor. In such
+            cases, it is feasible to run one instance of
+            <command>ndbd</command> per physical CPU. (Note that a
+            processor with multiple cores is still a single processor.)
+          </para>
+
+          <para>
+            It is common for the terms <quote>node</quote> and
+            <quote>data node</quote> to be used interchangeably when
+            referring to an <command>ndbd</command> process; where
+            mentioned, management nodes (<command>ndb_mgmd</command>
+            processes) and SQL nodes (<command>mysqld</command>
+            processes) are specified as such in this discussion.
+          </para>
+        </listitem>
+
+        <listitem>
+          <para>
+            <emphasis role="bold">Node Group</emphasis>: A node group
+            consists of one or more nodes, and stores a partition, or
+            set of <firstterm>replicas</firstterm> (see next item).
+          </para>
+
+          <para>
+            <emphasis role="bold">Note</emphasis>: Currently, all node
+            groups in a cluster must have the same number of nodes.
+          </para>
+        </listitem>
+
+        <listitem>
+          <para>
+            <emphasis role="bold">Partition</emphasis>: This is a
+            portion of the data stored by the cluster. There are as many
+            cluster partitions as node groups participating in the
+            cluster, and each node group is responible for keeping at
+            least one copy of the partition assigned to it (that, at
+            least one replica) available to the cluster.
+          </para>
+        </listitem>
+
+        <listitem>
+          <para>
+            <emphasis role="bold">Replica</emphasis>: This is a copy of
+            a cluster partition. Each node in a node group stores a
+            replica. Also sometimes known as a <firstterm>partition
+            replica</firstterm>.
+          </para>
+        </listitem>
+
+      </itemizedlist>
+
       <para>
-        <emphasis role="bold">Node Group</emphasis>: A node group
-        consists of one or more nodes, and stores a partition, or set of
-        <firstterm>replicas</firstterm> (see next item). 
+        The following diagram illustrates a MySQL Cluster with four data
+        nodes, arranged in two node groups of two nodes each. Note that
+        no nodes other than data nodes are shown here, although a
+        working cluster requires an <command>ndb_mgm</command> process
+        for cluster management and at least one SQL node in order to
+        access the data stored by the cluster.
       </para>
-      
+
+      <mediaobject>
+        <imageobject>
+          <imagedata fileref="images/replicas-groups-1-1.png" format="PNG"/>
+        </imageobject>
+        <textobject>
+          <phrase lang="en">A MySQL Cluster, with 2 node groups having 2
+          nodes each</phrase>
+        </textobject>
+      </mediaobject>
+
       <para>
-        <emphasis role="bold">Note</emphasis>: Currently, all node
-        groups in a cluster must have the same number of nodes.
+        The data stored by the cluster is divided into two partitions,
+        labeled <emphasis role="bold">A</emphasis> and
+        <emphasis role="bold">B</emphasis> in the diagram. Each
+        partition is stored &mdash; in multiple copies &mdash; on a node
+        group. The data making up Partition
+        <emphasis role="bold">A</emphasis> is stored on Node
+        <emphasis role="bold">A-1</emphasis>, and this data is identical
+        to that stored by Node <emphasis role="bold">A-2</emphasis>. The
+        data stored by Nodes <emphasis role="bold">B-1</emphasis> and
+        <emphasis role="bold">B-2</emphasis> is also the same &mdash;
+        these two nodes store identical copies of the data making up
+        Partition <emphasis role="bold">B</emphasis>.
       </para>
-    </listitem>
-    
-    <listitem>
+
       <para>
-        <emphasis role="bold">Partition</emphasis>: This is a portion of
-        the data stored by the cluster. There are as many cluster
-        partitions as node groups participating in the cluster, and each
-        node group is responible for keeping at least one copy of the
-        partition assigned to it (that, at least one replica) available
-        to the cluster.
+        What this means so far as the continued operation of a MySQL
+        Cluster is this: so long as each node group participating in the
+        cluster has at least one <quote>live</quote> node, the cluster
+        has a complete copy of all data and remains viable. This is
+        illustrated in the next diagram.
       </para>
-    </listitem>
-    
-    <listitem>
+
+      <remark role="todo">
+        [js] Not a very good caption; think of a better one.
+      </remark>
+
+      <mediaobject>
+        <imageobject>
+          <imagedata fileref="images/replicas-groups-1-2.png" format="PNG"/>
+        </imageobject>
+        <textobject>
+          <phrase lang="en">Nodes required to keep a 2x2 cluster
+          viable</phrase>
+        </textobject>
+      </mediaobject>
+
       <para>
-        <emphasis role="bold">Replica</emphasis>: This is a copy of a
-        cluster partition. Each node in a node group stores a replica.
-        Also sometimes known as a <firstterm>partition
-          replica</firstterm>.
+        In this example, where the cluster consists of two node groups
+        of two nodes each, any combination of at least one node in Node
+        Group <emphasis role="bold">A</emphasis> and at least one node
+        in Node Group <emphasis role="bold">B</emphasis> is sufficient
+        to keep the cluster <quote>alive</quote> (indicated by arrows in
+        the diagram). However, if both nodes from either node group
+        fail, the remaining two nodes are not sufficient (shown by
+        arrows marked out with an <emphasis role="bold">X</emphasis>);
+        in either case, the cluster has lost an entire partition and so
+        can no longer provide access to a complete set of all cluster
+        data.
       </para>
-    </listitem>
-  </itemizedlist>
-  
-  <para>
-    The following diagram illustrates a MySQL Cluster with four data
-    nodes, arranged in two node groups of two nodes each. Note that no
-    nodes other than data nodes are shown here, although a working
-    cluster requires an <command>ndb_mgm</command> process for cluster
-    management and at least one SQL node in order to access the data
-    stored by the cluster.
-  </para>
 
-  <mediaobject>
-    <imageobject>
-      <imagedata fileref="images/replicas-groups-1-1.png" format="PNG"/>
-    </imageobject>
-    <textobject>
-      <phrase lang="en">A MySQL Cluster, with 2 node groups having 2
-        nodes each</phrase>
-    </textobject>
-  </mediaobject>
-  
-  <para>
-    The data stored by the cluster is divided into two partitions,
-    labeled <emphasis role="bold">A</emphasis> and 
-    <emphasis role="bold">B</emphasis> in the diagram. Each partition is
-    stored &mdash; in multiple copies &mdash; on a node group. The data
-    making up Partition <emphasis role="bold">A</emphasis> is stored on
-    Node <emphasis role="bold">A-1</emphasis>, and this data is
-    identical to that stored by Node 
-    <emphasis role="bold">A-2</emphasis>. The data stored by Nodes
-    <emphasis role="bold">B-1</emphasis> and 
-    <emphasis role="bold">B-2</emphasis> is also the same &mdash; these
-    two nodes store identical copies of the data making up Partition
-    <emphasis role="bold">B</emphasis>.
-  </para>
-  
-  <para>
-    What this means so far as the continued operation of a MySQL
-    Cluster is this: so long as each node group participating in the
-    cluster has at least one <quote>live</quote> node, the cluster has a
-    complete copy of all data and remains viable. This is illustrated in
-    the next diagram.
-  </para>
-  
-  <remark role="todo">
-    [js] Not a very good caption; think of a better one.
-  </remark>
-
-  <mediaobject>
-    <imageobject>
-      <imagedata fileref="images/replicas-groups-1-2.png" format="PNG"/>
-    </imageobject>
-    <textobject>
-      <phrase lang="en">Nodes required to keep a 2x2 cluster viable</phrase>
-    </textobject>
-  </mediaobject>
-  
-  <para>
-    In this example, where the cluster consists of two node groups of
-    two nodes each, any combination of at least one node in Node Group
-    <emphasis role="bold">A</emphasis> and at least one node in Node
-    Group <emphasis role="bold">B</emphasis> is sufficient to keep the
-    cluster <quote>alive</quote> (indicated by arrows in the diagram).
-    However, if both nodes from either node group fail, the remaining
-    two nodes are not sufficient (shown by arrows marked out with an
-    <emphasis role="bold">X</emphasis>); in either case, the cluster has    
-    lost an entire partition and so can no longer provide access to a
-    complete set of all cluster data.
-  </para>
-      
       <remark role="todo">
         [js] Add discussion of application of the above to hosts running
         multiple CPUs.
       </remark>
-      
+
       <remark role="todo">
         [js] Add description of memory requirements based on Hartmut's
         example scripts.
       </remark>
+
     </section>
-    
-    
+
   </section>
 
   <section id="multi-computer">
@@ -2592,7 +2597,7 @@
                       old logfile is renamed by appending
                       <filename>.x</filename> to the filename, where
                       <literal>x</literal> is the next number not yet
-                      used with this name. 
+                      used with this name.
                     </para>
                   </listitem>
 

Thread
svn commit - mysqldoc@docsrva: r842 - in trunk: refman-4.1 refman-5.0 refman-5.1jon15 Jan