svn commit - mysqldoc@docsrva: r4055 - in trunk: refman-4.1 refman-5.0 refman-5.1

[jon]

Author: jstephens
Date: 2006-11-28 04:33:23 +0100 (Tue, 28 Nov 2006)
New Revision: 4055

Log:

Reformat.



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


Modified: trunk/refman-4.1/mysql-cluster.xml
===================================================================
--- trunk/refman-4.1/mysql-cluster.xml	2006-11-28 02:47:15 UTC (rev 4054)
+++ trunk/refman-4.1/mysql-cluster.xml	2006-11-28 03:33:23 UTC (rev 4055)
Changed blocks: 5, Lines Added: 15, Lines Deleted: 14; 3187 bytes

@@ -3205,8 +3205,8 @@
 
                   <listitem>
                     <para>
-                      <literal>filename</literal>: The name of the
-                      log file.
+                      <literal>filename</literal>: The name of the log
+                      file.
                     </para>
                   </listitem>
 

@@ -3543,7 +3543,7 @@
               <literal>NoOfReplicas</literal>; the maximum possible
               value is 4.
             </para>
-            
+
             <para>
               <emphasis role="bold">Important</emphasis>: The value for
               this parameter must divide evenly into the number of data

@@ -7931,14 +7931,14 @@
         Next, we need to determine the number of REDO log files required
         &mdash; that is, fragment log files &mdash; the corresponding
         parameter being <literal>NoOfFragmentLogFiles</literal>. We need
-        to make sure that there are sufficient REDO log files for keeping
-        records for at least 3 local checkpoints. In a production
-        setting, there are always uncertainties &mdash; for instance, we
-        cannot be sure that disks always operate at top speed or with
-        maximum throughput. For this reason, it is best to err on the
-        side of caution, so we double our requirement and calculate a
-        number of fragment log files which should be enough to keep
-        records covering 6 local checkpoints.
+        to make sure that there are sufficient REDO log files for
+        keeping records for at least 3 local checkpoints. In a
+        production setting, there are always uncertainties &mdash; for
+        instance, we cannot be sure that disks always operate at top
+        speed or with maximum throughput. For this reason, it is best to
+        err on the side of caution, so we double our requirement and
+        calculate a number of fragment log files which should be enough
+        to keep records covering 6 local checkpoints.
       </para>
 
       <para>

@@ -8224,14 +8224,15 @@
         The specifics for implementing a particular rolling upgrade
         depend upon the actual changes being made. A more detailed view
         of the process is presented here:
-      </para>      
+      </para>
 
       <mediaobject>
         <imageobject>
           <imagedata fileref="images/rolling-restarts.png" format="PNG"/>
         </imageobject>
         <textobject>
-          <phrase lang="en">MySQL Cluster Rolling Restarts (By Type)</phrase>
+          <phrase lang="en">MySQL Cluster Rolling Restarts (By
+          Type)</phrase>
         </textobject>
       </mediaobject>
 

@@ -10286,7 +10287,7 @@
             identified by the node ID <replaceable>node_id</replaceable>
             is allowed to access the database.
           </para>
-          
+
           <para>
             <emphasis role="bold">Important</emphasis>: Do not attempt
             to have data nodes join the cluster while it is running in


Modified: trunk/refman-5.0/mysql-cluster.xml
===================================================================
--- trunk/refman-5.0/mysql-cluster.xml	2006-11-28 02:47:15 UTC (rev 4054)
+++ trunk/refman-5.0/mysql-cluster.xml	2006-11-28 03:33:23 UTC (rev 4055)
Changed blocks: 6, Lines Added: 17, Lines Deleted: 16; 3705 bytes

@@ -962,7 +962,7 @@
         MySQL 5.1; however, we do not intend to backport this feature to
         MySQL &current-series;.) Naturally, multiple and faster CPUs
         will enhance performance. Memory requirements for other Cluster
-        processes are relatively small. 
+        processes are relatively small.
       </para>
 
       <remark role="todo">

@@ -3183,8 +3183,8 @@
 
                   <listitem>
                     <para>
-                      <literal>filename</literal>: The name of the
-                      log file.
+                      <literal>filename</literal>: The name of the log
+                      file.
                     </para>
                   </listitem>
 

@@ -3521,7 +3521,7 @@
               <literal>NoOfReplicas</literal>; the maximum possible
               value is 4.
             </para>
-            
+
             <para>
               <emphasis role="bold">Important</emphasis>: The value for
               this parameter must divide evenly into the number of data

@@ -7912,14 +7912,14 @@
         Next, we need to determine the number of REDO log files required
         &mdash; that is, fragment log files &mdash; the corresponding
         parameter being <literal>NoOfFragmentLogFiles</literal>. We need
-        to make sure that there are sufficient REDO log files for keeping
-        records for at least 3 local checkpoints. In a production
-        setting, there are always uncertainties &mdash; for instance, we
-        cannot be sure that disks always operate at top speed or with
-        maximum throughput. For this reason, it is best to err on the
-        side of caution, so we double our requirement and calculate a
-        number of fragment log files which should be enough to keep
-        records covering 6 local checkpoints.
+        to make sure that there are sufficient REDO log files for
+        keeping records for at least 3 local checkpoints. In a
+        production setting, there are always uncertainties &mdash; for
+        instance, we cannot be sure that disks always operate at top
+        speed or with maximum throughput. For this reason, it is best to
+        err on the side of caution, so we double our requirement and
+        calculate a number of fragment log files which should be enough
+        to keep records covering 6 local checkpoints.
       </para>
 
       <para>

@@ -8205,17 +8205,18 @@
         The specifics for implementing a particular rolling upgrade
         depend upon the actual changes being made. A more detailed view
         of the process is presented here:
-      </para>      
+      </para>
 
       <mediaobject>
         <imageobject>
           <imagedata fileref="images/rolling-restarts.png" format="PNG"/>
         </imageobject>
         <textobject>
-          <phrase lang="en">MySQL Cluster Rolling Restarts (By Type)</phrase>
+          <phrase lang="en">MySQL Cluster Rolling Restarts (By
+          Type)</phrase>
         </textobject>
       </mediaobject>
-      
+
       <para>
         In the previous diagram, <emphasis role="bold">Stop</emphasis>
         and <emphasis role="bold">Start</emphasis> steps indicate that

@@ -10346,7 +10347,7 @@
             identified by the node ID <replaceable>node_id</replaceable>
             is allowed to access the database.
           </para>
-          
+
           <para>
             <emphasis role="bold">Important</emphasis>: Do not attempt
             to have data nodes join the cluster while it is running in


Modified: trunk/refman-5.1/mysql-cluster.xml
===================================================================
--- trunk/refman-5.1/mysql-cluster.xml	2006-11-28 02:47:15 UTC (rev 4054)
+++ trunk/refman-5.1/mysql-cluster.xml	2006-11-28 03:33:23 UTC (rev 4055)
Changed blocks: 13, Lines Added: 46, Lines Deleted: 45; 9709 bytes

@@ -958,7 +958,7 @@
         commodity hardware and has no unusual requirements in this
         regard, other than for large amounts of RAM, due to the fact
         that all live data storage is done in memory. (Note that this is
-        not the case with Disk Data tables &mdash; see 
+        not the case with Disk Data tables &mdash; see
         <xref linkend="mysql-cluster-disk-data"/>, for more information
         about these.) Naturally, multiple and faster CPUs will enhance
         performance. Memory requirements for other Cluster processes are

@@ -3180,8 +3180,8 @@
 
                   <listitem>
                     <para>
-                      <literal>filename</literal>: The name of the
-                      log file.
+                      <literal>filename</literal>: The name of the log
+                      file.
                     </para>
                   </listitem>
 

@@ -3518,7 +3518,7 @@
               <literal>NoOfReplicas</literal>; the maximum possible
               value is 4.
             </para>
-            
+
             <para>
               <emphasis role="bold">Important</emphasis>: The value for
               this parameter must divide evenly into the number of data

@@ -7942,14 +7942,14 @@
         Next, we need to determine the number of REDO log files required
         &mdash; that is, fragment log files &mdash; the corresponding
         parameter being <literal>NoOfFragmentLogFiles</literal>. We need
-        to make sure that there are sufficient REDO log files for keeping
-        records for at least 3 local checkpoints. In a production
-        setting, there are always uncertainties &mdash; for instance, we
-        cannot be sure that disks always operate at top speed or with
-        maximum throughput. For this reason, it is best to err on the
-        side of caution, so we double our requirement and calculate a
-        number of fragment log files which should be enough to keep
-        records covering 6 local checkpoints.
+        to make sure that there are sufficient REDO log files for
+        keeping records for at least 3 local checkpoints. In a
+        production setting, there are always uncertainties &mdash; for
+        instance, we cannot be sure that disks always operate at top
+        speed or with maximum throughput. For this reason, it is best to
+        err on the side of caution, so we double our requirement and
+        calculate a number of fragment log files which should be enough
+        to keep records covering 6 local checkpoints.
       </para>
 
       <para>

@@ -8235,17 +8235,18 @@
         The specifics for implementing a particular rolling upgrade
         depend upon the actual changes being made. A more detailed view
         of the process is presented here:
-      </para>      
+      </para>
 
       <mediaobject>
         <imageobject>
           <imagedata fileref="images/rolling-restarts.png" format="PNG"/>
         </imageobject>
         <textobject>
-          <phrase lang="en">MySQL Cluster Rolling Restarts (By Type)</phrase>
+          <phrase lang="en">MySQL Cluster Rolling Restarts (By
+          Type)</phrase>
         </textobject>
       </mediaobject>
-      
+
       <para>
         In the previous diagram, <emphasis role="bold">Stop</emphasis>
         and <emphasis role="bold">Start</emphasis> steps indicate that

@@ -10393,7 +10394,7 @@
             identified by the node ID <replaceable>node_id</replaceable>
             is allowed to access the database.
           </para>
-          
+
           <para>
             <emphasis role="bold">Important</emphasis>: Do not attempt
             to have data nodes join the cluster while it is running in

@@ -16179,8 +16180,8 @@
           <para>
             Using <literal>@latest</literal> as the epoch value obtained
             in the previous step, you can obtain the correct starting
-            position <literal>@pos</literal> in the correct binary
-            log file <literal>@file</literal> from the master's
+            position <literal>@pos</literal> in the correct binary log
+            file <literal>@file</literal> from the master's
             <literal>cluster.binlog_index</literal> table using the
             query shown here:
           </para>

@@ -16690,8 +16691,8 @@
 
       <listitem>
         <para>
-          Create a <firstterm>tablespace</firstterm>, and assign the
-          log file group to it, as well as one or more data files.
+          Create a <firstterm>tablespace</firstterm>, and assign the log
+          file group to it, as well as one or more data files.
         </para>
       </listitem>
 

@@ -16719,17 +16720,17 @@
 
         <para>
           We create a log file group named <literal>lg_1</literal> using
-          <literal>CREATE LOGFILE GROUP</literal>. This log file group is
-          to be made up of two <literal>UNDO</literal> log files, which
-          we name <filename>undo_1.dat</filename> and
+          <literal>CREATE LOGFILE GROUP</literal>. This log file group
+          is to be made up of two <literal>UNDO</literal> log files,
+          which we name <filename>undo_1.dat</filename> and
           <filename>undo_2.dat</filename>, whose initial sizes are 16 MB
-          and 12 MB, respectively. (You must specify a log file's initial
-          size when adding it to a log file group.) Optionally, you can
-          also specify a size for the log file group's
+          and 12 MB, respectively. (You must specify a log file's
+          initial size when adding it to a log file group.) Optionally,
+          you can also specify a size for the log file group's
           <literal>UNDO</literal> buffer, or allow it to assume the
           default value of 8 MB. In this example, we set the UNDO
-          buffer's size at 2 MB. A log file group must be created with an
-          <literal>UNDO</literal> log file; so we add
+          buffer's size at 2 MB. A log file group must be created with
+          an <literal>UNDO</literal> log file; so we add
           <filename>undo_1.dat</filename> to
<literal>lg_1</literal> in
           this <literal>CREATE LOGFILE GROUP</literal> statement:
         </para>

@@ -16787,8 +16788,8 @@
 
           <listitem>
             <para>
-              When you add an <literal>UNDO</literal> log file to a
-              log file group using <literal>ADD UNDOFILE
+              When you add an <literal>UNDO</literal> log file to a log
+              file group using <literal>ADD UNDOFILE
               '<replaceable>filename</replaceable>'</literal>, a file
               with the the name <replaceable>filename</replaceable> is
               created in the

@@ -16829,21 +16830,21 @@
         <para>
           Now we can create a tablespace. A tablespace contains files to
           be used by MySQL Cluster Disk Data tables for storing their
-          data. A tablespace is also associated with a particular
-          log file group. When creating a new tablespace, you must
-          specify the log file group which it is to use for
-          <literal>UNDO</literal> logging; you must also specify a
-          data file. You can add more data files to the tablespace after
-          it the tablespace is created; it is also possible to drop
-          data files from a tablespace (an example of dropping data files
-          is provided later in this section).
+          data. A tablespace is also associated with a particular log
+          file group. When creating a new tablespace, you must specify
+          the log file group which it is to use for
+          <literal>UNDO</literal> logging; you must also specify a data
+          file. You can add more data files to the tablespace after it
+          the tablespace is created; it is also possible to drop data
+          files from a tablespace (an example of dropping data files is
+          provided later in this section).
         </para>
 
         <para>
           Assume that we wish to create a tablespace named
           <literal>ts_1</literal> which uses
<literal>lg_1</literal> as
-          its log file group. This tablespace is to contain two data files
-          named <filename>data_1.dat</filename> and
+          its log file group. This tablespace is to contain two data
+          files named <filename>data_1.dat</filename> and
           <filename>data_2.dat</filename>, whose initial sizes are 32 MB
           and 48 MB, respectively. We can do this using two SQL
           statements: <literal>CREATE TABLESPACE</literal>, to create

@@ -17104,8 +17105,8 @@
           This determines the amount of memory that is used for log
           buffers, disk operations (such as page requests and wait
           queues), and metadata for tablespaces, log file groups,
-          <literal>UNDO</literal> files, and data files. It can be set in
-          the <literal>[NDBD]</literal> or <literal>[NDBD
+          <literal>UNDO</literal> files, and data files. It can be set
+          in the <literal>[NDBD]</literal> or <literal>[NDBD
           DEFAULT]</literal> section of the
           <filename>config.ini</filename> configuration file, and is
           measured in bytes.

@@ -17113,10 +17114,10 @@
       </listitem>
 
     </itemizedlist>
-    
+
     <para>
-      <emphasis role="bold">Note</emphasis>: The <literal>OPTIMIZE 
-        TABLE</literal> statement does not have any effect on Disk Data
+      <emphasis role="bold">Note</emphasis>: The <literal>OPTIMIZE
+      TABLE</literal> statement does not have any effect on Disk Data
       tables.
     </para>