List:Commits« Previous MessageNext Message »
From:paul Date:January 9 2006 12:10am
Subject:svn commit - mysqldoc@docsrva: r726 - in trunk: . refman-4.1 refman-5.1 refman-common
View as plain text  
Author: paul
Date: 2006-01-09 01:10:14 +0100 (Mon, 09 Jan 2006)
New Revision: 726

Log:
 r5963@frost:  paul | 2006-01-08 17:44:09 -0600
 De-cruft.


Modified:
   trunk/
   trunk/refman-4.1/introduction.xml
   trunk/refman-5.1/introduction.xml
   trunk/refman-5.1/replication.xml
   trunk/refman-common/maxdb.en.xml


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

Modified: trunk/refman-4.1/introduction.xml
===================================================================
--- trunk/refman-4.1/introduction.xml	2006-01-09 00:09:57 UTC (rev 725)
+++ trunk/refman-4.1/introduction.xml	2006-01-09 00:10:14 UTC (rev 726)
@@ -787,59 +787,60 @@
                 <para>
                   Support for a number of additional storage engines was
                   implemented in the MySQL 4.1 release series:
+                </para>
 
-                  <itemizedlist>
+                <itemizedlist>
 
-                    <listitem>
-                      <para>
-                        The <literal>EXAMPLE</literal> storage engine is
-                        a <quote>stub</quote> engine that serves as an
-                        example in the MySQL source code for writing new
-                        storage engines, and is primarily of interest to
-                        developers. See
-                        <xref linkend="example-storage-engine"/>.
-                      </para>
-                    </listitem>
+                  <listitem>
+                    <para>
+                      The <literal>EXAMPLE</literal> storage engine is a
+                      <quote>stub</quote> engine that serves as an
+                      example in the MySQL source code for writing new
+                      storage engines, and is primarily of interest to
+                      developers. See
+                      <xref linkend="example-storage-engine"/>.
+                    </para>
+                  </listitem>
 
-                    <listitem>
-                      <para>
-                        <literal>NDB Cluster</literal> is the storage
-                        engine used by MySQL Cluster to implement tables
-                        that are partitioned over many computers. See
-                        <xref linkend="ndbcluster"/>.
-                      </para>
-                    </listitem>
+                  <listitem>
+                    <para>
+                      <literal>NDB Cluster</literal> is the storage
+                      engine used by MySQL Cluster to implement tables
+                      that are partitioned over many computers. See
+                      <xref linkend="ndbcluster"/>.
+                    </para>
+                  </listitem>
 
-                    <listitem>
-                      <para>
-                        The <literal>ARCHIVE</literal> storage engine is
-                        used for storing large amounts of data without
-                        indexes in a very small footprint. See
-                        <xref linkend="archive-storage-engine"/>.
-                      </para>
-                    </listitem>
+                  <listitem>
+                    <para>
+                      The <literal>ARCHIVE</literal> storage engine is
+                      used for storing large amounts of data without
+                      indexes in a very small footprint. See
+                      <xref linkend="archive-storage-engine"/>.
+                    </para>
+                  </listitem>
 
-                    <listitem>
-                      <para>
-                        The <literal>CSV</literal> storage engine stores
-                        data in text files using comma-separated-values
-                        format. See
-                        <xref linkend="csv-storage-engine"/>.
-                      </para>
-                    </listitem>
+                  <listitem>
+                    <para>
+                      The <literal>CSV</literal> storage engine stores
+                      data in text files using comma-separated-values
+                      format. See <xref linkend="csv-storage-engine"/>.
+                    </para>
+                  </listitem>
 
-                    <listitem>
-                      <para>
-                        The <literal>BLACKHOLE</literal> storage engine
-                        accepts but does not store data, and always
-                        returns an empty result set. It is for use
-                        primarily in replication. See
-                        <xref linkend="blackhole-storage-engine"/>.
-                      </para>
-                    </listitem>
+                  <listitem>
+                    <para>
+                      The <literal>BLACKHOLE</literal> storage engine
+                      accepts but does not store data, and always
+                      returns an empty result set. It is for use
+                      primarily in replication. See
+                      <xref linkend="blackhole-storage-engine"/>.
+                    </para>
+                  </listitem>
 
-                  </itemizedlist>
+                </itemizedlist>
 
+                <para>
                   <emphasis role="bold">Note</emphasis>: These engine
                   were implemented at different points in the
                   development of MySQL 4.1. Please see the indicated

Modified: trunk/refman-5.1/introduction.xml
===================================================================
--- trunk/refman-5.1/introduction.xml	2006-01-09 00:09:57 UTC (rev 725)
+++ trunk/refman-5.1/introduction.xml	2006-01-09 00:10:14 UTC (rev 726)
@@ -419,39 +419,39 @@
           <para>
             <emphasis role="bold">The Instance Manager (IM)</emphasis>
             now has some additional functionality:
+          </para>
 
-            <itemizedlist>
+          <itemizedlist>
 
-              <listitem>
-                <para>
-                  <literal>SHOW <replaceable>instance_name</replaceable>
-                  LOG FILES</literal> provides a listing of all log
-                  files used by the instance. (Author: Petr Chardin)
-                </para>
-              </listitem>
+            <listitem>
+              <para>
+                <literal>SHOW <replaceable>instance_name</replaceable>
+                LOG FILES</literal> provides a listing of all log files
+                used by the instance. (Author: Petr Chardin)
+              </para>
+            </listitem>
 
-              <listitem>
-                <para>
-                  <literal>SHOW <replaceable>instance_name</replaceable>
-                  LOG {ERROR | SLOW | GENERAL}
-                  <replaceable>size</replaceable></literal> retrieves a
-                  part of the specified log file. (Author: Petr Chardin)
-                </para>
-              </listitem>
+            <listitem>
+              <para>
+                <literal>SHOW <replaceable>instance_name</replaceable>
+                LOG {ERROR | SLOW | GENERAL}
+                <replaceable>size</replaceable></literal> retrieves a
+                part of the specified log file. (Author: Petr Chardin)
+              </para>
+            </listitem>
 
-              <listitem>
-                <para>
-                  <literal>SET
-                  <replaceable>instance_name</replaceable>.<replaceable>option_name</replaceable>=<replaceable>option_value</replaceable></literal>
-                  sets an option to the specified value and writes it to
-                  the config file See
-                  <xref linkend="instance-manager"/>, for more details
-                  on these new commands. (Author: Petr Chardin)
-                </para>
-              </listitem>
+            <listitem>
+              <para>
+                <literal>SET
+                <replaceable>instance_name</replaceable>.<replaceable>option_name</replaceable>=<replaceable>option_value</replaceable></literal>
+                sets an option to the specified value and writes it to
+                the config file See <xref linkend="instance-manager"/>,
+                for more details on these new commands. (Author: Petr
+                Chardin)
+              </para>
+            </listitem>
 
-            </itemizedlist>
-          </para>
+          </itemizedlist>
         </listitem>
 
       </itemizedlist>

Modified: trunk/refman-5.1/replication.xml
===================================================================
--- trunk/refman-5.1/replication.xml	2006-01-09 00:09:57 UTC (rev 725)
+++ trunk/refman-5.1/replication.xml	2006-01-09 00:10:14 UTC (rev 726)
@@ -94,12 +94,14 @@
       row-based replication. Consider the following scenario, where a
       record is inserted on the slave, followed by a statement on the
       master's side that should empty the table:
+    </para>
 
 <programlisting>
 slave> INSERT INTO tbl VALUES (1);
 master> DELETE FROM tbl;
 </programlisting>
 
+    <para>
       The master doesn't know about the <literal>INSERT</literal>
       operation on the slave server, but with statement-based
       replication, <literal>tbl</literal> will still be empty on both
@@ -267,11 +269,13 @@
       to using statement-based replication. If you want to use row-based
       replication instead, you have to start the MySQL server with this
       option:
+    </para>
 
 <programlisting>
 --binlog-format=row
 </programlisting>
 
+    <para>
       This enables row-based replication
       <emphasis>server-wide</emphasis>, and automatically turns on
       <option>innodb_locks_unsafe_for_binlog</option> as it is safe in
@@ -284,17 +288,19 @@
       as setting the dynamic server system variable
       <literal>BINLOG_FORMAT</literal> to a value of
       <literal>ROW</literal>, like this:
+    </para>
 
 <programlisting>
 mysql> <userinput>SET GLOBAL BINLOG_FORMAT = 'ROW';</userinput>
 </programlisting>
 
+    <para>
       Alternatively, you can set it to a value of <literal>2</literal>:
+    </para>
 
 <programlisting>
 mysql> <userinput>SET GLOBAL BINLOG_FORMAT = 2;</userinput>
 </programlisting>
-    </para>
 -->
 
     <para>
@@ -302,6 +308,7 @@
       the server without the <literal>--binlog-format=row</literal>
       option (statement-based replication is the default) or by
       specifiying <option>--binlog-format=statement</option> explicitly.
+    </para>
 
 <!--  Remove comment when WL#2712 is implemented         
       Without restarting the server, you can set the dynamic
@@ -311,13 +318,14 @@
 mysql> <userinput>SET GLOBAL BINLOG_FORMAT = 'STMT';</userinput>
 </programlisting>
 
+    <para>
       Alternatively, you can set it to a value of <literal>1</literal>:
+    </para>
 
 <programlisting>
 mysql> <userinput>SET GLOBAL BINLOG_FORMAT = 1;</userinput>
 </programlisting>
 -->
-    </para>
 
     <para>
 <!--  Remove comment when WL#2712 is implemented         
@@ -339,57 +347,57 @@
 
       Here are two reasons why you would want to set replication logging
       on a per-connection basis:
+    </para>
 
-      <itemizedlist>
+    <itemizedlist>
 
-        <listitem>
-          <para>
-            A thread that does a lot of small changes to the database
-            might want to use row-based logging, while a thread that
-            does a lot of heavy-duty searching might want to use
-            statement-based logging.
-          </para>
-        </listitem>
+      <listitem>
+        <para>
+          A thread that does a lot of small changes to the database
+          might want to use row-based logging, while a thread that does
+          a lot of heavy-duty searching might want to use
+          statement-based logging.
+        </para>
+      </listitem>
 
-        <listitem>
-          <para>
-            Some statements require a lot of execution on the master,
-            but create a small result set. It might therefore be
-            beneficial to replicated them row-based.
-          </para>
-        </listitem>
+      <listitem>
+        <para>
+          Some statements require a lot of execution on the master, but
+          create a small result set. It might therefore be beneficial to
+          replicated them row-based.
+        </para>
+      </listitem>
 
-      </itemizedlist>
-    </para>
+    </itemizedlist>
 
     <para>
       Row-based replication causes <emphasis>most</emphasis> changes to
       be written to the binary log using the row-based format. Some
       changes, however, will still be written into the binary log as
       statements:
+    </para>
 
-      <itemizedlist>
+    <itemizedlist>
 
-        <listitem>
-          <para>
-            <literal>ANALYZE</literal>
-          </para>
-        </listitem>
+      <listitem>
+        <para>
+          <literal>ANALYZE</literal>
+        </para>
+      </listitem>
 
-        <listitem>
-          <para>
-            <literal>REPAIR</literal>
-          </para>
-        </listitem>
+      <listitem>
+        <para>
+          <literal>REPAIR</literal>
+        </para>
+      </listitem>
 
-        <listitem>
-          <para>
-            <literal>OPTIMIZE</literal>
-          </para>
-        </listitem>
+      <listitem>
+        <para>
+          <literal>OPTIMIZE</literal>
+        </para>
+      </listitem>
 
-      </itemizedlist>
-    </para>
+    </itemizedlist>
 
     <para>
       There is another option you can use with row-based replication:
@@ -4228,321 +4236,319 @@
 
     <para>
       Advantages of statement-based replication are:
+    </para>
 
-      <itemizedlist>
+    <itemizedlist>
 
-        <listitem>
-          <para>
-            Proven technology (existed in MySQL since 3.23).
-          </para>
-        </listitem>
+      <listitem>
+        <para>
+          Proven technology (existed in MySQL since 3.23).
+        </para>
+      </listitem>
 
-        <listitem>
-          <para>
-            Smaller log files (when using updates or deletes that
-            affects many rows, much smaller log files). Because log
-            files are smaller, they take up less storage space and are
-            faster to back up.
-          </para>
-        </listitem>
+      <listitem>
+        <para>
+          Smaller log files (when using updates or deletes that affects
+          many rows, much smaller log files). Because log files are
+          smaller, they take up less storage space and are faster to
+          back up.
+        </para>
+      </listitem>
 
-        <listitem>
-          <para>
-            Log files contain all statements that made any changes,
-            which allow them to be used to audit the database.
-          </para>
-        </listitem>
+      <listitem>
+        <para>
+          Log files contain all statements that made any changes, which
+          allow them to be used to audit the database.
+        </para>
+      </listitem>
 
-        <listitem>
-          <para>
-            Log files can be used for point-in-time recovery, not just
-            for replication purposes. See
-            <xref linkend="point-in-time-recovery"/>.
-          </para>
-        </listitem>
+      <listitem>
+        <para>
+          Log files can be used for point-in-time recovery, not just for
+          replication purposes. See
+          <xref linkend="point-in-time-recovery"/>.
+        </para>
+      </listitem>
 
-        <listitem>
-          <para>
-            Slave may be a newer version of MySQL with a different row
-            structure.
-          </para>
-        </listitem>
+      <listitem>
+        <para>
+          Slave may be a newer version of MySQL with a different row
+          structure.
+        </para>
+      </listitem>
 
-      </itemizedlist>
-    </para>
+    </itemizedlist>
 
     <para>
       Disadvantages of statement-based replication are:
+    </para>
 
-      <itemizedlist>
+    <itemizedlist>
 
-        <listitem>
-          <para>
-            Not all <literal>UPDATE</literal> statements can be
-            replicated: Any non-deterministic behavior, for example when
-            using random functions in an SQL statement, is hard to
-            replicate when using statement-based replication. When using
-            a non-deterministic user-defined function (UDF), it is not
-            possible to replicate the result using statement-based
-            replication, while row-based replication will just replicate
-            the value returned by the UDF.
-          </para>
-        </listitem>
+      <listitem>
+        <para>
+          Not all <literal>UPDATE</literal> statements can be
+          replicated: Any non-deterministic behavior, for example when
+          using random functions in an SQL statement, is hard to
+          replicate when using statement-based replication. When using a
+          non-deterministic user-defined function (UDF), it is not
+          possible to replicate the result using statement-based
+          replication, while row-based replication will just replicate
+          the value returned by the UDF.
+        </para>
+      </listitem>
 
-        <listitem>
-          <para>
-            Statements that use a UDF (user defined function) which is
-            non-deterministic (value depends on other things than the
-            given parameters) cannot be replicated properly.
-          </para>
-        </listitem>
+      <listitem>
+        <para>
+          Statements that use a UDF (user defined function) which is
+          non-deterministic (value depends on other things than the
+          given parameters) cannot be replicated properly.
+        </para>
+      </listitem>
 
-        <listitem>
-          <para>
-            Statements that use one of the following functions cannot be
-            replicated properly:
+      <listitem>
+        <para>
+          Statements that use one of the following functions cannot be
+          replicated properly:
+        </para>
 
-            <itemizedlist>
+        <itemizedlist>
 
-              <listitem>
-                <para>
-                  <literal>LOAD_FILE()</literal>
-                </para>
-              </listitem>
+          <listitem>
+            <para>
+              <literal>LOAD_FILE()</literal>
+            </para>
+          </listitem>
 
-              <listitem>
-                <para>
-                  <literal>UUID()</literal>
-                </para>
-              </listitem>
+          <listitem>
+            <para>
+              <literal>UUID()</literal>
+            </para>
+          </listitem>
 
-              <listitem>
-                <para>
-                  <literal>USER()</literal>
-                </para>
-              </listitem>
+          <listitem>
+            <para>
+              <literal>USER()</literal>
+            </para>
+          </listitem>
 
-              <listitem>
-                <para>
-                  <literal>FOUND_ROWS()</literal>
-                </para>
-              </listitem>
+          <listitem>
+            <para>
+              <literal>FOUND_ROWS()</literal>
+            </para>
+          </listitem>
 
-            </itemizedlist>
+        </itemizedlist>
 
-            All other functions are replicated correctly (including
-            <literal>RAND()</literal>, <literal>NOW()</literal>,
-            <literal>LOAD DATA INFILE</literal>, an so forth).
-          </para>
-        </listitem>
+        <para>
+          All other functions are replicated correctly (including
+          <literal>RAND()</literal>, <literal>NOW()</literal>,
+          <literal>LOAD DATA INFILE</literal>, an so forth).
+        </para>
+      </listitem>
 
-        <listitem>
-          <para>
-            <literal>INSERT &hellip; SELECT</literal> requires more
-            row-level locks than with row-level replication.
-          </para>
-        </listitem>
+      <listitem>
+        <para>
+          <literal>INSERT &hellip; SELECT</literal> requires more
+          row-level locks than with row-level replication.
+        </para>
+      </listitem>
 
-        <listitem>
-          <para>
-            <literal>UPDATE</literal> statements that require a table
-            scan (that is don't use indexes in the
-            <literal>WHERE</literal> clause) have to lock more rows than
-            with row-level replication.
-          </para>
-        </listitem>
+      <listitem>
+        <para>
+          <literal>UPDATE</literal> statements that require a table scan
+          (that is don't use indexes in the <literal>WHERE</literal>
+          clause) have to lock more rows than with row-level
+          replication.
+        </para>
+      </listitem>
 
-        <listitem>
-          <para>
-            For <literal>InnoDB</literal>: An <literal>INSERT</literal>
-            statement that uses <literal>auto_increment</literal> will
-            block other non-conflicting <literal>INSERT</literal>
-            statements.
-          </para>
-        </listitem>
+      <listitem>
+        <para>
+          For <literal>InnoDB</literal>: An <literal>INSERT</literal>
+          statement that uses <literal>auto_increment</literal> will
+          block other non-conflicting <literal>INSERT</literal>
+          statements.
+        </para>
+      </listitem>
 
-        <listitem>
-          <para>
-            Slower to apply data on slave for complex queries.
-          </para>
-        </listitem>
+      <listitem>
+        <para>
+          Slower to apply data on slave for complex queries.
+        </para>
+      </listitem>
 
-        <listitem>
-          <para>
-            Stored functions (not stored procedures) will execute with
-            the same <literal>NOW()</literal> value as the calling
-            statement. (This may be regarded both as a bad and a good
-            thing.)
-          </para>
-        </listitem>
+      <listitem>
+        <para>
+          Stored functions (not stored procedures) will execute with the
+          same <literal>NOW()</literal> value as the calling statement.
+          (This may be regarded both as a bad and a good thing.)
+        </para>
+      </listitem>
 
-        <listitem>
-          <para>
-            Deterministic UDFs (user-defined functions) must be applied
-            on the slaves.
-          </para>
-        </listitem>
+      <listitem>
+        <para>
+          Deterministic UDFs (user-defined functions) must be applied on
+          the slaves.
+        </para>
+      </listitem>
 
-        <listitem>
-          <para>
-            When getting something wrong on the slave, the difference
-            between master and slave will grow with time.
-          </para>
-        </listitem>
+      <listitem>
+        <para>
+          When getting something wrong on the slave, the difference
+          between master and slave will grow with time.
+        </para>
+      </listitem>
 
-        <listitem>
-          <para>
-            Tables have to be (almost) identical on master and slave.
-          </para>
-        </listitem>
+      <listitem>
+        <para>
+          Tables have to be (almost) identical on master and slave.
+        </para>
+      </listitem>
 
-      </itemizedlist>
-    </para>
+    </itemizedlist>
 
     <para>
       Advantages of row-level replication are:
+    </para>
 
-      <itemizedlist>
+    <itemizedlist>
 
-        <listitem>
-          <para>
-            Everything can be replicated; safest form of replication.
-            Note that currently, DDL (data definition language)
-            statements such as <literal>CREATE TABLE</literal> are
-            replicated using statement-based replication, while DML
-            (data manipulation language) statements, as well as
-            <literal>GRANT</literal> and <literal>REVOKE</literal>
-            statements, are replicated using row-based-replication. For
-            statements like <literal>CREATE &hellip; SELECT</literal>, a
-            <literal>CREATE</literal> statement is generated from the
-            table definition and replicated statement-based, while the
-            row insertions are replicated row-based.
-          </para>
-        </listitem>
+      <listitem>
+        <para>
+          Everything can be replicated; safest form of replication. Note
+          that currently, DDL (data definition language) statements such
+          as <literal>CREATE TABLE</literal> are replicated using
+          statement-based replication, while DML (data manipulation
+          language) statements, as well as <literal>GRANT</literal> and
+          <literal>REVOKE</literal> statements, are replicated using
+          row-based-replication. For statements like <literal>CREATE
+          &hellip; SELECT</literal>, a <literal>CREATE</literal>
+          statement is generated from the table definition and
+          replicated statement-based, while the row insertions are
+          replicated row-based.
+        </para>
+      </listitem>
 
-        <listitem>
-          <para>
-            Same technology as most other database management systems
-            (easier to explain to database administrators used to other
-            systems).
-          </para>
-        </listitem>
+      <listitem>
+        <para>
+          Same technology as most other database management systems
+          (easier to explain to database administrators used to other
+          systems).
+        </para>
+      </listitem>
 
-        <listitem>
-          <para>
-            In many cases, faster to apply data on the slave on tables
-            with primary keys.
-          </para>
-        </listitem>
+      <listitem>
+        <para>
+          In many cases, faster to apply data on the slave on tables
+          with primary keys.
+        </para>
+      </listitem>
 
-        <listitem>
-          <para>
-            Less locks needed (thus higher concurrency) on the master
-            for:
+      <listitem>
+        <para>
+          Less locks needed (thus higher concurrency) on the master for:
+        </para>
 
-            <itemizedlist>
+        <itemizedlist>
 
-              <listitem>
-                <para>
-                  <literal>INSERT &hellip; SELECT</literal>
-                </para>
-              </listitem>
+          <listitem>
+            <para>
+              <literal>INSERT &hellip; SELECT</literal>
+            </para>
+          </listitem>
 
-              <listitem>
-                <para>
-                  <literal>INSERT</literal> statements with
-                  <literal>auto_increment</literal>
-                </para>
-              </listitem>
+          <listitem>
+            <para>
+              <literal>INSERT</literal> statements with
+              <literal>auto_increment</literal>
+            </para>
+          </listitem>
 
-              <listitem>
-                <para>
-                  <literal>UPDATE</literal> or <literal>DELETE</literal>
-                  statements with <literal>WHERE</literal> clauses that
-                  don't use keys or don't change most of the examined
-                  rows.
-                </para>
-              </listitem>
+          <listitem>
+            <para>
+              <literal>UPDATE</literal> or <literal>DELETE</literal>
+              statements with <literal>WHERE</literal> clauses that
+              don't use keys or don't change most of the examined rows.
+            </para>
+          </listitem>
 
-            </itemizedlist>
-          </para>
-        </listitem>
+        </itemizedlist>
+      </listitem>
 
-        <listitem>
-          <para>
-            Less locks on the slave for any <literal>INSERT</literal>,
-            <literal>UPDATE</literal>, or <literal>DELETE</literal>
-            statement.
-          </para>
-        </listitem>
+      <listitem>
+        <para>
+          Less locks on the slave for any <literal>INSERT</literal>,
+          <literal>UPDATE</literal>, or <literal>DELETE</literal>
+          statement.
+        </para>
+      </listitem>
 
-        <listitem>
-          <para>
-            It's possible to add multiple threads to apply data on the
-            slave in the future (works better on SMP machines).
-          </para>
-        </listitem>
+      <listitem>
+        <para>
+          It's possible to add multiple threads to apply data on the
+          slave in the future (works better on SMP machines).
+        </para>
+      </listitem>
 
-      </itemizedlist>
-    </para>
+    </itemizedlist>
 
     <para>
       Disadvantages of row-level replication are:
+    </para>
 
-      <itemizedlist>
+    <itemizedlist>
 
-        <listitem>
-          <para>
-            Bigger log files (much bigger in some cases).
-          </para>
-        </listitem>
+      <listitem>
+        <para>
+          Bigger log files (much bigger in some cases).
+        </para>
+      </listitem>
 
-        <listitem>
-          <para>
-            Binary log will contain data for large statements that were
-            rolled back.
-          </para>
-        </listitem>
+      <listitem>
+        <para>
+          Binary log will contain data for large statements that were
+          rolled back.
+        </para>
+      </listitem>
 
-        <listitem>
-          <para>
-            When using row-based replication to replicate a statement
-            (for example, an <literal>UPDATE</literal> or
-            <literal>DELETE</literal> statement), each changed row has
-            to be written to the binary log. In contrast, when using
-            statement-based replication only the statement is written to
-            the binary log. If the statement changes a lot of rows,
-            row-based replication may write significantly more data to
-            the binary log. In these cases the binary log will be locked
-            for longer times to write the data, which may cause
-            concurrency problems.
-          </para>
-        </listitem>
+      <listitem>
+        <para>
+          When using row-based replication to replicate a statement (for
+          example, an <literal>UPDATE</literal> or
+          <literal>DELETE</literal> statement), each changed row has to
+          be written to the binary log. In contrast, when using
+          statement-based replication only the statement is written to
+          the binary log. If the statement changes a lot of rows,
+          row-based replication may write significantly more data to the
+          binary log. In these cases the binary log will be locked for
+          longer times to write the data, which may cause concurrency
+          problems.
+        </para>
+      </listitem>
 
-        <listitem>
-          <para>
-            Deterministic UDFs that generate big
-            <literal>BLOB</literal>s will be notably slower to
-            replicate.
-          </para>
-        </listitem>
+      <listitem>
+        <para>
+          Deterministic UDFs that generate big <literal>BLOB</literal>s
+          will be notably slower to replicate.
+        </para>
+      </listitem>
 
-        <listitem>
-          <para>
-            One can't examine the logs to see what statements were
-            executed.
-          </para>
-        </listitem>
+      <listitem>
+        <para>
+          One can't examine the logs to see what statements were
+          executed.
+        </para>
+      </listitem>
 
-        <listitem>
-          <para>
-            One can't see on the slave what statements were received
-            from the master and executed.
-          </para>
-        </listitem>
+      <listitem>
+        <para>
+          One can't see on the slave what statements were received from
+          the master and executed.
+        </para>
+      </listitem>
 
-      </itemizedlist>
-    </para>
+    </itemizedlist>
 
     <section id="replication-problems">
 

Modified: trunk/refman-common/maxdb.en.xml
===================================================================
--- trunk/refman-common/maxdb.en.xml	2006-01-09 00:09:57 UTC (rev 725)
+++ trunk/refman-common/maxdb.en.xml	2006-01-09 00:10:14 UTC (rev 726)
@@ -160,52 +160,51 @@
       meet the needs of installations in OLTP and Data
       Warehouse/OLAP/Decision Support scenarios and offers these
       benefits:
+    </para>
 
-      <itemizedlist>
+    <itemizedlist>
 
-        <listitem>
-          <para>
-            <emphasis role="bold">Easy configuration and
-            administration:</emphasis> GUI-based Installation Manager
-            and Database Manager as single administration tools for DBMS
-            operations
-          </para>
-        </listitem>
+      <listitem>
+        <para>
+          <emphasis role="bold">Easy configuration and
+          administration:</emphasis> GUI-based Installation Manager and
+          Database Manager as single administration tools for DBMS
+          operations
+        </para>
+      </listitem>
 
-        <listitem>
-          <para>
-            <emphasis role="bold">Around-the-clock operation, no planned
-            downtimes, no permanent attendance required:</emphasis>
-            Automatic space management, no need for reorganizations
-          </para>
-        </listitem>
+      <listitem>
+        <para>
+          <emphasis role="bold">Around-the-clock operation, no planned
+          downtimes, no permanent attendance required:</emphasis>
+          Automatic space management, no need for reorganizations
+        </para>
+      </listitem>
 
-        <listitem>
-          <para>
-            <emphasis role="bold">Sophisticated backup and restore
-            capabilities:</emphasis> Online and incremental backups,
-            recovery wizard to guide you through the recovery scenario
-          </para>
-        </listitem>
+      <listitem>
+        <para>
+          <emphasis role="bold">Sophisticated backup and restore
+          capabilities:</emphasis> Online and incremental backups,
+          recovery wizard to guide you through the recovery scenario
+        </para>
+      </listitem>
 
-        <listitem>
-          <para>
-            <emphasis role="bold">Supports large number of users,
-            database sizes in the terabytes, and demanding
-            workloads:</emphasis> Proven reliability, performance, and
-            scalability
-          </para>
-        </listitem>
+      <listitem>
+        <para>
+          <emphasis role="bold">Supports large number of users, database
+          sizes in the terabytes, and demanding workloads:</emphasis>
+          Proven reliability, performance, and scalability
+        </para>
+      </listitem>
 
-        <listitem>
-          <para>
-            <emphasis role="bold">High availability:</emphasis> Cluster
-            support, standby configuration, hot standby configuration
-          </para>
-        </listitem>
+      <listitem>
+        <para>
+          <emphasis role="bold">High availability:</emphasis> Cluster
+          support, standby configuration, hot standby configuration
+        </para>
+      </listitem>
 
-      </itemizedlist>
-    </para>
+    </itemizedlist>
 
   </section>
 

Thread
svn commit - mysqldoc@docsrva: r726 - in trunk: . refman-4.1 refman-5.1 refman-commonpaul9 Jan