svn commit - mysqldoc@docsrva: r6529 - trunk/refman-5.1

[jon]

Author: jstephens
Date: 2007-05-18 16:41:27 +0200 (Fri, 18 May 2007)
New Revision: 6529

Log:

More fixups + reformat.



Modified:
   trunk/refman-5.1/mysql-cluster-limitations-working.xml


Modified: trunk/refman-5.1/mysql-cluster-limitations-working.xml
===================================================================
--- trunk/refman-5.1/mysql-cluster-limitations-working.xml	2007-05-18 13:46:23 UTC (rev
6528)
+++ trunk/refman-5.1/mysql-cluster-limitations-working.xml	2007-05-18 14:41:27 UTC (rev
6529)
Changed blocks: 9, Lines Added: 187, Lines Deleted: 137; 16253 bytes

@@ -15,7 +15,6 @@
 
   <indexterm>
     <primary>limitations of MySQL Cluster</primary>
-<!-- <see>MySQL Cluster limitations</see> -->
   </indexterm>
 
   <para>

@@ -43,9 +42,9 @@
   </para>
 
   <para>
-    (<emphasis role="bold">Note</emphasis>: See the end of this section
-    for a list of issues in MySQL &previous-series; Cluster that have
-    been resolved in the current version.)
+    See <xref linkend="mysql-cluster-limitations-resolved"/> for a list
+    of issues in MySQL Cluster in MySQL &previous-series; that have been
+    resolved in the current version.
   </para>
 
   <note>

@@ -234,17 +233,23 @@
 
           </formalpara>
 
-          <para>
-            As of MySQL 5.1.6, all Cluster tables are by default
-            partitioned by <literal>KEY</literal> using the table's
-            primary key as the partitioning key. If no primary key is
-            explicitly set for the table, the <quote>hidden</quote>
-            primary key automatically created by the
-            <literal>NDB</literal> storage engine is used instead. For
-            additional discussion of these and related issues, see
-            <xref linkend="partitioning-key"/>.
-          </para>
+          <formalpara>
 
+            <title>Default partitioning scheme</title>
+
+            <para>
+              As of MySQL 5.1.6, all Cluster tables are by default
+              partitioned by <literal>KEY</literal> using the table's
+              primary key as the partitioning key. If no primary key is
+              explicitly set for the table, the <quote>hidden</quote>
+              primary key automatically created by the
+              <literal>NDB</literal> storage engine is used instead. For
+              additional discussion of these and related issues, see
+              <xref linkend="partitioning-key"/>.
+            </para>
+
+          </formalpara>
+
           <formalpara>
 
             <title><literal>DROP PARTITION</literal> not
supported</title>

@@ -266,25 +271,38 @@
         </listitem>
 
         <listitem>
-          <indexterm>
-            <primary>MySQL Cluster limitations</primary>
-            <secondary>replication</secondary>
-          </indexterm>
+          <formalpara>
 
-          <para>
-            When using row-based replication with MySQL Cluster, binary
-            logging cannot be disabled. That is, the
-            <literal>NDB</literal> storage engine ignores the value of
-            <literal>SQL_LOG_BIN</literal>. (Bug #16680)
-          </para>
+            <title>Row-based replication</title>
+
+            <indexterm>
+              <primary>MySQL Cluster limitations</primary>
+              <secondary>replication</secondary>
+            </indexterm>
+
+            <para>
+              When using row-based replication with MySQL Cluster,
+              binary logging cannot be disabled. That is, the
+              <literal>NDB</literal> storage engine ignores the value of
+              <literal>SQL_LOG_BIN</literal>. (Bug #16680)
+            </para>
+
+          </formalpara>
         </listitem>
 
         <listitem>
-          <para>
-            The <literal>auto_increment_increment</literal> and
-            <literal>auto_increment_offset</literal> server system
-            variables are not supported for Cluster replication.
-          </para>
+          <formalpara>
+
+            <title><literal>auto_increment_increment</literal> and
+              <literal>auto_increment_offset</literal></title>
+
+            <para>
+              The <literal>auto_increment_increment</literal> and
+              <literal>auto_increment_offset</literal> server system
+              variables are not supported for Cluster replication.
+            </para>
+
+          </formalpara>
         </listitem>
 
       </itemizedlist>

@@ -439,12 +457,17 @@
                             <literal>MaxNoOfConcurrentOperations</literal>
                             and
                             <literal>MaxNoOfLocalOperations</literal>.
-                            Note that bulk loading, <literal>TRUNCATE
-                            TABLE</literal>, and <literal>ALTER
-                            TABLE</literal> are handled as special cases
-                            by running multiple transactions, and so are
-                            not subject to this limitation.
                           </para>
+
+                          <note>
+                            <para>
+                              Bulk loading, <literal>TRUNCATE
+                              TABLE</literal>, and <literal>ALTER
+                              TABLE</literal> are handled as special
+                              cases by running multiple transactions,
+                              and so are not subject to this limitation.
+                            </para>
+                          </note>
                         </listitem>
 
                         <listitem>

@@ -534,30 +557,36 @@
     </indexterm>
 
     <para>
-      A numbe of limitations exist in MySQL Cluster with regard to the
+      A number of limitations exist in MySQL Cluster with regard to the
       handling of transactions. These include the following:
 
       <itemizedlist>
 
         <listitem>
-          <para>
-            The <literal>NDBCLUSTER</literal> storage engine supports
-            only the <literal>READ COMMITTED</literal> transaction
-            isolation level.
-          </para>
+          <formalpara>
 
-          <important>
+            <title>Transaction isolation level</title>
+
             <para>
-              If a <literal>SELECT</literal> from a Cluster table
-              includes a <literal>BLOB</literal> or
-              <literal>TEXT</literal> column, the <literal>READ
-              COMMITTED</literal> transaction isolation level is
-              converted to a read with read lock. This is done to
-              guarantee consistency, due to the fact that parts of the
-              values stored in columns of these types are actually read
-              from a separate table.
+              The <literal>NDBCLUSTER</literal> storage engine supports
+              only the <literal>READ COMMITTED</literal> transaction
+              isolation level.
+
+              <important>
+                <para>
+                  If a <literal>SELECT</literal> from a Cluster table
+                  includes a <literal>BLOB</literal> or
+                  <literal>TEXT</literal> column, the <literal>READ
+                  COMMITTED</literal> transaction isolation level is
+                  converted to a read with read lock. This is done to
+                  guarantee consistency, due to the fact that parts of
+                  the values stored in columns of these types are
+                  actually read from a separate table.
+                </para>
+              </important>
             </para>
-          </important>
+
+          </formalpara>
         </listitem>
 
         <listitem>

@@ -574,99 +603,103 @@
         </listitem>
 
         <listitem>
-          <para>
-            As noted elsewhere in this chapter, MySQL Cluster does not
-            handle large transactions well; it is better to perform a
-            number of small transactions with a few operations each than
-            to attempt a single large transaction containing a great
-            many operations.
-          </para>
+          <formalpara>
 
-          <indexterm>
-            <primary>MySQL Cluster limitations</primary>
-            <secondary>memory usage and transaction handling</secondary>
-          </indexterm>
+            <title>Transactions and memory usage</title>
 
-          <indexterm>
-            <primary>MySQL Cluster</primary>
-            <secondary>transaction handling</secondary>
-          </indexterm>
+            <indexterm>
+              <primary>MySQL Cluster limitations</primary>
+              <secondary>memory usage and transaction handling</secondary>
+            </indexterm>
 
-          <para>
-            Among other considerations, large transactions require very
-            large amounts of memory. Because of this, the transactional
-            behaviour of a number of MySQL statements is effected as
-            described in the following list:
+            <indexterm>
+              <primary>MySQL Cluster</primary>
+              <secondary>transaction handling</secondary>
+            </indexterm>
 
-            <itemizedlist>
+            <para>
+              As noted elsewhere in this chapter, MySQL Cluster does not
+              handle large transactions well; it is better to perform a
+              number of small transactions with a few operations each
+              than to attempt a single large transaction containing a
+              great many operations. Among other considerations, large
+              transactions require very large amounts of memory. Because
+              of this, the transactional behaviour of a number of MySQL
+              statements is effected as described in the following list:
 
-              <listitem>
-                <para>
-                  <literal>TRUNCATE</literal> is not transactional when
-                  used on <literal>NDB</literal> tables. If a
-                  <literal>TRUNCATE</literal> fails to empty the table,
-                  then it must be re-run until it is successful.
-                </para>
-              </listitem>
+              <itemizedlist>
 
-              <listitem>
-                <para>
-                  <literal>DELETE FROM</literal> (even with no
-                  <literal>WHERE</literal> clause)
-                  <emphasis>is</emphasis> transactional. For tables
-                  containing a great many rows, you may find that
-                  performance is improved by using several
-                  <literal>DELETE FROM ... LIMIT ...</literal>
-                  statements to <quote>chunk</quote> the delete
-                  operation. If your objective is to empty the table,
-                  then you may wish to use <literal>TRUNCATE</literal>
-                  instead.
-                </para>
-              </listitem>
+                <listitem>
+                  <para>
+                    <literal>TRUNCATE</literal> is not transactional
+                    when used on <literal>NDB</literal> tables. If a
+                    <literal>TRUNCATE</literal> fails to empty the
+                    table, then it must be re-run until it is
+                    successful.
+                  </para>
+                </listitem>
 
-              <listitem>
-                <formalpara>
+                <listitem>
+                  <para>
+                    <literal>DELETE FROM</literal> (even with no
+                    <literal>WHERE</literal> clause)
+                    <emphasis>is</emphasis> transactional. For tables
+                    containing a great many rows, you may find that
+                    performance is improved by using several
+                    <literal>DELETE FROM ... LIMIT ...</literal>
+                    statements to <quote>chunk</quote> the delete
+                    operation. If your objective is to empty the table,
+                    then you may wish to use <literal>TRUNCATE</literal>
+                    instead.
+                  </para>
+                </listitem>
 
-                  <title><literal>LOAD DATA</literal>
statements</title>
+                <listitem>
+                  <formalpara>
 
-                  <para>
-                    <literal>LOAD DATA INFILE</literal> is not
-                    transactional when used on <literal>NDB</literal>
-                    tables.
+                    <title><literal>LOAD DATA</literal>
statements</title>
 
-                    <important>
-                      <para>
-                        When executing a <literal>LOAD DATA
-                        INFILE</literal> statement, the
-                        <literal>NDB</literal> engine can and does
-                        commit at will.
-                      </para>
-                    </important>
+                    <para>
+                      <literal>LOAD DATA INFILE</literal> is not
+                      transactional when used on <literal>NDB</literal>
+                      tables.
 
-                    <literal>LOAD DATA FROM MASTER</literal> is not
-                    supported in MySQL Cluster.
-                  </para>
+                      <important>
+                        <para>
+                          When executing a <literal>LOAD DATA
+                          INFILE</literal> statement, the
+                          <literal>NDB</literal> engine can and does
+                          commit at will.
+                        </para>
+                      </important>
 
-                </formalpara>
-              </listitem>
+                      <literal>LOAD DATA FROM MASTER</literal> is not
+                      supported in MySQL Cluster.
+                    </para>
 
-              <listitem>
-                <formalpara>
+                  </formalpara>
+                </listitem>
 
-                  <title><literal>ALTER TABLE</literal> and
transactions</title>
+                <listitem>
+                  <formalpara>
 
-                  <para>
-                    When copying an <literal>NDB</literal> table as part
-                    of an <literal>ALTER TABLE</literal>, the creation
-                    of the copy is non-transactional. (In any case, this
-                    operation is rolled back when the copy is deleted.)
-                  </para>
+                    <title><literal>ALTER TABLE</literal> and
transactions</title>
 
-                </formalpara>
-              </listitem>
+                    <para>
+                      When copying an <literal>NDB</literal> table as
+                      part of an <literal>ALTER TABLE</literal>, the
+                      creation of the copy is non-transactional. (In any
+                      case, this operation is rolled back when the copy
+                      is deleted.)
+                    </para>
 
-            </itemizedlist>
-          </para>
+                  </formalpara>
+                </listitem>
+
+              </itemizedlist>
+            </para>
+
+          </formalpara>
         </listitem>
 
       </itemizedlist>

@@ -678,6 +711,11 @@
 
     <title>Error Handling</title>
 
+    <indexterm>
+      <primary>MySQL Cluster limitations</primary>
+      <secondary>error handling and reporting</secondary>
+    </indexterm>
+
     <para>
       Starting, stopping, or restarting a node may give rise to
       temporary errors causing some transactions to fail. These include

@@ -686,20 +724,32 @@
       <itemizedlist>
 
         <listitem>
-          <para>
-            When first starting a node, it is possible that you may see
-            Error 1204 <errortext>Temporary failure, distribution
-            changed</errortext> and similar temporary errors.
-          </para>
+          <formalpara>
+
+            <title>Temporary errors</title>
+
+            <para>
+              When first starting a node, it is possible that you may
+              see Error 1204 <errortext>Temporary failure, distribution
+              changed</errortext> and similar temporary errors.
+            </para>
+
+          </formalpara>
         </listitem>
 
         <listitem>
-          <para>
-            The stopping or failure of any data node can result in a
-            number of different node failure errors. (However, there
-            should be no aborted transactions when performing a planned
-            shutdown of the cluster.)
-          </para>
+          <formalpara>
+
+            <title>Errors due to node failure</title>
+
+            <para>
+              The stopping or failure of any data node can result in a
+              number of different node failure errors. (However, there
+              should be no aborted transactions when performing a
+              planned shutdown of the cluster.)
+            </para>
+
+          </formalpara>
         </listitem>
 
       </itemizedlist>