List:Commits« Previous MessageNext Message »
From:stefan Date:January 3 2006 11:34pm
Subject:svn commit - mysqldoc@docsrva: r658 - trunk/refman-5.1
View as plain text  
Author: shinz
Date: 2006-01-04 00:34:28 +0100 (Wed, 04 Jan 2006)
New Revision: 658

Log:
More RBR tweaks based on Mats' feedback, and added --binlog-format option to DBA chapter

Modified:
   trunk/refman-5.1/database-administration.xml
   trunk/refman-5.1/replication.xml

Modified: trunk/refman-5.1/database-administration.xml
===================================================================
--- trunk/refman-5.1/database-administration.xml	2006-01-03 20:43:06 UTC (rev 657)
+++ trunk/refman-5.1/database-administration.xml	2006-01-03 23:34:28 UTC (rev 658)
@@ -5924,6 +5924,16 @@
               <xref linkend="binary-log"/>.
             </para>
           </listitem>
+          
+          <listitem>
+            <para>
+              <literal>binlog_format</literal>
+            </para>
+            <para>
+              The value of the <option>--binlog-format</option> option
+              (either <literal>row</literal> or <literal>statement</literal>).
+            </para>
+          </listitem>
 
           <listitem>
             <para>

Modified: trunk/refman-5.1/replication.xml
===================================================================
--- trunk/refman-5.1/replication.xml	2006-01-03 20:43:06 UTC (rev 657)
+++ trunk/refman-5.1/replication.xml	2006-01-03 23:34:28 UTC (rev 658)
@@ -236,6 +236,12 @@
   <section id="replication-row-based">
 
     <title>&title-replication-row-based;</title>
+    
+    <para>
+      <remark role="todo">
+        [SH] Provide a definition of row-based replication.
+      </remark>
+    </para>
 
     <para>
       With MySQL's classic statement-based replication, there may be
@@ -251,8 +257,9 @@
 
     <para>
       If you're building MySQL from source, it must be compiled with the
-      <option>- -with-row-based-replication</option> switch to
-      <command>configure</command> in order to enable RBR.
+      <option>--with-row-based-replication</option> switch to
+      <command>configure</command> in order to enable row-based 
+      replication.
     </para>
 
     <para>
@@ -262,7 +269,7 @@
       option:
 
 <programlisting>
-- -binlog-format=row
+--binlog-format=row
 </programlisting>
 
       This enables row-based replication
@@ -271,6 +278,7 @@
       this case.
     </para>
 
+<!-- Remove comment when WL#2712 is implemented    
     <para>
       Setting <option>- -binlog-format=row</option> has the same effect
       as setting the dynamic server system variable
@@ -287,13 +295,16 @@
 mysql> <userinput>SET GLOBAL BINLOG_FORMAT = 2;</userinput>
 </programlisting>
     </para>
-
+-->
+    
     <para>
       If you want to switch back to statement-based replication, restart
-      the server without the <literal>- -binlog-format=row</literal>
+      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. Without restarting the server, you can set the dynamic
+      specifiying <option>--binlog-format=statement</option>
+      explicitly.
+<!--  Remove comment when WL#2712 is implemented         
+      Without restarting the server, you can set the dynamic
       server system variable, like this:
 
 <programlisting>
@@ -305,9 +316,11 @@
 <programlisting>
 mysql> <userinput>SET GLOBAL BINLOG_FORMAT = 1;</userinput>
 </programlisting>
+-->
     </para>
 
-    <para>
+      <para>
+<!--  Remove comment when WL#2712 is implemented         
       The dynamic server system variable even allows you to set
       replication logging on a per-connection basis. To enable
       statement-based logging for a thread, rather than server-wide, you
@@ -322,7 +335,7 @@
 <programlisting>
 mysql> <userinput>SET LOCAL BINLOG_FORMAT = 1;</userinput>
 </programlisting>
-
+-->
       Here are two reasons why you would want to set replication logging
       on a per-connection basis:
 
@@ -378,7 +391,7 @@
     </para>
 
     <para>
-      There is another option you can use with RBR:
+      There is another option you can use with row-based replication:
       <option>binlog-row-event-max-size</option>. Rows are stored into
       the binlog in chunks not exceeding this value, which needs to be a
       multiple of 256. If you don't specify that option, the default
@@ -4217,13 +4230,6 @@
 
         <listitem>
           <para>
-            Faster to replicate, especially over slow network
-            installations.
-          </para>
-        </listitem>
-
-        <listitem>
-          <para>
             Log files contain all statements that made any changes,
             which allow them to be used to audit the database.
           </para>
@@ -4239,26 +4245,11 @@
 
         <listitem>
           <para>
-            Less lock time when writing to the binary log. This
-            increases concurrency and allows the master server to
-            execute more statements per second.
-          </para>
-        </listitem>
-
-        <listitem>
-          <para>
             Slave may be a newer version of MySQL with a different row
             structure.
           </para>
         </listitem>
 
-        <listitem>
-          <para>
-            Faster application of logs for update or delete statements
-            on tables without primary keys.
-          </para>
-        </listitem>
-
       </itemizedlist>
     </para>
 
@@ -4269,7 +4260,11 @@
 
         <listitem>
           <para>
-            Not all update statements can be replicated.
+            Not all update 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.
           </para>
         </listitem>
 
@@ -4390,20 +4385,28 @@
         <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.
           </para>
         </listitem>
 
         <listitem>
           <para>
             Same technology as most other database management systems
-            (easier to explain).
+            (easier to explain to database administrators used to other
+            systems).
           </para>
         </listitem>
-
+        
         <listitem>
           <para>
-            Faster to apply data on the slave on tables with primary
-            keys.
+            In many cases, faster to apply data on the slave on tables 
+            with primary keys.
           </para>
         </listitem>
 
@@ -4465,14 +4468,6 @@
 
         <listitem>
           <para>
-            DDL statements (data definition language, like
-            <literal>CREATE TABLE</literal>) are still replicated as
-            statements.
-          </para>
-        </listitem>
-
-        <listitem>
-          <para>
             Bigger log files (much bigger in some cases).
           </para>
         </listitem>
@@ -4486,15 +4481,19 @@
 
         <listitem>
           <para>
-            The potential for concurrency problems exists when writing
-            to the binary log for <literal>UPDATE</literal> or
-            <literal>DELETE</literal> statements that change a lot of
-            rows. (During update of the binary log, all other threads
-            that have finished their statements have to wait for the
-            binary log to be up to date before they can finish.)
+            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

Thread
svn commit - mysqldoc@docsrva: r658 - trunk/refman-5.1stefan4 Jan