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 — 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 — 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.1 | paul | 29 Jan |
