Author: mcbrown
Date: 2007-02-23 14:36:20 +0100 (Fri, 23 Feb 2007)
New Revision: 5039
Log:
Updating based on PeterL's comments (thanks!)
Modified:
trunk/refman-5.1/replication-configuration.xml
Modified: trunk/refman-5.1/replication-configuration.xml
===================================================================
--- trunk/refman-5.1/replication-configuration.xml 2007-02-23 12:38:56 UTC (rev 5038)
+++ trunk/refman-5.1/replication-configuration.xml 2007-02-23 13:36:20 UTC (rev 5039)
Changed blocks: 5, Lines Added: 16, Lines Deleted: 15; 3617 bytes
@@ -18,10 +18,10 @@
binary logging mechanism. The MySQL instance operating as the master
(the source of the database changes) writes updates and changes to
the database to the binary log. The information in the binary log is
- stored in different logging formats according to the statements
- database changes being recorded. Slaves are configured to read the
- binary log from the master and to execute the events in the binary
- log on the slave's local database.
+ stored in different logging formats according to the database
+ changes being recorded. Slaves are configured to read the binary log
+ from the master and to execute the events in the binary log on the
+ slave's local database.
</para>
<para>
@@ -82,9 +82,10 @@
Events in the binary log are recorded using a number of formats.
These are referred to as statement based replication (SBR) or
row based replication (RBR). A third type, mixed-format
- replication (MIXED), uses SBR or RBR replication according to
- the statements and/or user choice. The different formats are
- discussed in <xref
+ replication (MIXED), uses SBR or RBR replication automatically
+ to take advantage of the benefits of both SBR and RBR formats
+ when appropriate. The different formats are discussed in
+ <xref
linkend="replication-formats"/>.
</para>
</listitem>
@@ -1520,9 +1521,9 @@
possible for the data on the master and slave to become
different if a statement is designed in such a way that the
data modification is <firstterm>non-deterministic</firstterm>;
- that is, it is left to the will of the query optimizer. (This
- is in general not a good practice, even outside of
- replication.) For a detailed explanation of this issue, see
+ that is, it is left to the will of the query optimizer. In
+ general, this is not a good practice even outside of
+ replication. For a detailed explanation of this issue, see
<xref linkend="open-bugs"/>.
</para>
</warning>
@@ -3316,10 +3317,10 @@
<para>
Once replication has been started it should execute without
- requiring a significant form of regular administration. Depending
- on your replication environment, you will want to check the
- replication status of each slave either periodically, daily, or
- even more frequently.
+ requiring much regular administration. Depending on your
+ replication environment, you will want to check the replication
+ status of each slave either periodically, daily, or even more
+ frequently.
</para>
<section id="replication-administration-status">
@@ -3514,7 +3515,7 @@
ceased to receive new events. Using this option can be useful
when you want to pause execution to allow the slave to catch up
with events from the master, when you want to perform
- administration on the slave but ensure you have the latest
+ administration on the slave but also ensure you have the latest
updates to a specific point. This method can also be used to
pause execution on the slave while you conduct administration on
the master while ensuring that there is not a massive backlog of
| Thread |
|---|
| • svn commit - mysqldoc@docsrva: r5039 - trunk/refman-5.1 | mcbrown | 23 Feb |
