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

[stefan]

Author: shinz
Date: 2006-02-16 18:18:53 +0100 (Thu, 16 Feb 2006)
New Revision: 1351

Log:
Add an RBR disadvantage related to bulk inserts (Dean Ellis)

Modified:
   trunk/refman-5.1/replication.xml

Modified: trunk/refman-5.1/replication.xml
===================================================================
--- trunk/refman-5.1/replication.xml	2006-02-16 16:31:21 UTC (rev 1350)
+++ trunk/refman-5.1/replication.xml	2006-02-16 17:18:53 UTC (rev 1351)
@@ -251,6 +251,11 @@
       to its binary log that indicate how individual table rows are
       effected.
     </para>
+    
+    <para>
+      For a comparison that shows the advantages and disadvantages of SBR and
+      RBR, see <xref linkend="replication-sbr-rbr"/>.
+    </para>
 
     <para>
       With MySQL's classic statement-based replication, there may be
@@ -4573,7 +4578,7 @@
       the format most appropriate for your situation.
     </para>
 
-    <para>
+    <para role="bold">
       Advantages of statement-based replication:
     </para>
 
@@ -4621,7 +4626,7 @@
 
     </itemizedlist>
 
-    <para>
+    <para role="bold">
       Disadvantages of statement-based replication:
     </para>
 
@@ -4757,7 +4762,7 @@
 
     </itemizedlist>
 
-    <para>
+    <para role="bold">
       Advantages of row-based replication:
     </para>
 
@@ -4842,7 +4847,7 @@
 
     </itemizedlist>
 
-    <para>
+    <para role="bold">
       Disadvantages of row-based replication:
     </para>
 
@@ -4895,6 +4900,33 @@
           the master and executed.
         </para>
       </listitem>
+      
+      <listitem>
+        <para>
+          When making a bulk operation that includes non-transactional storage
+          engines, changes are applied as the statement executes. With row-based
+          replication logging, this means that the binary log is written while
+          the statement is running. On the master, this doesn't provide any
+          problems with concurrency, because tables are locked until the bulk
+          operation terminates. On the slave server, however, tables aren't
+          locked while the slave applies changes, because it doesn't know that
+          those changes are part of a bulk operation.
+        </para>
+        <para>
+          In that scenario, if you retrieve data from a table on the master (for
+          example, <literal>SELECT * FROM table_name</literal>), the server
will
+          wait for the bulk operation to complete before executing the
+          <literal>SELECT</literal> statement, because the table is
read-locked.
+          On the slave, the server won't wait (because there is no lock). This
+          means that until the <quote>bulk operation</quote> on the slave has
+          completed you will get different results for the same
+          <literal>SELECT</literal> query on the master and on the slave.
+        </para>
+        <para>
+          This behavior will eventually change, but until it does, you should
+          probably use statement-based replication in a scenario like this.
+        </para>
+      </listitem>
 
     </itemizedlist>