bk commit - mysqldoc@docsrva tree (stefan:1.3189)

[stefan]

Below is the list of changes that have just been committed into a local
mysqldoc repository of stefan. When stefan does a push these changes will
be propagated to the main repository and, within 24 hours after the
push, to the public repository.
For information on how to access the public repository
see http://www.mysql.com/doc/I/n/Installing_source_tree.html

ChangeSet
  1.3189 05/08/06 23:22:52 stefan@stripped +3 -0
  replication.xml:
    Sync with refman
    Add note and example demonstrating how replication
    might break with RBR when you have data-changing operations
    on the slave server (a scenario that won't cause problems
    with SBR). Still commented out until we have RBR in place.
    (Thanks, Jeb, for bringing this up!)

  refman-5.1/replication.xml
    1.2 05/08/06 23:22:40 stefan@stripped +31 -0
    Sync with refman

  refman-5.0/replication.xml
    1.2 05/08/06 23:22:37 stefan@stripped +31 -0
    Sync with refman

  refman/replication.xml
    1.12 05/08/06 23:20:34 stefan@stripped +31 -0
    Add note and example demonstrating how replication
    might break with RBR when you have data-changing operations
    on the slave server (a scenario that won't cause problems
    with SBR). Still commented out until we have RBR in place.
    (Thanks, Jeb, for bringing this up!)

# This is a BitKeeper patch.  What follows are the unified diffs for the
# set of deltas contained in the patch.  The rest of the patch, the part
# that BitKeeper cares about, is below these diffs.
# User:	stefan
# Host:	apollon.site
# Root:	/home/stefan/bk/mysqldoc

--- 1.1/refman-5.1/replication.xml	2005-08-05 19:47:02 +02:00
+++ 1.2/refman-5.1/replication.xml	2005-08-06 23:22:40 +02:00
@@ -89,6 +89,37 @@
       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:

--- 1.11/refman/replication.xml	2005-08-05 23:02:47 +02:00
+++ 1.12/refman/replication.xml	2005-08-06 23:20:34 +02:00
@@ -85,6 +85,37 @@
       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:

--- 1.1/refman-5.0/replication.xml	2005-08-05 19:11:26 +02:00
+++ 1.2/refman-5.0/replication.xml	2005-08-06 23:22:37 +02:00
@@ -89,6 +89,37 @@
       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: