From: stefan
Date: December 20 2005 3:55pm
Subject: svn commit - mysqldoc@docsrva: r602 - in trunk: refman-4.1 refman-5.0 refman-5.1
List-Archive: http://lists.mysql.com/commits/285
Message-Id: <200512201555.jBKFtIgq004744@docsrva.mysql.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Author: shinz
Date: 2005-12-20 16:55:16 +0100 (Tue, 20 Dec 2005)
New Revision: 602

Log:
Removal of RBR in 4.1 manual (forgot to press CTRL+S in editor)

Modified:
   trunk/refman-4.1/replication.xml
   trunk/refman-5.0/replication.xml
   trunk/refman-5.1/replication.xml

Modified: trunk/refman-4.1/replication.xml
===================================================================
--- trunk/refman-4.1/replication.xml	2005-12-20 14:42:37 UTC (rev 601)
+++ trunk/refman-4.1/replication.xml	2005-12-20 15:55:16 UTC (rev 602)
@@ -1514,16 +1514,6 @@
       and the version to which you are upgrading.
     </para>
 
-<!-- Remove the comment when we have RBR in place.
-    <para>
-      Note that downgrading a replication setup to a previous version
-      cannot be done once you've switched from statement-based to
-      row-based replication, and after the first row-based statement
-      has been written to the binlog. See 
-      <xref linkend="replication-row-based"/>.
-    </para>
--->
-
     <section id="replication-upgrade-4-0">
 
       <title>&title-replication-upgrade-4-0;</title>
@@ -4155,258 +4145,8 @@
       create your own monitoring tools.
     </para>
 
-<!-- Remove the comment when we have RBR in place.
-    <para>
-      <emphasis role="bold">Q</emphasis>:
-      How do I tell which format I'm currently running (row-based or 
-      statement-based)?
-    </para>
-    <para>
-      <emphasis role="bold">A</emphasis>:
-      By issuing this statement:
-    </para>
-<programlisting>
-mysql&gt; <userinput>SHOW VARIABLES LIKE "%binlog_format%";</userinput>
-</programlisting>
-
-    <para>
-      <emphasis role="bold">Q</emphasis>:
-      How do I tell the slave to use row-based replication?
-    </para>
-    <para>
-      <emphasis role="bold">A</emphasis>:
-      The slave automatically knows which format it should use.
-    </para>
--->
-
   </section>
 
-<!-- Remove comment when we have RBR in place
-  <section id="replication-sbr-rbr">
-    <title>&title-replication-sbr-rbr;</title>
-
-    <para>
-      Advantages of statement-based replication are:
-      <itemizedlist>
-       <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>
-         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></listitem>
-       <listitem><para>
-         Log files don't contain statements that were rolled back 
-         (when using only transactional tables).
-       </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>
-         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>
-         One can use different storage engines for tables on master and 
-         slave.
-         See <xref linkend="storage-engines"/>.
-       </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>
-       <listitem><para>
-         Circular replication (especially with incremental updates) can 
-         be done without conflicts. With row level replication, this is 
-         impossible to do in some cases.
-       </para></listitem>
-      </itemizedlist>
-    </para>
-
-    <para>
-      Disadvantages of statement-based replication are:
-      <itemizedlist>
-       <listitem><para>
-         Not all update statements can be replicated.
-       </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:
-         <itemizedlist>
-          <listitem><para>
-            <literal>LOAD_FILE()</literal>
-          </para></listitem>
-          <listitem><para>
-            <literal>UUID()</literal>
-          </para></listitem>
-          <listitem><para>
-            <literal>USER()</literal>
-          </para></listitem>
-          <listitem><para>
-            <literal>FOUND_ROWS()</literal>
-          </para></listitem>
-          All other functions are replicated correctly 
-          (including <literal>RAND()</literal>, 
-          <literal>NOW()</literal>, 
-          <literal>LOAD DATA INFILE</literal>, an so forth).
-         </itemizedlist>
-       </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>
-         For InnoDB: 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>
-         <literal>INSERT</literal> statements that use only constants 
-         are slightly slower to apply (probably barely measurable).
-       </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 must be replicated to the slave.
-       </para></listitem>
-       <listitem><para>
-         Deterministic UDFs (user-defined functions) must be applied on 
-         the slaves.
-       </para></listitem>
-       <listitem><para>
-         You can only use one thread to apply data on the slave 
-         (slow with many disks, CPUs).
-       </para></listitem>
-       <listitem><para>
-         When getting something wrong on the slave, the difference 
-         between master and slave will grow with time.
-       </para></listitem>
-      </itemizedlist>
-    </para>
-
-    <para>
-      Advantages of row-level replication are:
-      <itemizedlist>
-       <listitem><para>
-         Everything can be replicated; safest form of replication.
-       </para></listitem>
-       <listitem><para>
-         Same technology as most other database management systems 
-         (easier to explain).
-       </para></listitem>
-       <listitem><para>
-         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:
-         <itemizedlist>
-          <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>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>
-       <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>
-      </itemizedlist>
-    </para>
-
-    <para>
-     Disadvantages of row-level replication are:
-     <itemizedlist>
-      <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>
-      <listitem><para>
-        Binary log will contain data for large statements that were 
-        rolled back.
-      </para></listitem>
-      <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.)
-      </para></listitem>
-      <listitem><para>
-        Deterministic UDFs that generate big <literal>BLOB</literal>s 
-        will be notably slower to replicate.
-      </para></listitem>
-      <listitem><para>
-        Interlaced updates (will be used for updates/deletes that change a lot of rows) will require more resources to apply.
-      </para></listitem>
-      <listitem><para>
-        Tables have to be (almost) identical on master and slave.
-      </para></listitem>
-      <listitem><para>
-        It can be much slower to apply changes to tables without a 
-        primary key.
-      </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>
-     </itemizedlist>
-    </para>
--->
-
   <section id="replication-problems">
 
     <title>&title-replication-problems;</title>

Modified: trunk/refman-5.0/replication.xml
===================================================================
--- trunk/refman-5.0/replication.xml	2005-12-20 14:42:37 UTC (rev 601)
+++ trunk/refman-5.0/replication.xml	2005-12-20 15:55:16 UTC (rev 602)
@@ -91,38 +91,7 @@
       updates that they make to tables on the slave.
     </para>
 
-<!-- Remove the previous paragraph and replace it with the following
-         one when we have RBR in place:
     <para>
-      Note that when you are using replication, all updates to the
-      tables that are replicated should be performed on the master
-      server. Otherwise, you must always be careful to avoid conflicts
-      between updates that users make to tables on the master and
-      updates that they make to tables on the slave.
-      When performing updates on the slaves's side you should also keep
-      in mind that these might work with statement-based replication,
-      but not with 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:
-      <programlisting>
-        slave> INSERT INTO tbl VALUES (1);
-        master> DELETE FROM tbl;
-</programlisting>
-      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
-      master and slave as soon as the slave catches up with the master,
-      because the slave simply echoes the master's
-      <literal>DELETE</literal> statement.
-      With row-based replication, however, the master will write to its
-      binlog the rows that were deleted in the master's table, and
-      because it doesn't know about the slave's operations, this will
-      <emphasis>not</emphasis> include the record inserted on the slave.
-      As a consequence, replication will break.
-    </para> 
-    -->
-
-    <para>
       One-way replication has benefits for robustness, speed, and system
       administration:
     </para>
@@ -237,129 +206,6 @@
 
   </section>
 
-<!-- Uncomment when RBR is in place
-     Remember to uncomment the - -binlog-format item in
-     database-administration.xml, too!
-  <section id="replication-row-based">
-   <title>
-     &title-replication-row-based;
-   </title>
-   <para>
-     With MySQL's classic statement-based replication, there may be
-     issues with replicating stored routines or triggers. You can avoid
-     these issues by using MySQL's row-based replication (RBR) instead.
-     For a detailed list of issues, 
-     see <xref linkend="stored-procedure-logging"/>.
-   </para>
-   <para>
-     Note that in MySQL &current-series; RBR is only available in the
-    <literal>-max</literal> builds.
-   </para>
-   <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.
-   </para>
-   <para>
-     Even with row-based replication enabled, MySQL will still default 
-     to using statement-based replication. If you want to use row-based
-     replication instead, you have to start the MySQL server with this 
-     option:
-<programlisting>
-- -binlog-format=row
-</programlisting>
-     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
-     this case.
-    </para>
-    <para>
-     Setting <option>- -binlog-format=row</option> has the same effect
-     as setting the dynamic server system variable
-     <literal>BINLOG_FORMAT</literal> to a value of
-     <literal>ROW</literal>, like this:
-<programlisting>
-mysql> <userinput>SET GLOBAL BINLOG_FORMAT = 'ROW';</userinput>
-</programlisting>
-    Alternatively, you can set it to a value of <literal>2</literal>:
-<programlisting>
-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> 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 server
-     system variable, like this:
-<programlisting>
-mysql> <userinput>SET GLOBAL BINLOG_FORMAT = 'STMT';</userinput>
-</programlisting>
-    Alternatively, you can set it to a value of <literal>1</literal>:
-<programlisting>
-mysql> <userinput>SET GLOBAL BINLOG_FORMAT = 1;</userinput>
-</programlisting>
-    </para>
-    <para>
-     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 would issue:
-<programlisting>
-mysql> <userinput>SET LOCAL BINLOG_FORMAT = 'STMT';</userinput>
-</programlisting>
-    Alternatively, you can set it to a value of <literal>1</literal>:
-<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:
-    <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>
-       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>
-    <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:
-      <itemizedlist>
-       <listitem><para>
-        <literal>ANALYZE</literal>
-       </para></listitem>
-       <listitem><para>
-        <literal>REPAIR</literal>
-       </para></listitem>
-       <listitem><para>
-        <literal>OPTIMIZE</literal>
-       </para></listitem>
-      </itemizedlist>
-   </para>
-   <para>
-     There is another option you can use with RBR: 
-     <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
-     value will be 1024.
-   </para>
-  </section>
--->
-
   <section id="replication-implementation-details">
 
     <title>&title-replication-implementation-details;</title>
@@ -1644,16 +1490,6 @@
         the downgrade.
       </para>
 
-<!-- Remove the comment when we have RBR in place.
-      <para>
-        Note that downgrading a replication setup to a previous version
-        cannot be done once you've switched from statement-based to
-        row-based replication, and after the first row-based statement
-        has been written to the binlog. See 
-        <xref linkend="replication-row-based"/>.
-      </para>
--->
-
     </section>
 
   </section>
@@ -1714,19 +1550,6 @@
       described in <xref linkend="stored-procedure-logging"/>.
     </para>
 
-<!-- Remove the previous paragraph and replace it with the following
-     one when we have RBR in place:
-    <para>
-      With MySQL's classic statement-based replication, there may be
-      issues with replicating stored routines or triggers. You can avoid
-      these issues by using MySQL's row-based replication (RBR) instead.
-      For a detailed list of issues,
-      see <xref linkend="stored-procedure-logging"/>.
-      For a description of row-based replication, see
-      <xref linkend="replication-row-based"/>.
-    </para>
--->
-
     <itemizedlist>
 
       <listitem>
@@ -4186,232 +4009,6 @@
 
   </section>
 
-<!-- Remove comment when we have RBR in place
-  <section id="replication-sbr-rbr">
-    <title>&title-replication-sbr-rbr;</title>
-
-    <para>
-      Advantages of statement-based replication are:
-      <itemizedlist>
-       <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>
-         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></listitem>
-       <listitem><para>
-         Log files don't contain statements that were rolled back 
-         (when using only transactional tables).
-       </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>
-         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>
-         One can use different storage engines for tables on master and 
-         slave.
-         See <xref linkend="storage-engines"/>.
-       </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>
-       <listitem><para>
-         Circular replication (especially with incremental updates) can 
-         be done without conflicts. With row level replication, this is 
-         impossible to do in some cases.
-       </para></listitem>
-      </itemizedlist>
-    </para>
-
-    <para>
-      Disadvantages of statement-based replication are:
-      <itemizedlist>
-       <listitem><para>
-         Not all update statements can be replicated.
-       </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:
-         <itemizedlist>
-          <listitem><para>
-            <literal>LOAD_FILE()</literal>
-          </para></listitem>
-          <listitem><para>
-            <literal>UUID()</literal>
-          </para></listitem>
-          <listitem><para>
-            <literal>USER()</literal>
-          </para></listitem>
-          <listitem><para>
-            <literal>FOUND_ROWS()</literal>
-          </para></listitem>
-          All other functions are replicated correctly 
-          (including <literal>RAND()</literal>, 
-          <literal>NOW()</literal>, 
-          <literal>LOAD DATA INFILE</literal>, an so forth).
-         </itemizedlist>
-       </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>
-         For InnoDB: 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>
-         <literal>INSERT</literal> statements that use only constants 
-         are slightly slower to apply (probably barely measurable).
-       </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 must be replicated to the slave.
-       </para></listitem>
-       <listitem><para>
-         Deterministic UDFs (user-defined functions) must be applied on 
-         the slaves.
-       </para></listitem>
-       <listitem><para>
-         You can only use one thread to apply data on the slave 
-         (slow with many disks, CPUs).
-       </para></listitem>
-       <listitem><para>
-         When getting something wrong on the slave, the difference 
-         between master and slave will grow with time.
-       </para></listitem>
-      </itemizedlist>
-    </para>
-
-    <para>
-      Advantages of row-level replication are:
-      <itemizedlist>
-       <listitem><para>
-         Everything can be replicated; safest form of replication.
-       </para></listitem>
-       <listitem><para>
-         Same technology as most other database management systems 
-         (easier to explain).
-       </para></listitem>
-       <listitem><para>
-         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:
-         <itemizedlist>
-          <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>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>
-       <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>
-      </itemizedlist>
-    </para>
-
-    <para>
-     Disadvantages of row-level replication are:
-     <itemizedlist>
-      <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>
-      <listitem><para>
-        Binary log will contain data for large statements that were 
-        rolled back.
-      </para></listitem>
-      <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.)
-      </para></listitem>
-      <listitem><para>
-        Deterministic UDFs that generate big <literal>BLOB</literal>s 
-        will be notably slower to replicate.
-      </para></listitem>
-      <listitem><para>
-        Interlaced updates (will be used for updates/deletes that change a lot of rows) will require more resources to apply.
-      </para></listitem>
-      <listitem><para>
-        Tables have to be (almost) identical on master and slave.
-      </para></listitem>
-      <listitem><para>
-        It can be much slower to apply changes to tables without a 
-        primary key.
-      </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>
-     </itemizedlist>
-    </para>
--->
-
   <section id="replication-problems">
 
     <title>&title-replication-problems;</title>
@@ -4661,30 +4258,6 @@
       with as much information as possible.
     </para>
 
-<!-- Uncomment when RBR is in place
-    <para>
-      <emphasis role="bold">Q</emphasis>:
-      How do I tell which format I'm currently running (row-based or 
-      statement-based)?
-    </para>
-    <para>
-      <emphasis role="bold">A</emphasis>:
-      By issuing this statement:
-    </para>
-<programlisting>
-mysql&gt; <userinput>SHOW VARIABLES LIKE "%binlog_format%";</userinput>
-</programlisting>
-
-    <para>
-      <emphasis role="bold">Q</emphasis>:
-      How do I tell the slave to use row-based replication?
-    </para>
-    <para>
-      <emphasis role="bold">A</emphasis>:
-      The slave automatically knows which format it should use.
-    </para>
--->
-
   </section>
 
   <section id="replication-auto-increment">

Modified: trunk/refman-5.1/replication.xml
===================================================================
--- trunk/refman-5.1/replication.xml	2005-12-20 14:42:37 UTC (rev 601)
+++ trunk/refman-5.1/replication.xml	2005-12-20 15:55:16 UTC (rev 602)
@@ -92,7 +92,7 @@
     </para>
 
 <!-- Remove the previous paragraph and replace it with the following
-         one when we have RBR in place:
+     one when we have RBR in place:
     <para>
       Note that when you are using replication, all updates to the
       tables that are replicated should be performed on the master
@@ -104,9 +104,9 @@
       but not with 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:
-      <programlisting>
-        slave> INSERT INTO tbl VALUES (1);
-        master> DELETE FROM tbl;
+<programlisting>
+slave> INSERT INTO tbl VALUES (1);
+master> DELETE FROM tbl;
 </programlisting>
       The master doesn't know about the <literal>INSERT</literal>
       operation on the slave server, but with statement-based
@@ -1640,8 +1640,8 @@
         the downgrade.
       </para>
 
-<!-- Remove the comment when we have RBR in place.
-      <para>
+<!-- Uncomment when RBR is in place
+        <para>
         Note that downgrading a replication setup to a previous version
         cannot be done once you've switched from statement-based to
         row-based replication, and after the first row-based statement
@@ -4179,8 +4179,8 @@
 
   </section>
 
-<!-- Remove comment when we have RBR in place
-  <section id="replication-sbr-rbr">
+<!-- Uncomment when RBR is in place
+    <section id="replication-sbr-rbr">
     <title>&title-replication-sbr-rbr;</title>
 
     <para>