List:Commits« Previous MessageNext Message »
From:paul Date:January 29 2006 9:32pm
Subject:svn commit - mysqldoc@docsrva: r1107 - in trunk: . refman-4.1 refman-5.0 refman-5.1
View as plain text  
Author: paul
Date: 2006-01-29 22:32:03 +0100 (Sun, 29 Jan 2006)
New Revision: 1107

Log:
 r6867@frost:  paul | 2006-01-29 14:48:41 -0600
 General revisions.


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


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

Modified: trunk/refman-4.1/replication.xml
===================================================================
--- trunk/refman-4.1/replication.xml	2006-01-29 21:31:32 UTC (rev 1106)
+++ trunk/refman-4.1/replication.xml	2006-01-29 21:32:03 UTC (rev 1107)
@@ -52,46 +52,45 @@
     statements, see <xref linkend="replication-sql"/>.
   </para>
 
-  <para>
-    We suggest that you visit our Web site at
-    <ulink url="http://www.mysql.com"/> frequently as well as check for
-    revisions to this chapter. Replication is constantly being improved,
-    and we update the manual regularly with the most current
-    information.
-  </para>
-
   <section id="replication-intro">
 
     <title>&title-replication-intro;</title>
 
     <para>
-      MySQL 3.23.15 and up features support for one-way replication. One
-      server acts as the master, while one or more other servers act as
-      slaves. The master server writes updates to its binary log files,
-      and maintains an index of the files to keep track of log rotation.
-      These logs serve as a record of updates to be sent to slave
-      servers. When a slave server connects to the master server, it
-      informs the master of its last position within the logs since the
-      last successfully propagated update. The slave catches up any
-      updates that have occurred since then, and then blocks and waits
-      for the master to notify it of new updates.
+      MySQL 3.23.15 and up features support for one-way, asynchronous
+      replication, in which one server acts as the master, while one or
+      more other servers act as slaves. This is in contrast to the
+      <emphasis>synchronous</emphasis> replication which is a
+      characteristic of MySQL Cluster (see
+      <xref linkend="ndbcluster"/>).
     </para>
 
     <para>
+      In single-master replication, the master server writes updates to
+      its binary log files and maintains an index of those files to keep
+      track of log rotation. The binary log files serve as a record of
+      updates to be sent to any slave servers. When a slave connects to
+      its master, it informs the master of the position up to which the
+      slave read the logs at its last successful update. The slave
+      receives any updates that have taken place since that time, and
+      then blocks and waits for the master to notify it of new updates.
+    </para>
+
+    <para>
       A slave server can itself serve as a master if you want to set up
       chained replication servers.
     </para>
 
     <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 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.
     </para>
 
     <para>
-      One-way replication has benefits for robustness, speed, and system
+      Replication offers benefits for robustness, speed, and system
       administration:
     </para>
 

Modified: trunk/refman-5.0/replication.xml
===================================================================
--- trunk/refman-5.0/replication.xml	2006-01-29 21:31:32 UTC (rev 1106)
+++ trunk/refman-5.0/replication.xml	2006-01-29 21:32:03 UTC (rev 1107)
@@ -50,14 +50,6 @@
     statements, see <xref linkend="replication-sql"/>.
   </para>
 
-  <para>
-    We suggest that you visit our Web site at
-    <ulink url="http://www.mysql.com"/> frequently as well as check for
-    revisions to this chapter. Replication is constantly being improved,
-    and we update the manual regularly with the most current
-    information.
-  </para>
-
   <section id="replication-intro">
 
     <title>&title-replication-intro;</title>
@@ -65,34 +57,44 @@
     <para>
       MySQL features support for one-way, asynchronous replication, in
       which one server acts as the master, while one or more other
-      servers act as slaves. (This is in contrast to the
+      servers act as slaves. This is in contrast to the
       <emphasis>synchronous</emphasis> replication which is a
-      characteristic of MySQL Cluster &mdash; see
-      <xref linkend="ndbcluster"/>.) The master server writes updates to
-      its binary log files, and maintains an index of the files to keep
-      track of log rotation. These logs serve as records of updates to
-      be sent to any slave servers. When a slave connects to the master,
-      it informs the master of the position up to which the slave read
-      in the logs at the last successful update. The slave receives any
-      updates that have taken place since that time, and then blocks and
-      waits for the master to notify it of new updates.
+      characteristic of MySQL Cluster (see
+      <xref linkend="ndbcluster"/>).
     </para>
 
     <para>
+      In single-master replication, the master server writes updates to
+      its binary log files and maintains an index of those files to keep
+      track of log rotation. The binary log files serve as a record of
+      updates to be sent to any slave servers. When a slave connects to
+      its master, it informs the master of the position up to which the
+      slave read the logs at its last successful update. The slave
+      receives any updates that have taken place since that time, and
+      then blocks and waits for the master to notify it of new updates.
+    </para>
+
+    <para>
       A slave server can itself serve as a master if you want to set up
       chained replication servers.
     </para>
 
     <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.
+      Multiple-master replication is possible, but raises issues not
+      present in single-master replication. See
+      <xref linkend="replication-auto-increment"/>.
     </para>
 
     <para>
-      One-way replication has benefits for robustness, speed, and system
+      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.
+    </para>
+
+    <para>
+      Replication offers benefits for robustness, speed, and system
       administration:
     </para>
 

Modified: trunk/refman-5.1/replication.xml
===================================================================
--- trunk/refman-5.1/replication.xml	2006-01-29 21:31:32 UTC (rev 1106)
+++ trunk/refman-5.1/replication.xml	2006-01-29 21:32:03 UTC (rev 1107)
@@ -50,14 +50,6 @@
     statements, see <xref linkend="replication-sql"/>.
   </para>
 
-  <para>
-    We suggest that you visit our Web site at
-    <ulink url="http://www.mysql.com"/> frequently as well as check for
-    revisions to this chapter. Replication is constantly being improved,
-    and we update the manual regularly with the most current
-    information.
-  </para>
-
   <section id="replication-intro">
 
     <title>&title-replication-intro;</title>
@@ -65,63 +57,75 @@
     <para>
       MySQL features support for one-way, asynchronous replication, in
       which one server acts as the master, while one or more other
-      servers act as slaves. (This is in contrast to the
+      servers act as slaves. This is in contrast to the
       <emphasis>synchronous</emphasis> replication which is a
-      characteristic of MySQL Cluster &mdash; see
-      <xref linkend="ndbcluster"/>.) The master server writes updates to
-      its binary log files, and maintains an index of the files to keep
-      track of log rotation. These logs serve as records of updates to
-      be sent to any slave servers. When a slave connects to the master,
-      it informs the master of the position up to which the slave read
-      in the logs at the last successful update. The slave receives any
-      updates that have taken place since that time, and then blocks and
-      waits for the master to notify it of new updates.
+      characteristic of MySQL Cluster (see
+      <xref linkend="ndbcluster"/>).
     </para>
 
     <para>
+      In single-master replication, the master server writes updates to
+      its binary log files and maintains an index of those files to keep
+      track of log rotation. The binary log files serve as a record of
+      updates to be sent to any slave servers. When a slave connects to
+      its master, it informs the master of the position up to which the
+      slave read the logs at its last successful update. The slave
+      receives any updates that have taken place since that time, and
+      then blocks and waits for the master to notify it of new updates.
+    </para>
+
+    <para>
       A slave server can itself serve as a master if you want to set up
       chained replication servers.
     </para>
 
     <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:
+      Multiple-master replication is possible, but raises issues not
+      present in single-master replication. See
+      <xref linkend="replication-auto-increment"/>.
     </para>
 
+    <para>
+      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. Keep in mind as well that updates on the
+      slave side might be affected differently depending on whether you
+      are using statement-based or row-based replication. Consider the
+      following scenario, where a record is inserted on the slave,
+      followed by a statement on the master side that should empty the
+      table:
+    </para>
+
 <programlisting>
-slave> INSERT INTO tbl VALUES (1);
-master> DELETE FROM tbl;
+slave> <userinput>INSERT INTO tbl VALUES (1);</userinput>
+master> <userinput>DELETE FROM tbl;</userinput>
 </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
-      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.
+      operation on the slave server. With statement-based replication,
+      <literal>tbl</literal> will be empty on both master and slave as
+      soon as the slave catches up with the master, because the master
+      sends its <literal>DELETE</literal> statement to the slave. As a
+      result, <literal>tbl</literal> has the same contents on both
+      servers. With row-based replication, the effect of the
+      <literal>DELETE</literal> on the slave is different. The master
+      writes to its binary log each record to be deleted from the table.
+      The slave deletes only those records, and not the row that was
+      inserted on the slave side. As a result, the table has different
+      contents on the master and server, which may cause replication
+      problems.
     </para>
 
     <para>
-      For information about row-based replication (RBR), see
+      For information about row-based replication, see
       <xref linkend="replication-row-based"/>.
     </para>
 
     <para>
-      One-way replication has benefits for robustness, speed, and system
+      Replication offers benefits for robustness, speed, and system
       administration:
     </para>
 

Thread
svn commit - mysqldoc@docsrva: r1107 - in trunk: . refman-4.1 refman-5.0 refman-5.1paul29 Jan