List:Commits« Previous MessageNext Message »
From:paul Date:January 31 2006 8:55pm
Subject:svn commit - mysqldoc@docsrva: r1153 - in trunk: . refman-4.1 refman-5.0 refman-5.1
View as plain text  
Author: paul
Date: 2006-01-31 21:55:32 +0100 (Tue, 31 Jan 2006)
New Revision: 1153

Log:
 r2747@kite-hub:  paul | 2006-01-31 14:55:24 -0600
 General revisions.


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


Property changes on: trunk
___________________________________________________________________
Name: svk:merge
   - b5ec3a16-e900-0410-9ad2-d183a3acac99:/mysqldoc-local/mysqldoc/trunk:6975
bf112a9c-6c03-0410-a055-ad865cd57414:/mysqldoc-local/mysqldoc/trunk:2745
   + b5ec3a16-e900-0410-9ad2-d183a3acac99:/mysqldoc-local/mysqldoc/trunk:6975
bf112a9c-6c03-0410-a055-ad865cd57414:/mysqldoc-local/mysqldoc/trunk:2747

Modified: trunk/refman-4.1/ndbcluster.xml
===================================================================
--- trunk/refman-4.1/ndbcluster.xml	2006-01-31 18:19:58 UTC (rev 1152)
+++ trunk/refman-4.1/ndbcluster.xml	2006-01-31 20:55:32 UTC (rev 1153)
@@ -73,7 +73,7 @@
 
     <listitem>
       <para>
-        The MySQL Cluster forum:
+        The MySQL Cluster Forum:
         <ulink url="&base-url-forum-list;?25"/>.
       </para>
     </listitem>
@@ -4183,7 +4183,7 @@
               When a transaction is committed, it is committed in main
               memory in all nodes on which the data is mirrored.
               However, transaction log records are not flushed to disk
-              as part of the commit. The reasoning behing this behavior
+              as part of the commit. The reasoning behind this behavior
               is that having the transaction safely committed on at
               least two autonomous host machines should meet reasonable
               standards for durability.
@@ -5117,7 +5117,7 @@
 
         <para>
           In the following example, we envision a cluster with at least
-          4 hosts, one each for a management server, an SQL node, and
+          four hosts, one each for a management server, an SQL node, and
           two data nodes. The cluster as a whole resides on the
           <literal>172.23.72.*</literal> subnet of a LAN. In addition to
           the usual network connections, the two data nodes are
@@ -5302,10 +5302,10 @@
           also that using SCI Transporters means that the
           <command>ndbd</command> processes never sleep. For this
           reason, SCI Transporters should be used only on machines
-          having at least 2 CPUs dedicated for use by
-          <command>ndbd</command> processes. There should be at least 1
-          CPU per <command>ndbd</command> process, with at least 1 CPU
-          left in reserve to handle operating system activities.
+          having at least two CPUs dedicated for use by
+          <command>ndbd</command> processes. There should be at least
+          one CPU per <command>ndbd</command> process, with at least one
+          CPU left in reserve to handle operating system activities.
         </para>
 
         <itemizedlist>
@@ -9482,10 +9482,27 @@
       [js] Add cross-references.
     </remark>
 
+    <para>
+      This section answers questions that are often asked about MySQL
+      Cluster.
+    </para>
+
     <itemizedlist>
 
       <listitem>
         <para>
+          <emphasis>What does <quote>NDB</quote> mean?</emphasis>
+        </para>
+
+        <para>
+          This stands for
+          <quote><emphasis role="bold">N</emphasis>etwork
+          <emphasis role="bold">D</emphasis>ata<emphasis role="bold">b</emphasis>ase.</quote>
+        </para>
+      </listitem>
+
+      <listitem>
+        <para>
           <emphasis>What's the difference in using Cluster vs. using
           replication?</emphasis>
         </para>
@@ -9501,10 +9518,10 @@
           slave or not applied at all, but replication does not
           guarantee that all data on the master and the slave will be
           consistent at all times. In MySQL Cluster, all data nodes are
-          kept in synch, and a transaction committed by any one data
+          kept in synchrony, and a transaction committed by any one data
           node is committed for all data nodes. In the event of a data
-          node failure, all remaining data nodes will remain in a
-          consistent state.
+          node failure, all remaining data nodes remain in a consistent
+          state.
         </para>
 
         <para>
@@ -9583,11 +9600,11 @@
           are:
         </para>
 
-        <orderedlist>
+        <itemizedlist>
 
           <listitem>
             <para>
-              <emphasis role="bold">management node (MGM
+              <emphasis role="bold">Management node (MGM
               node)</emphasis>: Provides management services for the
               cluster as a whole, including startup, shutdown, backups,
               and configuration data for the other nodes. The management
@@ -9600,7 +9617,7 @@
 
           <listitem>
             <para>
-              <emphasis role="bold">data node</emphasis>: Stores and
+              <emphasis role="bold">Data node</emphasis>: Stores and
               replicates data. Data node functionality is handled by an
               instance of the NDB data node process
               <command>ndbd</command>.
@@ -9611,11 +9628,14 @@
             <para>
               <emphasis role="bold">SQL node</emphasis>: This is simply
               an instance of MySQL Server (<command>mysqld</command>)
-              started with the <command>--ndb-cluster</command> option.
+              that is built with support for the <literal>NDB
+              Cluster</literal> storage engine and started with the
+              <command>--ndb-cluster</command> option to enable the
+              engine.
             </para>
           </listitem>
 
-        </orderedlist>
+        </itemizedlist>
       </listitem>
 
       <listitem>
@@ -9662,8 +9682,8 @@
           will improve performance, and 64-bit CPUs will likely be more
           effective than 32-bit processors. There must be sufficient
           memory on machines used for data nodes to hold each node's
-          share of the database (see <emphasis role="bold">How much RAM
-          do I Need?</emphasis> for more info). Nodes can communicate
+          share of the database (see <emphasis>How much RAM do I
+          Need?</emphasis> for more information). Nodes can communicate
           via a standard TCP/IP network and hardware. For SCI support,
           special networking hardware is required.
         </para>
@@ -9671,23 +9691,137 @@
 
       <listitem>
         <para>
-          <emphasis>Because MySQL Cluster uses TCP/IP, does that mean I
-          can run it over the Internet, with one or more nodes in a
-          remote location?</emphasis>
+          <emphasis>How much RAM do I need? Is it possible to use disk
+          memory at all?</emphasis>
         </para>
 
         <para>
-          It is extremely important to keep in mind that communications
-          between the nodes in a MySQL Cluster are not secure; they are
-          neither encrypted nor safeguarded by any other protective
-          mechanism. The most secure configuration for a cluster is in a
-          private network behind a firewall, with no direct access to
-          any Cluster data or management nodes from outside. (For SQL
-          nodes, you should take the same precautions as you would with
-          any other instance of the MySQL server.)
+          Currently, Cluster is in-memory only. This means that all
+          table data (including indexes) is stored in RAM. Therefore, if
+          your data takes up 1 gigabyte of space and you wish to
+          replicate it once in the cluster, you need 2 gigabytes of
+          memory to do so. This in addition to the memory required by
+          the operating system and any applications running on the
+          cluster computers.
         </para>
 
         <para>
+          You can use the following formula for obtaining a rough
+          estimate of how much RAM is needed for each data node in the
+          cluster:
+        </para>
+
+<programlisting>
+(SizeofDatabase &times; NumberOfReplicas &times; 1.1 ) / NumberOfDataNodes
+</programlisting>
+
+        <para>
+          To calculate the memory requirements more exactly requires
+          determining, for each table in the cluster database, the
+          storage space required per row (see
+          <xref linkend="storage-requirements"/>, for details), and
+          multiplying this by the number of rows. You must also remember
+          to account for any column indexes as follows:
+        </para>
+
+        <itemizedlist>
+
+          <listitem>
+            <para>
+              Each primary key or hash index created for an
+              <literal>NDBCluster</literal> table requires 21-25 bytes
+              per record. These indexes use
+              <literal>IndexMemory</literal>.
+            </para>
+          </listitem>
+
+          <listitem>
+            <para>
+              Each ordered index requires 10 bytes storage per record,
+              using <literal>DataMemory</literal>.
+            </para>
+          </listitem>
+
+          <listitem>
+            <para>
+              Creating a primary key or unique index also creates an
+              ordered index, unless this index is created with
+              <literal>USING HASH</literal>. In other words, if created
+              without <literal>USING HASH</literal>, a primary key or
+              unique index on a Cluster table takes up 31-35 bytes per
+              record in MySQL &current-series;.
+            </para>
+
+            <para>
+              Note that creating MySQL Cluster tables with
+              <literal>USING HASH</literal> for all primary keys and
+              unique indexes will generally cause table updates to run
+              more quickly. This is due to the fact that less memory is
+              required (because no ordered indexes are created), and
+              that less CPU must be utilized (because fewer indexes must
+              be read and possibly updated).
+            </para>
+          </listitem>
+
+        </itemizedlist>
+
+        <para>
+          It is especially important to keep in mind that
+          <emphasis>every MySQL Cluster table must have a primary
+          key</emphasis>. The <literal>NDB</literal> storage engine
+          creates a primary key automatically if none is defined, and
+          this primary key is created without <literal>USING
+          HASH</literal>.
+        </para>
+
+        <para>
+          As of MySQL 4.1.11 there is no easy way determine exactly how
+          much memory is being used for storage of Cluster indexes;
+          however, warnings are written to the Cluster log when 80% of
+          available <literal>DataMemory</literal> or
+          <literal>IndexMemory</literal> is in use, and again when use
+          reaches 85%, 90%, and so on.
+        </para>
+
+        <para>
+          We often see questions from users who report that, when they
+          are trying to populate a Cluster database, the loading process
+          terminates prematurely and an error message like this one is
+          observed:
+        </para>
+
+<programlisting>
+ERROR 1114: The table 'my_cluster_table' is full
+</programlisting>
+
+        <para>
+          When this occurs, the cause is very likely to be that your
+          setup does not provide sufficient RAM for all table data and
+          all indexes, <emphasis>including the primary key required by
+          the <literal>NDB</literal> storage engine and automatically
+          created in the event that the table definition does not
+          include the definition of a primary key</emphasis>.
+        </para>
+
+        <para>
+          It is also worth noting that all data nodes should have the
+          same amount of RAM, as no data node in a cluster can use more
+          memory than the least amount available to any individual data
+          node. In other words, if there are three computers hosting
+          Cluster data nodes, with two of these having 3GB of RAM
+          available to store Cluster data, and one having only 1GB RAM,
+          then each data node can devote only 1GB to clustering.
+        </para>
+      </listitem>
+
+      <listitem>
+        <para>
+          <emphasis>Because MySQL Cluster uses TCP/IP, does that mean I
+          can run it over the Internet, with one or more nodes in a
+          remote location?</emphasis>
+        </para>
+
+        <para>
           It is very doubtful in any case that a cluster would perform
           reliably under such conditions, as MySQL Cluster was designed
           and implemented with the assumption that it would be run under
@@ -9696,6 +9830,17 @@
           Ethernet (preferably the latter). We neither test nor warrant
           its performance using anything slower than this.
         </para>
+
+        <para>
+          Also, it is extremely important to keep in mind that
+          communications between the nodes in a MySQL Cluster are not
+          secure; they are neither encrypted nor safeguarded by any
+          other protective mechanism. The most secure configuration for
+          a cluster is in a private network behind a firewall, with no
+          direct access to any Cluster data or management nodes from
+          outside. (For SQL nodes, you should take the same precautions
+          as you would with any other instance of the MySQL server.)
+        </para>
       </listitem>
 
       <listitem>
@@ -9707,7 +9852,7 @@
         <para>
           No. Although some specialized commands are used to manage and
           configure the cluster itself, only standard (My)SQL queries
-          and commands are required for:
+          and commands are required for the following operations:
         </para>
 
         <itemizedlist>
@@ -9754,15 +9899,15 @@
           There are two ways in which this can be done:
         </para>
 
-        <orderedlist>
+        <itemizedlist>
 
           <listitem>
             <para>
-              From within the MySQL Monitor, use <command>SHOW
-              ERRORS</command> or <command>SHOW WARNINGS</command>
-              immediately upon being notified of the error or warning
-              condition. These can also be displayed in MySQL Query
-              Browser.
+              From within the <command>mysql</command> client, use
+              <command>SHOW ERRORS</command> or <command>SHOW
+              WARNINGS</command> immediately upon being notified of the
+              error or warning condition. Errors and warnings also be
+              displayed in MySQL Query Browser.
             </para>
           </listitem>
 
@@ -9773,7 +9918,7 @@
             </para>
           </listitem>
 
-        </orderedlist>
+        </itemizedlist>
       </listitem>
 
       <listitem>
@@ -9812,19 +9957,6 @@
         </para>
       </listitem>
 
-      <listitem>
-        <para>
-          <emphasis>What does <quote>NDB</quote> mean?</emphasis>
-        </para>
-
-        <para>
-          This stands for
-          <quote><emphasis role="bold">N</emphasis>etwork
-          <emphasis role="bold">D</emphasis>ata<emphasis
-role="bold">b</emphasis>ase.</quote>
-        </para>
-      </listitem>
-
 <!--  
       <listitem>
         <remark role="todo">
@@ -9872,132 +10004,6 @@
 
       <listitem>
         <para>
-          <emphasis>How much RAM do I need? Is it possible to use disk
-          memory at all?</emphasis>
-        </para>
-
-        <para>
-          Currently, Cluster is in-memory only. This means that all
-          table data (including indexes) is stored in RAM. Therefore, if
-          your data takes up 1 gigabyte of space and you wish to
-          replicate it once in the cluster, you need 2 gigabytes of
-          memory to do so. This in addition to the memory required by
-          the operating system and any applications running on the
-          cluster computers.
-        </para>
-
-        <para>
-          You can use the following formula for obtaining a rough
-          estimate of how much RAM is needed for each data node in the
-          cluster:
-        </para>
-
-<programlisting>
-(SizeofDatabase * NumberOfReplicas * 1.1 ) / NumberOfDataNodes
-</programlisting>
-
-        <para>
-          To calculate the memory requirements more exactly requires
-          determining, for each table in the cluster database, the
-          storage space required per row (see
-          <xref linkend="storage-requirements"/>, for details), and
-          multiplying this by the number of rows. You must also remember
-          to account for any column indexes as follows:
-        </para>
-
-        <itemizedlist>
-
-          <listitem>
-            <para>
-              Each primary key or hash index created for an
-              <literal>NDBCluster</literal> table requires 21-25 bytes
-              per record. These indexes use
-              <literal>IndexMemory</literal>.
-            </para>
-          </listitem>
-
-          <listitem>
-            <para>
-              Each ordered index requires 10 bytes storage per record,
-              using <literal>DataMemory</literal>.
-            </para>
-          </listitem>
-
-          <listitem>
-            <para>
-              Creating a primary key or unique index also creates an
-              ordered index, unless this index is created with
-              <literal>USING HASH</literal>. In other words, if created
-              without <literal>USING HASH</literal>, a primary key or
-              unique index on a Cluster table takes up 31-35 bytes per
-              record in MySQL &current-series;.
-            </para>
-
-            <para>
-              Note that creating MySQL Cluster tables with
-              <literal>USING HASH</literal> for all primary keys and
-              unique indexes will generally cause table updates to run
-              more quickly. This is due to the fact that less memory is
-              required (because no ordered indexes are created), and
-              that less CPU must be utilized (because fewer indexes must
-              be read and possibly updated).
-            </para>
-          </listitem>
-
-        </itemizedlist>
-
-        <para>
-          It is especially important to keep in mind that
-          <emphasis>every MySQL Cluster table must have a primary
-          key</emphasis>. The <literal>NDB</literal> storage engine
-          creates a primary key automatically if none is defined, and
-          this primary key is created without <literal>USING
-          HASH</literal>.
-        </para>
-
-        <para>
-          As of MySQL 4.1.11 there is no easy way determine exactly how
-          much memory is being used for storage of Cluster indexes;
-          however, warnings are written to the Cluster log when 80% of
-          available <literal>DataMemory</literal> or
-          <literal>IndexMemory</literal> is in use, and again when 85%,
-          90%, and so on is in use.
-        </para>
-
-        <para>
-          We often see questions from users who report that, when they
-          are trying to populate a Cluster database, the loading process
-          terminates prematurely and an error message like this one is
-          observed:
-        </para>
-
-<programlisting>
-ERROR 1114: The table 'my_cluster_table' is full
-</programlisting>
-
-        <para>
-          When this occurs, the cause is very likely to be that your
-          setup does not provide sufficient RAM for all table data and
-          all indexes, <emphasis>including the primary key required by
-          the <literal>NDB</literal> storage engine and automatically
-          created in the event that the table definition does not
-          include the definition of a primary key</emphasis>.
-        </para>
-
-        <para>
-          It is also worth noting that all data nodes should have the
-          same amount of RAM, as no data node in a cluster can use more
-          memory than the least amount available to any individual data
-          node. In other words, if there are three computers hosting
-          Cluster data nodes, with two of these having three gigabytes
-          of RAM available to store Cluster data, and one having only
-          one GB RAM, then each data node can devote only one GB to
-          clustering.
-        </para>
-      </listitem>
-
-      <listitem>
-        <para>
           <emphasis>In the event of a catastrophic failure &mdash; say,
           for instance, the whole city loses power
           <emphasis role="bold">and</emphasis> my UPS fails &mdash;
@@ -10005,8 +10011,8 @@
         </para>
 
         <para>
-          All committed transactions are logged. Therefore, while it is
-          possible that some data could be lost in the event of a
+          All committed transactions are logged. Therefore, although it
+          is possible that some data could be lost in the event of a
           catastrophe, this should be quite limited. Data loss can be
           further reduced by minimizing the number of operations per
           transaction. (It is not a good idea to perform large numbers
@@ -10036,7 +10042,7 @@
 
         <para>
           It is possible but not advisable. One of the chief reasons to
-          run a cluster is to provide redundancy; to enjoy the full
+          run a cluster is to provide redundancy. To enjoy the full
           benefits of this redundancy, each node should reside on a
           separate machine. If you place multiple nodes on a single
           machine and that machine fails, you lose all of those nodes.
@@ -10045,7 +10051,7 @@
           is well worth the expense of an extra machine or two in order
           to safeguard mission-critical data. It also worth noting that
           the requirements for a cluster host running a management node
-          are minimal; this task can be accomplished with a 200 MHz
+          are minimal. This task can be accomplished with a 200 MHz
           Pentium CPU and sufficient RAM for the operating system plus a
           small amount of overhead for the <command>ndb_mgmd</command>
           and <command>ndb_mgm</command> processes.
@@ -10065,7 +10071,7 @@
           steps:
         </para>
 
-        <itemizedlist>
+        <orderedlist>
 
           <listitem>
             <para>
@@ -10093,7 +10099,7 @@
             </para>
           </listitem>
 
-        </itemizedlist>
+        </orderedlist>
 
         <para>
           In a future MySQL Cluster release series, we hope to implement
@@ -10127,14 +10133,14 @@
 
           <listitem>
             <para>
-              <literal>FULLTEXT</literal> indexes and prefix indexes are
+              <literal>FULLTEXT</literal> indexes and index prefixes are
               not supported. Only complete columns may be indexed.
             </para>
           </listitem>
 
           <listitem>
             <para>
-              Spatial extensions are not supported. See
+              Spatial data types are not supported. See
               <xref linkend="spatial-extensions"/>.
             </para>
           </listitem>
@@ -10142,7 +10148,7 @@
           <listitem>
             <para>
               Only complete rollbacks for transactions are supported.
-              Partial rollbacks and rollbacks to save points are not
+              Partial rollbacks and rollbacks to savepoints are not
               supported.
             </para>
           </listitem>
@@ -10160,7 +10166,7 @@
             <para>
               The maximum size for a table row is 8 kilobytes, not
               counting <literal>BLOB</literal>s. There is no set limit
-              for the number of rows per table; table size limits depend
+              for the number of rows per table. Table size limits depend
               on a number of factors, in particular on the amount of RAM
               available to each data node.
             </para>
@@ -10206,7 +10212,7 @@
           <literal>ENGINE=NDBCLUSTER</literal>. It is also possible to
           convert existing tables using other storage engines to
           <literal>NDB Cluster</literal> using <literal>ALTER
-          TABLE</literal>, but requires an additional workaround; see
+          TABLE</literal>, but requires an additional workaround. See
           <xref linkend="mysql-cluster-limitations-in-4-1"/>, for
           details.
         </para>
@@ -10239,13 +10245,12 @@
 
         <para>
           If one or more nodes in a cluster fail, it is possible that
-          not all cluster nodes will not be able to <quote>see</quote>
-          one another. In fact, it is possible that two sets of nodes
-          might become isolated from one another in a network
-          partitioning, also known as a <quote>split brain</quote>
-          scenario. This type of situation is undesirable because each
-          set of nodes tries to behave as though it is the entire
-          cluster.
+          not all cluster nodes will be able to <quote>see</quote> one
+          another. In fact, it is possible that two sets of nodes might
+          become isolated from one another in a network partitioning,
+          also known as a <quote>split brain</quote> scenario. This type
+          of situation is undesirable because each set of nodes tries to
+          behave as though it is the entire cluster.
         </para>
 
         <para>
@@ -10260,7 +10265,7 @@
         </para>
 
         <para>
-          The preceding information is somewhat simplified; a more
+          The preceding information is somewhat simplified. A more
           complete explanation taking into account node groups follows:
         </para>
 
@@ -10382,7 +10387,7 @@
 </programlisting>
 
         <para>
-          This will cause the <command>ndb_mgm</command>,
+          This causes the <command>ndb_mgm</command>,
           <command>ndb_mgm</command>, and any <command>ndbd</command>
           processes to terminate gracefully. MySQL servers running as
           Cluster SQL nodes can be stopped using <command>mysqladmin
@@ -10406,7 +10411,7 @@
           It can be helpful as a fail-safe. Only one MGM node controls
           the cluster at any given time, but it is possible to configure
           one MGM as primary, and one or more additional management
-          nodes to take over in the evnt that the primary MGM node
+          nodes to take over in the event that the primary MGM node
           fails.
         </para>
 
@@ -10426,11 +10431,12 @@
         </para>
 
         <para>
-          Yes, so long as all machines and operating systems are the
-          same endian. It is also possible to use different MySQL
-          Cluster releases on different nodes (for example, 4.1.8 on
-          some nodes and 4.1.9 on others); however, we recommend this be
-          done only as part of a rolling upgrade procedure.
+          Yes, so long as all machines and operating systems have the
+          same endianness (all big-endian or all little-endian). It is
+          also possible to use different MySQL Cluster releases on
+          different nodes (for example, 4.1.8 on some nodes and 4.1.9 on
+          others). However, we recommend this be done only as part of a
+          rolling upgrade procedure.
         </para>
       </listitem>
 
@@ -10577,7 +10583,7 @@
           that a checkpoint has been reached. More specific to Cluster,
           it is a point in time where all committed transactions are
           stored on disk. With regard to the <literal>NDB</literal>
-          storage engine, there are two sorts of checkpoints which work
+          storage engine, there are two types of checkpoints which work
           together to ensure that a consistent view of the cluster's
           data is maintained:
         </para>
@@ -10640,11 +10646,11 @@
         <para>
           This refers to a logical or functional unit of MySQL Cluster,
           and is sometimes also referred to as a <firstterm>cluster
-          node</firstterm>. In the context of MySQl Cluster, we use the
+          node</firstterm>. In the context of MySQL Cluster, we use the
           term <quote>node</quote> to indicate a
           <emphasis>process</emphasis> rather than a physical component
           of the cluster. There are three node types required to
-          implement a working MySQL Cluster. These are:
+          implement a working MySQL Cluster:
         </para>
 
         <itemizedlist>
@@ -10839,27 +10845,18 @@
 
           <listitem>
             <para>
-              TCP/IP (local)
+              TCP/IP
             </para>
 
             <para>
               This is, of course, the familiar network protocol that
-              underlies HTTP, FTP (and so on) on the Internet.
+              underlies HTTP, FTP (and so on) on the Internet. TCP/IP
+              can be used for both local and remote connections.
             </para>
           </listitem>
 
           <listitem>
             <para>
-              TCP/IP (remote)
-            </para>
-
-            <para>
-              Same as above, except as used for communicating remotely.
-            </para>
-          </listitem>
-
-          <listitem>
-            <para>
               SCI
             </para>
 
@@ -10869,7 +10866,7 @@
               <emphasis role="bold">I</emphasis>nterface is a high-speed
               protocol used in building multiprocessor systems and
               parallel-processing applications. Use of SCI with MySQL
-              Cluster requires specialized hardware and is discussed in
+              Cluster requires specialized hardware, as discussed in
               <xref linkend="sci-sockets"/>. For a basic introduction to
               SCI, see
               <ulink url="http://www.dolphinics.com/corporate/scitech.html">this
@@ -10901,8 +10898,8 @@
           is internal to the cluster. Applications using MySQL Cluster
           communicate with SQL nodes just as they do with any other
           version of MySQL Server (via TCP/IP, or through the use of
-          Unix sockets or Windows named pipes). Queries can be sent and
-          results retrieved using the standard MySQL APIs.
+          Unix socket files or Windows named pipes). Queries can be sent
+          and results retrieved using the standard MySQL client APIs.
         </para>
       </listitem>
 
@@ -10947,11 +10944,11 @@
           must have available an amount of RAM equal to the size of the
           database times the number of replicas, divided by the number
           of data nodes. Thus, if the database takes up 1 gigabyte of
-          memory, and you wish to set up the cluster with 4 replicas and
-          8 data nodes, a minimum of 500MB memory will be required per
-          node. Note that this is in addition to any requirements for
-          the operating system and any other applications that might be
-          running on the host.
+          memory, and you wish to set up the cluster with four replicas
+          and eight data nodes, a minimum of 500MB memory will be
+          required per node. Note that this is in addition to any
+          requirements for the operating system and any other
+          applications that might be running on the host.
         </para>
       </listitem>
 

Modified: trunk/refman-5.0/ndbcluster.xml
===================================================================
--- trunk/refman-5.0/ndbcluster.xml	2006-01-31 18:19:58 UTC (rev 1152)
+++ trunk/refman-5.0/ndbcluster.xml	2006-01-31 20:55:32 UTC (rev 1153)
@@ -72,7 +72,7 @@
 
     <listitem>
       <para>
-        The MySQL Cluster forum:
+        The MySQL Cluster Forum:
         <ulink url="&base-url-forum-list;?25"/>.
       </para>
     </listitem>
@@ -5124,7 +5124,7 @@
 
         <para>
           In the following example, we envision a cluster with at least
-          4 hosts, one each for a management server, an SQL node, and
+          four hosts, one each for a management server, an SQL node, and
           two data nodes. The cluster as a whole resides on the
           <literal>172.23.72.*</literal> subnet of a LAN. In addition to
           the usual network connections, the two data nodes are
@@ -5310,10 +5310,10 @@
           also that using SCI Transporters means that the
           <command>ndbd</command> processes never sleep. For this
           reason, SCI Transporters should be used only on machines
-          having at least 2 CPUs dedicated for use by
-          <command>ndbd</command> processes. There should be at least 1
-          CPU per <command>ndbd</command> process, with at least 1 CPU
-          left in reserve to handle operating system activities.
+          having at least two CPUs dedicated for use by
+          <command>ndbd</command> processes. There should be at least
+          one CPU per <command>ndbd</command> process, with at least one
+          CPU left in reserve to handle operating system activities.
         </para>
 
         <itemizedlist>
@@ -9562,8 +9562,8 @@
 
         <listitem>
           <para>
-            <emphasis role="bold">Condition Pushdown</emphasis>: A query
-            such as
+            <emphasis role="bold">Push-Down Conditions</emphasis>:
+            Consider the following query:
           </para>
 
 <programlisting>
@@ -9571,26 +9571,27 @@
 </programlisting>
 
           <para>
-            will use a full table scan and the condition will be
-            evaluated in the cluster's data nodes. Thus it is not
+            This query will use a full table scan and the condition will
+            be evaluated in the cluster's data nodes. Thus, it is not
             necessary to send the records across the network for
             evaluation. (That is, function transport is used, rather
             than data transport.) Please note that this feature is
-            disabled by default, but it should work in most cases. This
-            feature can be enabled through the use of the <literal>SET
-            engine_condition_pushdown=On</literal> statement.
+            currently disabled by default (pending more thorough
+            testing), but it should work in most cases. This feature can
+            be enabled through the use of the <literal>SET
+            engine_condition_pushdown = On</literal> statement.
             Alternatively, you can run <command>mysqld</command> with
-            this feature enabled by starting the MySQL server with the
-            <option>--engine-condition-pushdown</option> option.
+            the this feature enabled by starting the MySQL server with
+            the <option>--engine-condition-pushdown</option> option.
           </para>
 
           <para>
             A major benefit of this change is that queries can be
             executed in parallel. This means that queries against
-            non-indexed columns can run as much as 5 to 10 times,
-            <emphasis>times the number of data nodes</emphasis>, faster
-            than previously because multiple CPUs can work on the query
-            in parallel.
+            non-indexed columns can run faster than previously by a
+            factor of as much as 5 to 10 times, <emphasis>times the
+            number of data nodes</emphasis>, because multiple CPUs can
+            work on the query in parallel.
           </para>
 
           <para>
@@ -9608,8 +9609,8 @@
             bytes of index memory, and every unique index uses 25 bytes
             per record of index memory (in addition to some data memory
             because these are stored in a separate table). This is
-            because there is no storage of the primary key in the index
-            memory anymore.
+            because the primary key is not stored in the index memory
+            anymore.
           </para>
         </listitem>
 
@@ -9617,7 +9618,7 @@
           <para>
             <emphasis role="bold">Query Cache Enabled for MySQL
             Cluster</emphasis>: See <xref linkend="query-cache"/>, for
-            information on configuring ans using the query cache.
+            information on configuring and using the query cache.
           </para>
         </listitem>
 
@@ -9681,7 +9682,7 @@
         <listitem>
           <para>
             <emphasis role="bold">Integration of MySQL Cluster into
-            MySQL Replication</emphasis>: This will make it possible to
+            MySQL replication</emphasis>: This will make it possible to
             update from any MySQL Server in the cluster and still have
             the MySQL Replication handled by one of the MySQL Servers in
             the cluster and the installation on the slave side
@@ -9700,12 +9701,12 @@
 
         <listitem>
           <para>
-            <emphasis role="bold">Variable sized records</emphasis>: A
+            <emphasis role="bold">Variable-sized records</emphasis>: A
             column defined as <literal>VARCHAR(255)</literal> currently
             uses 260 bytes of storage independent of what is stored in
-            any particular record. In MySQL 5.1 Cluster tables only the
-            portion of the field actually taken up by the record will be
-            stored. This will make possible a reduction in space
+            any particular record. In MySQL 5.1 Cluster tables, only the
+            portion of the column actually taken up by the record will
+            be stored. This will make possible a reduction in space
             requirements for such columns by a factor of 5 in many
             cases.
           </para>
@@ -9713,7 +9714,7 @@
 
         <listitem>
           <para>
-            <emphasis role="bold">User-defined Partitioning</emphasis>:
+            <emphasis role="bold">User-defined partitioning</emphasis>:
             Users will be able to define partitions based on the fields
             part of the primary key. The MySQL Server will be able to
             discover whether it is possible to prune away some of the
@@ -9730,15 +9731,15 @@
 
       <para>
         In addition, we are working to increase the 8KB size limit for
-        rows containing columns of types other than BLOB or TEXT in
-        Cluster tables. This is due to the fact that rows are currently
-        fixed in size and the page size is 32,768 bytes (minus 128 bytes
-        for the row header). Currently, this means that if we allowed
-        more than 8KB per record, any remaining space (up to
-        approximately 14,000 bytes) would be left empty. In MySQL 5.1,
-        we plan to fix this limitation so that using more than 8KB in a
-        given row does not result in the remainder of the page being
-        wasted.
+        rows containing columns of types other than
+        <literal>BLOB</literal> or <literal>TEXT</literal> in Cluster
+        tables. This is due to the fact that rows are currently fixed in
+        size and the page size is 32,768 bytes (minus 128 bytes for the
+        row header). Currently, this means that if we allowed more than
+        8KB per record, any remaining space (up to approximately 14,000
+        bytes) would be left empty. In MySQL 5.1, we plan to fix this
+        limitation so that using more than 8KB in a given row does not
+        result in the remainder of the page being wasted.
       </para>
 
     </section>
@@ -9759,10 +9760,27 @@
       [js] Add cross-references.
     </remark>
 
+    <para>
+      This section answers questions that are often asked about MySQL
+      Cluster.
+    </para>
+
     <itemizedlist>
 
       <listitem>
         <para>
+          <emphasis>What does <quote>NDB</quote> mean?</emphasis>
+        </para>
+
+        <para>
+          This stands for
+          <quote><emphasis role="bold">N</emphasis>etwork
+          <emphasis role="bold">D</emphasis>ata<emphasis role="bold">b</emphasis>ase.</quote>
+        </para>
+      </listitem>
+
+      <listitem>
+        <para>
           <emphasis>What's the difference in using Cluster vs. using
           replication?</emphasis>
         </para>
@@ -9778,10 +9796,10 @@
           slave or not applied at all, but replication does not
           guarantee that all data on the master and the slave will be
           consistent at all times. In MySQL Cluster, all data nodes are
-          kept in synch, and a transaction committed by any one data
+          kept in synchrony, and a transaction committed by any one data
           node is committed for all data nodes. In the event of a data
-          node failure, all remaining data nodes will remain in a
-          consistent state.
+          node failure, all remaining data nodes remain in a consistent
+          state.
         </para>
 
         <para>
@@ -9860,11 +9878,11 @@
           are:
         </para>
 
-        <orderedlist>
+        <itemizedlist>
 
           <listitem>
             <para>
-              <emphasis role="bold">management node (MGM
+              <emphasis role="bold">Management node (MGM
               node)</emphasis>: Provides management services for the
               cluster as a whole, including startup, shutdown, backups,
               and configuration data for the other nodes. The management
@@ -9877,7 +9895,7 @@
 
           <listitem>
             <para>
-              <emphasis role="bold">data node</emphasis>: Stores and
+              <emphasis role="bold">Data node</emphasis>: Stores and
               replicates data. Data node functionality is handled by an
               instance of the NDB data node process
               <command>ndbd</command>.
@@ -9888,11 +9906,14 @@
             <para>
               <emphasis role="bold">SQL node</emphasis>: This is simply
               an instance of MySQL Server (<command>mysqld</command>)
-              started with the <command>--ndb-cluster</command> option.
+              that is built with support for the <literal>NDB
+              Cluster</literal> storage engine and started with the
+              <command>--ndb-cluster</command> option to enable the
+              engine.
             </para>
           </listitem>
 
-        </orderedlist>
+        </itemizedlist>
       </listitem>
 
       <listitem>
@@ -9940,8 +9961,8 @@
           will improve performance, and 64-bit CPUs will likely be more
           effective than 32-bit processors. There must be sufficient
           memory on machines used for data nodes to hold each node's
-          share of the database (see <emphasis role="bold">How much RAM
-          do I Need?</emphasis> for more info). Nodes can communicate
+          share of the database (see <emphasis>How much RAM do I
+          Need?</emphasis> for more information). Nodes can communicate
           via a standard TCP/IP network and hardware. For SCI support,
           special networking hardware is required.
         </para>
@@ -9949,23 +9970,137 @@
 
       <listitem>
         <para>
-          <emphasis>Because MySQL Cluster uses TCP/IP, does that mean I
-          can run it over the Internet, with one or more nodes in a
-          remote location?</emphasis>
+          <emphasis>How much RAM do I need? Is it possible to use disk
+          memory at all?</emphasis>
         </para>
 
         <para>
-          It is extremely important to keep in mind that communications
-          between the nodes in a MySQL Cluster are not secure; they are
-          neither encrypted nor safeguarded by any other protective
-          mechanism. The most secure configuration for a cluster is in a
-          private network behind a firewall, with no direct access to
-          any Cluster data or management nodes from outside. (For SQL
-          nodes, you should take the same precautions as you would with
-          any other instance of the MySQL server.)
+          Currently, Cluster is in-memory only. This means that all
+          table data (including indexes) is stored in RAM. Therefore, if
+          your data takes up 1 gigabyte of space and you wish to
+          replicate it once in the cluster, you need 2 gigabytes of
+          memory to do so. This in addition to the memory required by
+          the operating system and any applications running on the
+          cluster computers.
         </para>
 
         <para>
+          You can use the following formula for obtaining a rough
+          estimate of how much RAM is needed for each data node in the
+          cluster:
+        </para>
+
+<programlisting>
+(SizeofDatabase &times; NumberOfReplicas &times; 1.1 ) / NumberOfDataNodes
+</programlisting>
+
+        <para>
+          To calculate the memory requirements more exactly requires
+          determining, for each table in the cluster database, the
+          storage space required per row (see
+          <xref linkend="storage-requirements"/>, for details), and
+          multiplying this by the number of rows. You must also remember
+          to account for any column indexes as follows:
+        </para>
+
+        <itemizedlist>
+
+          <listitem>
+            <para>
+              Each primary key or hash index created for an
+              <literal>NDBCluster</literal> table requires 21-25 bytes
+              per record. These indexes use
+              <literal>IndexMemory</literal>.
+            </para>
+          </listitem>
+
+          <listitem>
+            <para>
+              Each ordered index requires 10 bytes storage per record,
+              using <literal>DataMemory</literal>.
+            </para>
+          </listitem>
+
+          <listitem>
+            <para>
+              Creating a primary key or unique index also creates an
+              ordered index, unless this index is created with
+              <literal>USING HASH</literal>. In other words, if created
+              without <literal>USING HASH</literal>, a primary key or
+              unique index on a Cluster table takes up 31-35 bytes per
+              record in MySQL &current-series;.
+            </para>
+
+            <para>
+              Note that creating MySQL Cluster tables with
+              <literal>USING HASH</literal> for all primary keys and
+              unique indexes will generally cause table updates to run
+              more quickly. This is due to the fact that less memory is
+              required (because no ordered indexes are created), and
+              that less CPU must be utilized (because fewer indexes must
+              be read and possibly updated).
+            </para>
+          </listitem>
+
+        </itemizedlist>
+
+        <para>
+          It is especially important to keep in mind that
+          <emphasis>every MySQL Cluster table must have a primary
+          key</emphasis>. The <literal>NDB</literal> storage engine
+          creates a primary key automatically if none is defined, and
+          this primary key is created without <literal>USING
+          HASH</literal>.
+        </para>
+
+        <para>
+          There is no easy way to determine exactly how much memory is
+          being used for storage of Cluster indexes at any given time;
+          however, warnings are written to the Cluster log when 80% of
+          available <literal>DataMemory</literal> or
+          <literal>IndexMemory</literal> is in use, and again when use
+          reaches 85%, 90%, and so on.
+        </para>
+
+        <para>
+          We often see questions from users who report that, when they
+          are trying to populate a Cluster database, the loading process
+          terminates prematurely and an error message like this one is
+          observed:
+        </para>
+
+<programlisting>
+ERROR 1114: The table 'my_cluster_table' is full
+</programlisting>
+
+        <para>
+          When this occurs, the cause is very likely to be that your
+          setup does not provide sufficient RAM for all table data and
+          all indexes, <emphasis>including the primary key required by
+          the <literal>NDB</literal> storage engine and automatically
+          created in the event that the table definition does not
+          include the definition of a primary key</emphasis>.
+        </para>
+
+        <para>
+          It is also worth noting that all data nodes should have the
+          same amount of RAM, as no data node in a cluster can use more
+          memory than the least amount available to any individual data
+          node. In other words, if there are three computers hosting
+          Cluster data nodes, with two of these having 3GB of RAM
+          available to store Cluster data, and one having only 1GB RAM,
+          then each data node can devote only 1GB to clustering.
+        </para>
+      </listitem>
+
+      <listitem>
+        <para>
+          <emphasis>Because MySQL Cluster uses TCP/IP, does that mean I
+          can run it over the Internet, with one or more nodes in a
+          remote location?</emphasis>
+        </para>
+
+        <para>
           It is very doubtful in any case that a cluster would perform
           reliably under such conditions, as MySQL Cluster was designed
           and implemented with the assumption that it would be run under
@@ -9974,6 +10109,17 @@
           Ethernet (preferably the latter). We neither test nor warrant
           its performance using anything slower than this.
         </para>
+
+        <para>
+          Also, it is extremely important to keep in mind that
+          communications between the nodes in a MySQL Cluster are not
+          secure; they are neither encrypted nor safeguarded by any
+          other protective mechanism. The most secure configuration for
+          a cluster is in a private network behind a firewall, with no
+          direct access to any Cluster data or management nodes from
+          outside. (For SQL nodes, you should take the same precautions
+          as you would with any other instance of the MySQL server.)
+        </para>
       </listitem>
 
       <listitem>
@@ -9985,7 +10131,7 @@
         <para>
           No. Although some specialized commands are used to manage and
           configure the cluster itself, only standard (My)SQL queries
-          and commands are required for:
+          and commands are required for the following operations:
         </para>
 
         <itemizedlist>
@@ -10032,15 +10178,15 @@
           There are two ways in which this can be done:
         </para>
 
-        <orderedlist>
+        <itemizedlist>
 
           <listitem>
             <para>
-              From within the MySQL Monitor, use <command>SHOW
-              ERRORS</command> or <command>SHOW WARNINGS</command>
-              immediately upon being notified of the error or warning
-              condition. These can also be displayed in MySQL Query
-              Browser.
+              From within the <command>mysql</command> client, use
+              <command>SHOW ERRORS</command> or <command>SHOW
+              WARNINGS</command> immediately upon being notified of the
+              error or warning condition. Errors and warnings also be
+              displayed in MySQL Query Browser.
             </para>
           </listitem>
 
@@ -10051,7 +10197,7 @@
             </para>
           </listitem>
 
-        </orderedlist>
+        </itemizedlist>
       </listitem>
 
       <listitem>
@@ -10090,19 +10236,6 @@
         </para>
       </listitem>
 
-      <listitem>
-        <para>
-          <emphasis>What does <quote>NDB</quote> mean?</emphasis>
-        </para>
-
-        <para>
-          This stands for
-          <quote><emphasis role="bold">N</emphasis>etwork
-          <emphasis role="bold">D</emphasis>ata<emphasis
-role="bold">b</emphasis>ase.</quote>
-        </para>
-      </listitem>
-
 <!--  
       <listitem>
         <remark role="todo">
@@ -10158,132 +10291,6 @@
 
       <listitem>
         <para>
-          <emphasis>How much RAM do I need? Is it possible to use disk
-          memory at all?</emphasis>
-        </para>
-
-        <para>
-          Currently, Cluster is in-memory only. This means that all
-          table data (including indexes) is stored in RAM. Therefore, if
-          your data takes up 1 gigabyte of space and you wish to
-          replicate it once in the cluster, you need 2 gigabytes of
-          memory to do so. This in addition to the memory required by
-          the operating system and any applications running on the
-          cluster computers.
-        </para>
-
-        <para>
-          You can use the following formula for obtaining a rough
-          estimate of how much RAM is needed for each data node in the
-          cluster:
-        </para>
-
-<programlisting>
-(SizeofDatabase * NumberOfReplicas * 1.1 ) / NumberOfDataNodes
-</programlisting>
-
-        <para>
-          To calculate the memory requirements more exactly requires
-          determining, for each table in the cluster database, the
-          storage space required per row (see
-          <xref linkend="storage-requirements"/>, for details), and
-          multiplying this by the number of rows. You must also remember
-          to account for any column indexes as follows:
-        </para>
-
-        <itemizedlist>
-
-          <listitem>
-            <para>
-              Each primary key or hash index created for an
-              <literal>NDBCluster</literal> table requires 21-25 bytes
-              per record. These indexes use
-              <literal>IndexMemory</literal>.
-            </para>
-          </listitem>
-
-          <listitem>
-            <para>
-              Each ordered index requires 10 bytes storage per record,
-              using <literal>DataMemory</literal>.
-            </para>
-          </listitem>
-
-          <listitem>
-            <para>
-              Creating a primary key or unique index also creates an
-              ordered index, unless this index is created with
-              <literal>USING HASH</literal>. In other words, if created
-              without <literal>USING HASH</literal>, a primary key or
-              unique index on a Cluster table takes up 31-35 bytes per
-              record in MySQL &current-series;.
-            </para>
-
-            <para>
-              Note that creating MySQL Cluster tables with
-              <literal>USING HASH</literal> for all primary keys and
-              unique indexes will generally cause table updates to run
-              more quickly. This is due to the fact that less memory is
-              required (because no ordered indexes are created), and
-              that less CPU must be utilized (because fewer indexes must
-              be read and possibly updated).
-            </para>
-          </listitem>
-
-        </itemizedlist>
-
-        <para>
-          It is especially important to keep in mind that
-          <emphasis>every MySQL Cluster table must have a primary
-          key</emphasis>. The <literal>NDB</literal> storage engine
-          creates a primary key automatically if none is defined, and
-          this primary key is created without <literal>USING
-          HASH</literal>.
-        </para>
-
-        <para>
-          There is no easy way to determine exactly how much memory is
-          being used for storage of Cluster indexes at any given time;
-          however, warnings are written to the Cluster log when 80% of
-          available <literal>DataMemory</literal> or
-          <literal>IndexMemory</literal> is in use, and again when 85%,
-          90%, and so on is in use.
-        </para>
-
-        <para>
-          We often see questions from users who report that, when they
-          are trying to populate a Cluster database, the loading process
-          terminates prematurely and an error message like this one is
-          observed:
-        </para>
-
-<programlisting>
-ERROR 1114: The table 'my_cluster_table' is full
-</programlisting>
-
-        <para>
-          When this occurs, the cause is very likely to be that your
-          setup does not provide sufficient RAM for all table data and
-          all indexes, <emphasis>including the primary key required by
-          the <literal>NDB</literal> storage engine and automatically
-          created in the event that the table definition does not
-          include the definition of a primary key</emphasis>.
-        </para>
-
-        <para>
-          It is also worth noting that all data nodes should have the
-          same amount of RAM, as no data node in a cluster can use more
-          memory than the least amount available to any individual data
-          node. In other words, if there are three computers hosting
-          Cluster data nodes, with two of these having three gigabytes
-          of RAM available to store Cluster data, and one having only
-          one GB RAM, then each data node can devote only one GB to
-          clustering.
-        </para>
-      </listitem>
-
-      <listitem>
-        <para>
           <emphasis>In the event of a catastrophic failure &mdash; say,
           for instance, the whole city loses power
           <emphasis role="bold">and</emphasis> my UPS fails &mdash;
@@ -10291,8 +10298,8 @@
         </para>
 
         <para>
-          All committed transactions are logged. Therefore, while it is
-          possible that some data could be lost in the event of a
+          All committed transactions are logged. Therefore, although it
+          is possible that some data could be lost in the event of a
           catastrophe, this should be quite limited. Data loss can be
           further reduced by minimizing the number of operations per
           transaction. (It is not a good idea to perform large numbers
@@ -10322,7 +10329,7 @@
 
         <para>
           It is possible but not advisable. One of the chief reasons to
-          run a cluster is to provide redundancy; to enjoy the full
+          run a cluster is to provide redundancy. To enjoy the full
           benefits of this redundancy, each node should reside on a
           separate machine. If you place multiple nodes on a single
           machine and that machine fails, you lose all of those nodes.
@@ -10331,7 +10338,7 @@
           is well worth the expense of an extra machine or two in order
           to safeguard mission-critical data. It also worth noting that
           the requirements for a cluster host running a management node
-          are minimal; this task can be accomplished with a 200 MHz
+          are minimal. This task can be accomplished with a 200 MHz
           Pentium CPU and sufficient RAM for the operating system plus a
           small amount of overhead for the <command>ndb_mgmd</command>
           and <command>ndb_mgm</command> processes.
@@ -10351,7 +10358,7 @@
           steps:
         </para>
 
-        <itemizedlist>
+        <orderedlist>
 
           <listitem>
             <para>
@@ -10379,7 +10386,7 @@
             </para>
           </listitem>
 
-        </itemizedlist>
+        </orderedlist>
 
         <para>
           In a future MySQL Cluster release series, we hope to implement
@@ -10415,14 +10422,14 @@
 
           <listitem>
             <para>
-              <literal>FULLTEXT</literal> indexes and prefix indexes are
+              <literal>FULLTEXT</literal> indexes and index prefixes are
               not supported. Only complete columns may be indexed.
             </para>
           </listitem>
 
           <listitem>
             <para>
-              Spatial extensions are not supported. See
+              Spatial data types are not supported. See
               <xref linkend="spatial-extensions"/>.
             </para>
           </listitem>
@@ -10448,7 +10455,7 @@
             <para>
               The maximum size for a table row is 8 kilobytes, not
               counting <literal>BLOB</literal>s. There is no set limit
-              for the number of rows per table; table size limits depend
+              for the number of rows per table. Table size limits depend
               on a number of factors, in particular on the amount of RAM
               available to each data node.
             </para>
@@ -10493,7 +10500,7 @@
           <literal>ENGINE=NDBCLUSTER</literal>. It is also possible to
           convert existing tables using other storage engines to
           <literal>NDB Cluster</literal> using <literal>ALTER
-          TABLE</literal>, but requires an additional workaround; see
+          TABLE</literal>, but requires an additional workaround. See
           <xref linkend="mysql-cluster-limitations"/>, for details.
         </para>
       </listitem>
@@ -10525,13 +10532,12 @@
 
         <para>
           If one or more nodes in a cluster fail, it is possible that
-          not all cluster nodes will not be able to <quote>see</quote>
-          one another. In fact, it is possible that two sets of nodes
-          might become isolated from one another in a network
-          partitioning, also known as a <quote>split brain</quote>
-          scenario. This type of situation is undesirable because each
-          set of nodes tries to behave as though it is the entire
-          cluster.
+          not all cluster nodes will be able to <quote>see</quote> one
+          another. In fact, it is possible that two sets of nodes might
+          become isolated from one another in a network partitioning,
+          also known as a <quote>split brain</quote> scenario. This type
+          of situation is undesirable because each set of nodes tries to
+          behave as though it is the entire cluster.
         </para>
 
         <para>
@@ -10546,7 +10552,7 @@
         </para>
 
         <para>
-          The preceding information is somewhat simplified; a more
+          The preceding information is somewhat simplified. A more
           complete explanation taking into account node groups follows:
         </para>
 
@@ -10668,7 +10674,7 @@
 </programlisting>
 
         <para>
-          This will cause the <command>ndb_mgm</command>,
+          This causes the <command>ndb_mgm</command>,
           <command>ndb_mgm</command>, and any <command>ndbd</command>
           processes to terminate gracefully. MySQL servers running as
           Cluster SQL nodes can be stopped using <command>mysqladmin
@@ -10692,7 +10698,7 @@
           It can be helpful as a fail-safe. Only one MGM node controls
           the cluster at any given time, but it is possible to configure
           one MGM as primary, and one or more additional management
-          nodes to take over in the evnt that the primary MGM node
+          nodes to take over in the event that the primary MGM node
           fails.
         </para>
 
@@ -10712,10 +10718,11 @@
         </para>
 
         <para>
-          Yes, so long as all machines and operating systems are the
-          same endian. It is also possible to use different MySQL
-          Cluster releases on different nodes; however, we recommend
-          this be done only as part of a rolling upgrade procedure.
+          Yes, so long as all machines and operating systems have the
+          same endianness (all big-endian or all little-endian). It is
+          also possible to use different MySQL Cluster releases on
+          different nodes. However, we recommend this be done only as
+          part of a rolling upgrade procedure.
         </para>
       </listitem>
 
@@ -10862,7 +10869,7 @@
           that a checkpoint has been reached. More specific to Cluster,
           it is a point in time where all committed transactions are
           stored on disk. With regard to the <literal>NDB</literal>
-          storage engine, there are two sorts of checkpoints which work
+          storage engine, there are two types of checkpoints which work
           together to ensure that a consistent view of the cluster's
           data is maintained:
         </para>
@@ -10925,11 +10932,11 @@
         <para>
           This refers to a logical or functional unit of MySQL Cluster,
           and is sometimes also referred to as a <firstterm>cluster
-          node</firstterm>. In the context of MySQl Cluster, we use the
+          node</firstterm>. In the context of MySQL Cluster, we use the
           term <quote>node</quote> to indicate a
           <emphasis>process</emphasis> rather than a physical component
           of the cluster. There are three node types required to
-          implement a working MySQL Cluster. These are:
+          implement a working MySQL Cluster:
         </para>
 
         <itemizedlist>
@@ -11124,27 +11131,18 @@
 
           <listitem>
             <para>
-              TCP/IP (local)
+              TCP/IP
             </para>
 
             <para>
               This is, of course, the familiar network protocol that
-              underlies HTTP, FTP (and so on) on the Internet.
+              underlies HTTP, FTP (and so on) on the Internet. TCP/IP
+              can be used for both local and remote connections.
             </para>
           </listitem>
 
           <listitem>
             <para>
-              TCP/IP (remote)
-            </para>
-
-            <para>
-              Same as above, except as used for communicating remotely.
-            </para>
-          </listitem>
-
-          <listitem>
-            <para>
               SCI
             </para>
 
@@ -11154,7 +11152,7 @@
               <emphasis role="bold">I</emphasis>nterface is a high-speed
               protocol used in building multiprocessor systems and
               parallel-processing applications. Use of SCI with MySQL
-              Cluster requires specialized hardware and is discussed in
+              Cluster requires specialized hardware, as discussed in
               <xref linkend="sci-sockets"/>. For a basic introduction to
               SCI, see
               <ulink url="http://www.dolphinics.com/corporate/scitech.html">this
@@ -11186,8 +11184,8 @@
           is internal to the cluster. Applications using MySQL Cluster
           communicate with SQL nodes just as they do with any other
           version of MySQL Server (via TCP/IP, or through the use of
-          Unix sockets or Windows named pipes). Queries can be sent and
-          results retrieved using the standard MySQL APIs.
+          Unix socket files or Windows named pipes). Queries can be sent
+          and results retrieved using the standard MySQL client APIs.
         </para>
       </listitem>
 
@@ -11232,11 +11230,11 @@
           must have available an amount of RAM equal to the size of the
           database times the number of replicas, divided by the number
           of data nodes. Thus, if the database takes up 1 gigabyte of
-          memory, and you wish to set up the cluster with 4 replicas and
-          8 data nodes, a minimum of 500MB memory will be required per
-          node. Note that this is in addition to any requirements for
-          the operating system and any other applications that might be
-          running on the host.
+          memory, and you wish to set up the cluster with four replicas
+          and eight data nodes, a minimum of 500MB memory will be
+          required per node. Note that this is in addition to any
+          requirements for the operating system and any other
+          applications that might be running on the host.
         </para>
       </listitem>
 

Modified: trunk/refman-5.1/ndbcluster.xml
===================================================================
--- trunk/refman-5.1/ndbcluster.xml	2006-01-31 18:19:58 UTC (rev 1152)
+++ trunk/refman-5.1/ndbcluster.xml	2006-01-31 20:55:32 UTC (rev 1153)
@@ -1452,10 +1452,10 @@
             <xref linkend="mysql-cluster-limitations"/>.) This means
             that, once the <literal>world</literal> database and its
             tables have been created on one data node, you need to issue
-            the statement <literal>CREATE SCHEMA world;</literal>,
-            followed by <literal>FLUSH TABLES;</literal> on each SQL
-            node in the cluster. This will cause the node to recognize
-            the database and read its table definitions.
+            the statement <literal>CREATE SCHEMA world</literal>,
+            followed by <literal>FLUSH TABLES</literal> on each SQL node
+            in the cluster. This will cause the node to recognize the
+            database and read its table definitions.
           </para>
 
           <para>
@@ -5122,7 +5122,7 @@
 
         <para>
           In the following example, we envision a cluster with at least
-          4 hosts, one each for a management server, an SQL node, and
+          four hosts, one each for a management server, an SQL node, and
           two data nodes. The cluster as a whole resides on the
           <literal>172.23.72.*</literal> subnet of a LAN. In addition to
           the usual network connections, the two data nodes are
@@ -5308,10 +5308,10 @@
           also that using SCI Transporters means that the
           <command>ndbd</command> processes never sleep. For this
           reason, SCI Transporters should be used only on machines
-          having at least 2 CPUs dedicated for use by
-          <command>ndbd</command> processes. There should be at least 1
-          CPU per <command>ndbd</command> process, with at least 1 CPU
-          left in reserve to handle operating system activities.
+          having at least two CPUs dedicated for use by
+          <command>ndbd</command> processes. There should be at least
+          one CPU per <command>ndbd</command> process, with at least one
+          CPU left in reserve to handle operating system activities.
         </para>
 
         <itemizedlist>
@@ -11176,8 +11176,8 @@
 
         <listitem>
           <para>
-            <emphasis role="bold">Push-Down Conditions</emphasis>: A
-            query such as
+            <emphasis role="bold">Push-Down Conditions</emphasis>:
+            Consider the following query:
           </para>
 
 <programlisting>
@@ -11185,33 +11185,33 @@
 </programlisting>
 
           <para>
-            will use a full table scan and the condition will be
-            evaluated in the cluster's data nodes. Thus it is not
+            This query will use a full table scan and the condition will
+            be evaluated in the cluster's data nodes. Thus, it is not
             necessary to send the records across the network for
             evaluation. (That is, function transport is used, rather
             than data transport.) Please note that this feature is
             currently disabled by default (pending more thorough
             testing), but it should work in most cases. This feature can
             be enabled through the use of the <literal>SET
-            engine_condition_pushdown=On;</literal> statement.
+            engine_condition_pushdown = On</literal> statement.
             Alternatively, you can run <command>mysqld</command> with
             the this feature enabled by starting the MySQL server with
-            the new <option>--engine-condition-pushdown</option> option
-            flag.
+            the <option>--engine-condition-pushdown</option> option.
           </para>
 
           <para>
-            You can use <literal>EXPLAIN</literal> to determine when
-            push-down conditions are being used.
+            A major benefit of this change is that queries can be
+            executed in parallel. This means that queries against
+            non-indexed columns can run faster than previously by a
+            factor of as much as 5 to 10 times, <emphasis>times the
+            number of data nodes</emphasis>, because multiple CPUs can
+            work on the query in parallel.
           </para>
 
           <para>
-            A major benefit of this change is that queries are now
-            executed in parallel. This means that queries against
-            non-indexed columns can run as much as 5 to 10 times,
-            <emphasis>times the number of data nodes</emphasis>, faster
-            than previously because multiple CPUs can work on the query
-            in parallel.
+            You can use <literal>EXPLAIN</literal> to determine when
+            condition pushdown is being used. See
+            <xref linkend="explain"/>.
           </para>
         </listitem>
 
@@ -11223,8 +11223,8 @@
             bytes of index memory, and every unique index uses 25 bytes
             per record of index memory (in addition to some data memory
             because these are stored in a separate table). This is
-            because there is no storage of the primary key in the index
-            memory anymore.
+            because the primary key is not stored in the index memory
+            anymore.
           </para>
         </listitem>
 
@@ -11232,7 +11232,7 @@
           <para>
             <emphasis role="bold">Query Cache Enabled for MySQL
             Cluster</emphasis>: See <xref linkend="query-cache"/>, for
-            information on configuring ans using the query cache.
+            information on configuring and using the query cache.
           </para>
         </listitem>
 
@@ -11296,7 +11296,7 @@
         <listitem>
           <para>
             <emphasis role="bold">Integration of MySQL Cluster into
-            MySQL Replication</emphasis>: This will make it possible to
+            MySQL replication</emphasis>: This will make it possible to
             update from any MySQL Server in the cluster and still have
             the MySQL Replication handled by one of the MySQL Servers in
             the cluster and the installation on the slave side
@@ -11315,12 +11315,12 @@
 
         <listitem>
           <para>
-            <emphasis role="bold">Variable sized records</emphasis>: A
+            <emphasis role="bold">Variable-sized records</emphasis>: A
             column defined as <literal>VARCHAR(255)</literal> currently
             uses 260 bytes of storage independent of what is stored in
-            any particular record. In MySQL 5.1 Cluster tables only the
-            portion of the field actually taken up by the record will be
-            stored. This will make possible a reduction in space
+            any particular record. In MySQL 5.1 Cluster tables, only the
+            portion of the column actually taken up by the record will
+            be stored. This will make possible a reduction in space
             requirements for such columns by a factor of 5 in many
             cases.
           </para>
@@ -11328,7 +11328,7 @@
 
         <listitem>
           <para>
-            <emphasis role="bold">User-defined Partitioning</emphasis>:
+            <emphasis role="bold">User-defined partitioning</emphasis>:
             Users will be able to define partitions based on the fields
             part of the primary key. The MySQL Server will be able to
             discover whether it is possible to prune away some of the
@@ -11345,15 +11345,15 @@
 
       <para>
         In addition, we are working to increase the 8KB size limit for
-        rows containing columns of types other than BLOB or TEXT in
-        Cluster tables. This is due to the fact that rows are currently
-        fixed in size and the page size is 32,768 bytes (minus 128 bytes
-        for the row header). Currently, this means that if we allowed
-        more than 8KB per record, any remaining space (up to
-        approximately 14,000 bytes) would be left empty. In MySQL 5.1,
-        we plan to fix this limitation so that using more than 8KB in a
-        given row does not result in the remainder of the page being
-        wasted.
+        rows containing columns of types other than
+        <literal>BLOB</literal> or <literal>TEXT</literal> in Cluster
+        tables. This is due to the fact that rows are currently fixed in
+        size and the page size is 32,768 bytes (minus 128 bytes for the
+        row header). Currently, this means that if we allowed more than
+        8KB per record, any remaining space (up to approximately 14,000
+        bytes) would be left empty. In MySQL 5.1, we plan to fix this
+        limitation so that using more than 8KB in a given row does not
+        result in the remainder of the page being wasted.
       </para>
 
     </section>
@@ -11374,10 +11374,27 @@
       [js] Add cross-references.
     </remark>
 
+    <para>
+      This section answers questions that are often asked about MySQL
+      Cluster.
+    </para>
+
     <itemizedlist>
 
       <listitem>
         <para>
+          <emphasis>What does <quote>NDB</quote> mean?</emphasis>
+        </para>
+
+        <para>
+          This stands for
+          <quote><emphasis role="bold">N</emphasis>etwork
+          <emphasis role="bold">D</emphasis>ata<emphasis role="bold">b</emphasis>ase.</quote>
+        </para>
+      </listitem>
+
+      <listitem>
+        <para>
           <emphasis>What's the difference in using Cluster vs. using
           replication?</emphasis>
         </para>
@@ -11393,10 +11410,10 @@
           slave or not applied at all, but replication does not
           guarantee that all data on the master and the slave will be
           consistent at all times. In MySQL Cluster, all data nodes are
-          kept in synch, and a transaction committed by any one data
+          kept in synchrony, and a transaction committed by any one data
           node is committed for all data nodes. In the event of a data
-          node failure, all remaining data nodes will remain in a
-          consistent state.
+          node failure, all remaining data nodes remain in a consistent
+          state.
         </para>
 
         <para>
@@ -11475,11 +11492,11 @@
           are:
         </para>
 
-        <orderedlist>
+        <itemizedlist>
 
           <listitem>
             <para>
-              <emphasis role="bold">management node (MGM
+              <emphasis role="bold">Management node (MGM
               node)</emphasis>: Provides management services for the
               cluster as a whole, including startup, shutdown, backups,
               and configuration data for the other nodes. The management
@@ -11492,7 +11509,7 @@
 
           <listitem>
             <para>
-              <emphasis role="bold">data node</emphasis>: Stores and
+              <emphasis role="bold">Data node</emphasis>: Stores and
               replicates data. Data node functionality is handled by an
               instance of the NDB data node process
               <command>ndbd</command>.
@@ -11503,11 +11520,14 @@
             <para>
               <emphasis role="bold">SQL node</emphasis>: This is simply
               an instance of MySQL Server (<command>mysqld</command>)
-              started with the <command>--ndb-cluster</command> option.
+              that is built with support for the <literal>NDB
+              Cluster</literal> storage engine and started with the
+              <command>--ndb-cluster</command> option to enable the
+              engine.
             </para>
           </listitem>
 
-        </orderedlist>
+        </itemizedlist>
       </listitem>
 
       <listitem>
@@ -11555,8 +11575,8 @@
           will improve performance, and 64-bit CPUs will likely be more
           effective than 32-bit processors. There must be sufficient
           memory on machines used for data nodes to hold each node's
-          share of the database (see <emphasis role="bold">How much RAM
-          do I Need?</emphasis> for more info). Nodes can communicate
+          share of the database (see <emphasis>How much RAM do I
+          Need?</emphasis> for more information). Nodes can communicate
           via a standard TCP/IP network and hardware. For SCI support,
           special networking hardware is required.
         </para>
@@ -11564,23 +11584,137 @@
 
       <listitem>
         <para>
-          <emphasis>Because MySQL Cluster uses TCP/IP, does that mean I
-          can run it over the Internet, with one or more nodes in a
-          remote location?</emphasis>
+          <emphasis>How much RAM do I need? Is it possible to use disk
+          memory at all?</emphasis>
         </para>
 
         <para>
-          It is extremely important to keep in mind that communications
-          between the nodes in a MySQL Cluster are not secure; they are
-          neither encrypted nor safeguarded by any other protective
-          mechanism. The most secure configuration for a cluster is in a
-          private network behind a firewall, with no direct access to
-          any Cluster data or management nodes from outside. (For SQL
-          nodes, you should take the same precautions as you would with
-          any other instance of the MySQL server.)
+          Currently, Cluster is in-memory only. This means that all
+          table data (including indexes) is stored in RAM. Therefore, if
+          your data takes up 1 gigabyte of space and you wish to
+          replicate it once in the cluster, you need 2 gigabytes of
+          memory to do so. This in addition to the memory required by
+          the operating system and any applications running on the
+          cluster computers.
         </para>
 
         <para>
+          You can use the following formula for obtaining a rough
+          estimate of how much RAM is needed for each data node in the
+          cluster:
+        </para>
+
+<programlisting>
+(SizeofDatabase &times; NumberOfReplicas &times; 1.1 ) / NumberOfDataNodes
+</programlisting>
+
+        <para>
+          To calculate the memory requirements more exactly requires
+          determining, for each table in the cluster database, the
+          storage space required per row (see
+          <xref linkend="storage-requirements"/>, for details), and
+          multiplying this by the number of rows. You must also remember
+          to account for any column indexes as follows:
+        </para>
+
+        <itemizedlist>
+
+          <listitem>
+            <para>
+              Each primary key or hash index created for an
+              <literal>NDBCluster</literal> table requires 21-25 bytes
+              per record. These indexes use
+              <literal>IndexMemory</literal>.
+            </para>
+          </listitem>
+
+          <listitem>
+            <para>
+              Each ordered index requires 10 bytes storage per record,
+              using <literal>DataMemory</literal>.
+            </para>
+          </listitem>
+
+          <listitem>
+            <para>
+              Creating a primary key or unique index also creates an
+              ordered index, unless this index is created with
+              <literal>USING HASH</literal>. In other words, if created
+              without <literal>USING HASH</literal>, a primary key or
+              unique index on a Cluster table takes up 31-35 bytes per
+              record in MySQL &current-series;.
+            </para>
+
+            <para>
+              Note that creating MySQL Cluster tables with
+              <literal>USING HASH</literal> for all primary keys and
+              unique indexes will generally cause table updates to run
+              more quickly. This is due to the fact that less memory is
+              required (because no ordered indexes are created), and
+              that less CPU must be utilized (because fewer indexes must
+              be read and possibly updated).
+            </para>
+          </listitem>
+
+        </itemizedlist>
+
+        <para>
+          It is especially important to keep in mind that
+          <emphasis>every MySQL Cluster table must have a primary
+          key</emphasis>. The <literal>NDB</literal> storage engine
+          creates a primary key automatically if none is defined, and
+          this primary key is created without <literal>USING
+          HASH</literal>.
+        </para>
+
+        <para>
+          There is no easy way to determine exactly how much memory is
+          being used for storage of Cluster indexes at any given time;
+          however, warnings are written to the Cluster log when 80% of
+          available <literal>DataMemory</literal> or
+          <literal>IndexMemory</literal> is in use, and again when use
+          reaches 85%, 90%, and so on.
+        </para>
+
+        <para>
+          We often see questions from users who report that, when they
+          are trying to populate a Cluster database, the loading process
+          terminates prematurely and an error message like this one is
+          observed:
+        </para>
+
+<programlisting>
+ERROR 1114: The table 'my_cluster_table' is full
+</programlisting>
+
+        <para>
+          When this occurs, the cause is very likely to be that your
+          setup does not provide sufficient RAM for all table data and
+          all indexes, <emphasis>including the primary key required by
+          the <literal>NDB</literal> storage engine and automatically
+          created in the event that the table definition does not
+          include the definition of a primary key</emphasis>.
+        </para>
+
+        <para>
+          It is also worth noting that all data nodes should have the
+          same amount of RAM, as no data node in a cluster can use more
+          memory than the least amount available to any individual data
+          node. In other words, if there are three computers hosting
+          Cluster data nodes, with two of these having 3GB of RAM
+          available to store Cluster data, and one having only 1GB RAM,
+          then each data node can devote only 1GB to clustering.
+        </para>
+      </listitem>
+
+      <listitem>
+        <para>
+          <emphasis>Because MySQL Cluster uses TCP/IP, does that mean I
+          can run it over the Internet, with one or more nodes in a
+          remote location?</emphasis>
+        </para>
+
+        <para>
           It is very doubtful in any case that a cluster would perform
           reliably under such conditions, as MySQL Cluster was designed
           and implemented with the assumption that it would be run under
@@ -11589,6 +11723,17 @@
           Ethernet (preferably the latter). We neither test nor warrant
           its performance using anything slower than this.
         </para>
+
+        <para>
+          Also, it is extremely important to keep in mind that
+          communications between the nodes in a MySQL Cluster are not
+          secure; they are neither encrypted nor safeguarded by any
+          other protective mechanism. The most secure configuration for
+          a cluster is in a private network behind a firewall, with no
+          direct access to any Cluster data or management nodes from
+          outside. (For SQL nodes, you should take the same precautions
+          as you would with any other instance of the MySQL server.)
+        </para>
       </listitem>
 
       <listitem>
@@ -11600,7 +11745,7 @@
         <para>
           No. Although some specialized commands are used to manage and
           configure the cluster itself, only standard (My)SQL queries
-          and commands are required for:
+          and commands are required for the following operations:
         </para>
 
         <itemizedlist>
@@ -11647,15 +11792,15 @@
           There are two ways in which this can be done:
         </para>
 
-        <orderedlist>
+        <itemizedlist>
 
           <listitem>
             <para>
-              From within the MySQL Monitor, use <command>SHOW
-              ERRORS</command> or <command>SHOW WARNINGS</command>
-              immediately upon being notified of the error or warning
-              condition. These can also be displayed in MySQL Query
-              Browser.
+              From within the <command>mysql</command> client, use
+              <command>SHOW ERRORS</command> or <command>SHOW
+              WARNINGS</command> immediately upon being notified of the
+              error or warning condition. Errors and warnings also be
+              displayed in MySQL Query Browser.
             </para>
           </listitem>
 
@@ -11666,7 +11811,7 @@
             </para>
           </listitem>
 
-        </orderedlist>
+        </itemizedlist>
       </listitem>
 
       <listitem>
@@ -11705,19 +11850,6 @@
         </para>
       </listitem>
 
-      <listitem>
-        <para>
-          <emphasis>What does <quote>NDB</quote> mean?</emphasis>
-        </para>
-
-        <para>
-          This stands for
-          <quote><emphasis role="bold">N</emphasis>etwork
-          <emphasis role="bold">D</emphasis>ata<emphasis
-role="bold">b</emphasis>ase.</quote>
-        </para>
-      </listitem>
-
 <!--  
       <listitem>
         <remark role="todo">
@@ -11773,132 +11905,6 @@
 
       <listitem>
         <para>
-          <emphasis>How much RAM do I need? Is it possible to use disk
-          memory at all?</emphasis>
-        </para>
-
-        <para>
-          Currently, Cluster is in-memory only. This means that all
-          table data (including indexes) is stored in RAM. Therefore, if
-          your data takes up 1 gigabyte of space and you wish to
-          replicate it once in the cluster, you need 2 gigabytes of
-          memory to do so. This in addition to the memory required by
-          the operating system and any applications running on the
-          cluster computers.
-        </para>
-
-        <para>
-          You can use the following formula for obtaining a rough
-          estimate of how much RAM is needed for each data node in the
-          cluster:
-        </para>
-
-<programlisting>
-(SizeofDatabase * NumberOfReplicas * 1.1 ) / NumberOfDataNodes
-</programlisting>
-
-        <para>
-          To calculate the memory requirements more exactly requires
-          determining, for each table in the cluster database, the
-          storage space required per row (see
-          <xref linkend="storage-requirements"/>, for details), and
-          multiplying this by the number of rows. You must also remember
-          to account for any column indexes as follows:
-        </para>
-
-        <itemizedlist>
-
-          <listitem>
-            <para>
-              Each primary key or hash index created for an
-              <literal>NDBCluster</literal> table requires 21-25 bytes
-              per record. These indexes use
-              <literal>IndexMemory</literal>.
-            </para>
-          </listitem>
-
-          <listitem>
-            <para>
-              Each ordered index requires 10 bytes storage per record,
-              using <literal>DataMemory</literal>.
-            </para>
-          </listitem>
-
-          <listitem>
-            <para>
-              Creating a primary key or unique index also creates an
-              ordered index, unless this index is created with
-              <literal>USING HASH</literal>. In other words, if created
-              without <literal>USING HASH</literal>, a primary key or
-              unique index on a Cluster table takes up 31-35 bytes per
-              record in MySQL &current-series;.
-            </para>
-
-            <para>
-              Note that creating MySQL Cluster tables with
-              <literal>USING HASH</literal> for all primary keys and
-              unique indexes will generally cause table updates to run
-              more quickly. This is due to the fact that less memory is
-              required (because no ordered indexes are created), and
-              that less CPU must be utilized (because fewer indexes must
-              be read and possibly updated).
-            </para>
-          </listitem>
-
-        </itemizedlist>
-
-        <para>
-          It is especially important to keep in mind that
-          <emphasis>every MySQL Cluster table must have a primary
-          key</emphasis>. The <literal>NDB</literal> storage engine
-          creates a primary key automatically if none is defined, and
-          this primary key is created without <literal>USING
-          HASH</literal>.
-        </para>
-
-        <para>
-          There is no easy way to determine exactly how much memory is
-          being used for storage of Cluster indexes at any given time;
-          however, warnings are written to the Cluster log when 80% of
-          available <literal>DataMemory</literal> or
-          <literal>IndexMemory</literal> is in use, and again when 85%,
-          90%, and so on is in use.
-        </para>
-
-        <para>
-          We often see questions from users who report that, when they
-          are trying to populate a Cluster database, the loading process
-          terminates prematurely and an error message like this one is
-          observed:
-        </para>
-
-<programlisting>
-ERROR 1114: The table 'my_cluster_table' is full
-</programlisting>
-
-        <para>
-          When this occurs, the cause is very likely to be that your
-          setup does not provide sufficient RAM for all table data and
-          all indexes, <emphasis>including the primary key required by
-          the <literal>NDB</literal> storage engine and automatically
-          created in the event that the table definition does not
-          include the definition of a primary key</emphasis>.
-        </para>
-
-        <para>
-          It is also worth noting that all data nodes should have the
-          same amount of RAM, as no data node in a cluster can use more
-          memory than the least amount available to any individual data
-          node. In other words, if there are three computers hosting
-          Cluster data nodes, with two of these having three gigabytes
-          of RAM available to store Cluster data, and one having only
-          one GB RAM, then each data node can devote only one GB to
-          clustering.
-        </para>
-      </listitem>
-
-      <listitem>
-        <para>
           <emphasis>In the event of a catastrophic failure &mdash; say,
           for instance, the whole city loses power
           <emphasis role="bold">and</emphasis> my UPS fails &mdash;
@@ -11906,8 +11912,8 @@
         </para>
 
         <para>
-          All committed transactions are logged. Therefore, while it is
-          possible that some data could be lost in the event of a
+          All committed transactions are logged. Therefore, although it
+          is possible that some data could be lost in the event of a
           catastrophe, this should be quite limited. Data loss can be
           further reduced by minimizing the number of operations per
           transaction. (It is not a good idea to perform large numbers
@@ -11937,7 +11943,7 @@
 
         <para>
           It is possible but not advisable. One of the chief reasons to
-          run a cluster is to provide redundancy; to enjoy the full
+          run a cluster is to provide redundancy. To enjoy the full
           benefits of this redundancy, each node should reside on a
           separate machine. If you place multiple nodes on a single
           machine and that machine fails, you lose all of those nodes.
@@ -11946,7 +11952,7 @@
           is well worth the expense of an extra machine or two in order
           to safeguard mission-critical data. It also worth noting that
           the requirements for a cluster host running a management node
-          are minimal; this task can be accomplished with a 200 MHz
+          are minimal. This task can be accomplished with a 200 MHz
           Pentium CPU and sufficient RAM for the operating system plus a
           small amount of overhead for the <command>ndb_mgmd</command>
           and <command>ndb_mgm</command> processes.
@@ -11966,7 +11972,7 @@
           steps:
         </para>
 
-        <itemizedlist>
+        <orderedlist>
 
           <listitem>
             <para>
@@ -11994,7 +12000,7 @@
             </para>
           </listitem>
 
-        </itemizedlist>
+        </orderedlist>
 
         <para>
           In a future MySQL Cluster release series, we hope to implement
@@ -12030,14 +12036,14 @@
 
           <listitem>
             <para>
-              <literal>FULLTEXT</literal> indexes and prefix indexes are
+              <literal>FULLTEXT</literal> indexes and index prefixes are
               not supported. Only complete columns may be indexed.
             </para>
           </listitem>
 
           <listitem>
             <para>
-              Spatial extensions are not supported. See
+              Spatial data types are not supported. See
               <xref linkend="spatial-extensions"/>.
             </para>
           </listitem>
@@ -12063,7 +12069,7 @@
             <para>
               The maximum size for a table row is 8 kilobytes, not
               counting <literal>BLOB</literal>s. There is no set limit
-              for the number of rows per table; table size limits depend
+              for the number of rows per table. Table size limits depend
               on a number of factors, in particular on the amount of RAM
               available to each data node.
             </para>
@@ -12108,7 +12114,7 @@
           <literal>ENGINE=NDBCLUSTER</literal>. It is also possible to
           convert existing tables using other storage engines to
           <literal>NDB Cluster</literal> using <literal>ALTER
-          TABLE</literal>, but requires an additional workaround; see
+          TABLE</literal>, but requires an additional workaround. See
           <xref linkend="mysql-cluster-limitations"/>, for details.
         </para>
       </listitem>
@@ -12140,13 +12146,12 @@
 
         <para>
           If one or more nodes in a cluster fail, it is possible that
-          not all cluster nodes will not be able to <quote>see</quote>
-          one another. In fact, it is possible that two sets of nodes
-          might become isolated from one another in a network
-          partitioning, also known as a <quote>split brain</quote>
-          scenario. This type of situation is undesirable because each
-          set of nodes tries to behave as though it is the entire
-          cluster.
+          not all cluster nodes will be able to <quote>see</quote> one
+          another. In fact, it is possible that two sets of nodes might
+          become isolated from one another in a network partitioning,
+          also known as a <quote>split brain</quote> scenario. This type
+          of situation is undesirable because each set of nodes tries to
+          behave as though it is the entire cluster.
         </para>
 
         <para>
@@ -12161,7 +12166,7 @@
         </para>
 
         <para>
-          The preceding information is somewhat simplified; a more
+          The preceding information is somewhat simplified. A more
           complete explanation taking into account node groups follows:
         </para>
 
@@ -12283,7 +12288,7 @@
 </programlisting>
 
         <para>
-          This will cause the <command>ndb_mgm</command>,
+          This causes the <command>ndb_mgm</command>,
           <command>ndb_mgm</command>, and any <command>ndbd</command>
           processes to terminate gracefully. MySQL servers running as
           Cluster SQL nodes can be stopped using <command>mysqladmin
@@ -12307,7 +12312,7 @@
           It can be helpful as a fail-safe. Only one MGM node controls
           the cluster at any given time, but it is possible to configure
           one MGM as primary, and one or more additional management
-          nodes to take over in the evnt that the primary MGM node
+          nodes to take over in the event that the primary MGM node
           fails.
         </para>
 
@@ -12327,10 +12332,11 @@
         </para>
 
         <para>
-          Yes, so long as all machines and operating systems are the
-          same endian. It is also possible to use different MySQL
-          Cluster releases on different nodes; however, we recommend
-          this be done only as part of a rolling upgrade procedure.
+          Yes, so long as all machines and operating systems have the
+          same endianness (all big-endian or all little-endian). It is
+          also possible to use different MySQL Cluster releases on
+          different nodes. However, we recommend this be done only as
+          part of a rolling upgrade procedure.
         </para>
       </listitem>
 
@@ -12477,7 +12483,7 @@
           that a checkpoint has been reached. More specific to Cluster,
           it is a point in time where all committed transactions are
           stored on disk. With regard to the <literal>NDB</literal>
-          storage engine, there are two sorts of checkpoints which work
+          storage engine, there are two types of checkpoints which work
           together to ensure that a consistent view of the cluster's
           data is maintained:
         </para>
@@ -12540,11 +12546,11 @@
         <para>
           This refers to a logical or functional unit of MySQL Cluster,
           and is sometimes also referred to as a <firstterm>cluster
-          node</firstterm>. In the context of MySQl Cluster, we use the
+          node</firstterm>. In the context of MySQL Cluster, we use the
           term <quote>node</quote> to indicate a
           <emphasis>process</emphasis> rather than a physical component
           of the cluster. There are three node types required to
-          implement a working MySQL Cluster. These are:
+          implement a working MySQL Cluster:
         </para>
 
         <itemizedlist>
@@ -12739,27 +12745,18 @@
 
           <listitem>
             <para>
-              TCP/IP (local)
+              TCP/IP
             </para>
 
             <para>
               This is, of course, the familiar network protocol that
-              underlies HTTP, FTP (and so on) on the Internet.
+              underlies HTTP, FTP (and so on) on the Internet. TCP/IP
+              can be used for both local and remote connections.
             </para>
           </listitem>
 
           <listitem>
             <para>
-              TCP/IP (remote)
-            </para>
-
-            <para>
-              Same as above, except as used for communicating remotely.
-            </para>
-          </listitem>
-
-          <listitem>
-            <para>
               SCI
             </para>
 
@@ -12769,7 +12766,7 @@
               <emphasis role="bold">I</emphasis>nterface is a high-speed
               protocol used in building multiprocessor systems and
               parallel-processing applications. Use of SCI with MySQL
-              Cluster requires specialized hardware and is discussed in
+              Cluster requires specialized hardware, as discussed in
               <xref linkend="sci-sockets"/>. For a basic introduction to
               SCI, see
               <ulink url="http://www.dolphinics.com/corporate/scitech.html">this
@@ -12801,8 +12798,8 @@
           is internal to the cluster. Applications using MySQL Cluster
           communicate with SQL nodes just as they do with any other
           version of MySQL Server (via TCP/IP, or through the use of
-          Unix sockets or Windows named pipes). Queries can be sent and
-          results retrieved using the standard MySQL APIs.
+          Unix socket files or Windows named pipes). Queries can be sent
+          and results retrieved using the standard MySQL client APIs.
         </para>
       </listitem>
 
@@ -12847,11 +12844,11 @@
           must have available an amount of RAM equal to the size of the
           database times the number of replicas, divided by the number
           of data nodes. Thus, if the database takes up 1 gigabyte of
-          memory, and you wish to set up the cluster with 4 replicas and
-          8 data nodes, a minimum of 500MB memory will be required per
-          node. Note that this is in addition to any requirements for
-          the operating system and any other applications that might be
-          running on the host.
+          memory, and you wish to set up the cluster with four replicas
+          and eight data nodes, a minimum of 500MB memory will be
+          required per node. Note that this is in addition to any
+          requirements for the operating system and any other
+          applications that might be running on the host.
         </para>
       </listitem>
 

Thread
svn commit - mysqldoc@docsrva: r1153 - in trunk: . refman-4.1 refman-5.0 refman-5.1paul31 Jan