List:Commits« Previous MessageNext Message »
From:paul Date:January 29 2006 10:54pm
Subject:svn commit - mysqldoc@docsrva: r1110 - in trunk: . refman-4.1 refman-5.0 refman-5.1
View as plain text  
Author: paul
Date: 2006-01-29 23:54:16 +0100 (Sun, 29 Jan 2006)
New Revision: 1110

Log:
 r6874@frost:  paul | 2006-01-29 16:05:40 -0600
 General revisions.


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


Property changes on: trunk
___________________________________________________________________
Name: svk:merge
   - b5ec3a16-e900-0410-9ad2-d183a3acac99:/mysqldoc-local/mysqldoc/trunk:6869
bf112a9c-6c03-0410-a055-ad865cd57414:/mysqldoc-local/mysqldoc/trunk:2588
   + b5ec3a16-e900-0410-9ad2-d183a3acac99:/mysqldoc-local/mysqldoc/trunk:6874
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:32:47 UTC (rev 1109)
+++ trunk/refman-4.1/replication.xml	2006-01-29 22:54:16 UTC (rev 1110)
@@ -211,25 +211,25 @@
     <para>
       MySQL replication capabilities are implemented using three threads
       (one on the master server and two on the slave). When a
-      <literal>START SLAVE</literal> is issued, the slave creates an I/O
-      thread, which connects to the master and asks it to send the
-      statements recorded in its binary logs. The master creates a
-      thread to send the binary log contents to the slave. This thread
-      can be identified as the <literal>Binlog Dump</literal> thread in
-      the output of <literal>SHOW PROCESSLIST</literal> on the master.
-      The slave I/O thread reads what the master <literal>Binlog
-      Dump</literal> thread sends and copies this data to local files,
-      known as <emphasis>relay logs</emphasis>, in the slave's data
-      directory. The third thread is the SQL thread, which the slave
-      creates to read the relay logs and to execute the updates they
-      contain.
+      <literal>START SLAVE</literal> statement is issued on a slave
+      server, the slave creates an I/O thread, which connects to the
+      master and asks it to send the updates recorded in its binary
+      logs. The master creates a thread to send the binary log contents
+      to the slave. This thread can be identified as the <literal>Binlog
+      Dump</literal> thread in the output of <literal>SHOW
+      PROCESSLIST</literal> on the master. The slave I/O thread reads
+      the updates that the master <literal>Binlog Dump</literal> thread
+      sends and copies them to local files, known as <emphasis>relay
+      logs</emphasis>, in the slave's data directory. The third thread
+      is the SQL thread, which the slave creates to read the relay logs
+      and to execute the updates they contain.
     </para>
 
     <para>
-      In the preceding description, there are three threads per slave. A
-      master that has multiple slaves creates one thread for each slave
-      that is currently connected slave; each slave has its own I/O and
-      SQL threads.
+      In the preceding description, there are three threads per
+      master/slave connection. A master that has multiple slaves creates
+      one thread for each currently-connected slave, and each slave has
+      its own I/O and SQL threads.
     </para>
 
     <para>
@@ -240,37 +240,33 @@
     </para>
 
     <para>
-      The advantage of using two slave threads is that statement reading
-      and execution are separated into two independent tasks. The task
-      of reading statements is not slowed down if statement execution is
-      slow. For example, if the slave server has not been running for a
-      while, its I/O thread can quickly fetch all the binary log
-      contents from the master when the slave starts, even if the SQL
-      thread lags far behind and may take hours to catch up. If the
-      slave stops before the SQL thread has executed all the fetched
-      statements, the I/O thread has at least fetched everything so that
-      a safe copy of the statements is stored locally in the slave's
-      relay logs, ready for execution the next time that the slave
-      starts. This allows the binary logs to be purged on the master,
-      because it no longer needs to wait for the slave to fetch their
-      contents.
+      The slave uses two threads so that reading updates from the master
+      and executing them can be separated into two independent tasks.
+      Thus, the task of reading statements is not slowed down if
+      statement execution is slow. For example, if the slave server has
+      not been running for a while, its I/O thread can quickly fetch all
+      the binary log contents from the master when the slave starts,
+      even if the SQL thread lags far behind. If the slave stops before
+      the SQL thread has executed all the fetched statements, the I/O
+      thread has at least fetched everything so that a safe copy of the
+      statements is stored locally in the slave's relay logs, ready for
+      execution the next time that the slave starts. This enables the
+      master server to purge its binary logs sooner because it no longer
+      needs to wait for the slave to fetch their contents.
     </para>
 
     <para>
       The <literal>SHOW PROCESSLIST</literal> statement provides
       information that tells you what is happening on the master and on
-      the slave regarding replication.
+      the slave regarding replication. The following example illustrates
+      how the three threads show up in the output from <literal>SHOW
+      PROCESSLIST</literal>. The output format is that used by
+      <literal>SHOW PROCESSLIST</literal> as of MySQL version 4.0.15,
+      when the content of the <literal>State</literal> column was
+      changed to be more meaningful compared to earlier versions.
     </para>
 
     <para>
-      The following example illustrates how the three threads show up in
-      <literal>SHOW PROCESSLIST</literal>. The output format is that
-      used by <literal>SHOW PROCESSLIST</literal> as of MySQL version
-      4.0.15, when the content of the <literal>State</literal> column
-      was changed to be more meaningful compared to earlier versions.
-    </para>
-
-    <para>
       On the master server, the output from <literal>SHOW
       PROCESSLIST</literal> looks like this:
     </para>
@@ -290,10 +286,13 @@
 </programlisting>
 
     <para>
-      Here, thread 2 is a replication thread for a connected slave. The
+      Here, thread 2 is a <literal>Binlog Dump</literal> replication
+      thread for a connected slave. The <literal>State</literal>
       information indicates that all outstanding updates have been sent
       to the slave and that the master is waiting for more updates to
-      occur.
+      occur. If you see no <literal>Binlog Dump</literal> threads on a
+      master server, this means that replication is not running &mdash;
+      that is, that no slaves are currently connected.
     </para>
 
     <para>
@@ -333,8 +332,8 @@
     </para>
 
     <para>
-      Note that the value in the <literal>Time</literal> column can show
-      how late the slave is compared to the master. See
+      The value in the <literal>Time</literal> column can show how late
+      the slave is compared to the master. See
       <xref linkend="replication-faq"/>.
     </para>
 
@@ -345,7 +344,7 @@
       <para>
         The following list shows the most common states you may see in
         the <literal>State</literal> column for the master's
-        <literal>Binlog Dump</literal> thread. If you don't see any
+        <literal>Binlog Dump</literal> thread. If you see no
         <literal>Binlog Dump</literal> threads on a master server, this
         means that replication is not running &mdash; that is, that no
         slaves are currently connected.
@@ -414,10 +413,9 @@
         The following list shows the most common states you see in the
         <literal>State</literal> column for a slave server I/O thread.
         Beginning with MySQL 4.1.1, this state also appears in the
-        <literal>Slave_IO_State</literal> column displayed by the
-        <literal>SHOW SLAVE STATUS</literal> statement. This means that
-        you can get a good view of what is happening by using only
-        <literal>SHOW SLAVE STATUS</literal>.
+        <literal>Slave_IO_State</literal> column displayed by
+        <literal>SHOW SLAVE STATUS</literal>, so by using that
+        statement, you can get a good view of what is happening.
       </para>
 
       <itemizedlist>
@@ -438,8 +436,8 @@
           </para>
 
           <para>
-            A state that occurs very briefly, immediately after the
-            connection to the master is established.
+            A state that occurs very briefly, after the connection to
+            the master is established.
           </para>
         </listitem>
 
@@ -449,8 +447,8 @@
           </para>
 
           <para>
-            A state that occurs very briefly immediately after the
-            connection to the master is established.
+            A state that occurs very briefly after the connection to the
+            master is established.
           </para>
         </listitem>
 
@@ -460,11 +458,10 @@
           </para>
 
           <para>
-            A state that occurs very briefly, immediately after the
-            connection to the master is established. The thread sends to
-            the master a request for the contents of its binary logs,
-            starting from the requested binary log filename and
-            position.
+            A state that occurs very briefly, after the connection to
+            the master is established. The thread sends to the master a
+            request for the contents of its binary logs, starting from
+            the requested binary log filename and position.
           </para>
         </listitem>
 
@@ -505,7 +502,7 @@
             if the master is idle. If the wait lasts for
             <literal>slave_read_timeout</literal> seconds, a timeout
             occurs. At that point, the thread considers the connection
-            to be broken and make an attempt to reconnect.
+            to be broken and makes an attempt to reconnect.
           </para>
         </listitem>
 
@@ -556,10 +553,10 @@
           <para>
             You are using a non-zero
             <literal>relay_log_space_limit</literal> value, and the
-            relay logs have grown until their combined size exceeds this
-            value. The I/O thread is waiting until the SQL thread frees
-            enough space by processing relay log contents so that it can
-            delete some relay log files.
+            relay logs have grown large enough that their combined size
+            exceeds this value. The I/O thread is waiting until the SQL
+            thread frees enough space by processing relay log contents
+            so that it can delete some relay log files.
           </para>
         </listitem>
 
@@ -639,44 +636,44 @@
       <title>&title-slave-logs;</title>
 
       <para>
-        By default, relay logs are named using filenames of the form
+        By default, relay logs filenames have the form
         <filename><replaceable>host_name</replaceable>-relay-bin.<replaceable>nnnnnn</replaceable></filename>,
         where <replaceable>host_name</replaceable> is the name of the
         slave server host and <replaceable>nnnnnn</replaceable> is a
         sequence number. Successive relay log files are created using
         successive sequence numbers, beginning with
         <literal>000001</literal> (<literal>001</literal> in MySQL 4.0
-        or older). The slave keeps track of relay logs currently in use
-        in an index file. The default relay log index filename is
+        or older). The slave uses an index file to track the relay log
+        files currently in use. The default relay log index filename is
         <filename><replaceable>host_name</replaceable>-relay-bin.index</filename>.
-        By default, these files are created in the slave's data
-        directory. The default filenames may be overridden with the
+        By default, the slave server creates relay log files in its data
+        directory. The default filenames can be overridden with the
         <option>--relay-log</option> and
         <option>--relay-log-index</option> server options. See
         <xref linkend="replication-options"/>.
       </para>
 
       <para>
-        Relay logs have the same format as binary logs, and can be read
-        using <command>mysqlbinlog</command>. A relay log is
-        automatically deleted by the SQL thread as soon as it has
-        executed all its events and no longer needs it). There is no
-        explicit mechanism for deleting relay logs because the SQL
-        thread takes care of doing so. However, from MySQL 4.0.14,
+        Relay logs have the same format as binary logs and can be read
+        using <command>mysqlbinlog</command>. The SQL thread
+        automatically deletes each relay log file as soon as it has
+        executed all events in the file and no longer needs it. There is
+        no explicit mechanism for deleting relay logs because the SQL
+        thread takes care of doing so. However, as of MySQL 4.0.14,
         <literal>FLUSH LOGS</literal> rotates relay logs, which
         influences when the SQL thread deletes them.
       </para>
 
       <para>
-        A new relay log is created under the following conditions:
+        A slave server creates a new relay log file under the following
+        conditions:
       </para>
 
       <itemizedlist>
 
         <listitem>
           <para>
-            When the I/O thread starts for the first time after the
-            slave server starts.
+            Each time the I/O thread starts.
           </para>
         </listitem>
 
@@ -699,16 +696,19 @@
 
             <listitem>
               <para>
-                <literal>max_relay_log_size</literal>, if
-                <literal>max_relay_log_size</literal> &gt; 0
+                If the value of <literal>max_relay_log_size</literal> is
+                greater than 0, that is the maximum relay log file size.
               </para>
             </listitem>
 
             <listitem>
               <para>
-                <literal>max_binlog_size</literal>, if
-                <literal>max_relay_log_size</literal> = 0 or MySQL is
-                older than 4.0.14
+                If the value of <literal>max_relay_log_size</literal> is
+                0, <literal>max_binlog_size</literal> determines the
+                maximum relay log file size.
+                <literal>max_binlog_size</literal> always determines the
+                relay log size before MySQL 4.0.14, the first version in
+                which <literal>max_relay_log_size</literal> appears.
               </para>
             </listitem>
 
@@ -721,23 +721,30 @@
         A slave replication server creates two additional small files in
         the data directory. These <emphasis>status files</emphasis> are
         named <filename>master.info</filename> and
-        <filename>relay-log.info</filename> by default. They contain
-        information like that shown in the output of the <literal>SHOW
-        SLAVE STATUS</literal> statement (see
-        <xref linkend="replication-slave-sql"/>, for a description of
-        this statement). As disk files, they survive a slave server's
-        shutdown. The next time the slave starts up, it reads these
-        files to determine how far it has proceeded in reading binary
-        logs from the master and in processing its own relay logs.
+        <filename>relay-log.info</filename> by default. Their names can
+        be changed by using the <option>--master-info-file</option> and
+        <option>--relay-log-info-file</option> options. See
+        <xref linkend="replication-options"/>.
       </para>
 
       <para>
-        The <filename>master.info</filename> file is updated by the I/O
-        thread. Before MySQL 4.1, the correspondence between the lines
-        in the file and the columns displayed by <literal>SHOW SLAVE
-        STATUS</literal> is as follows:
+        The two status files contain information like that shown in the
+        output of the <literal>SHOW SLAVE STATUS</literal> statement,
+        which is discussed in <xref linkend="replication-slave-sql"/>.
+        Because the status files are stored on disk, they survive a
+        slave server's shutdown. The next time the slave starts up, it
+        reads the two files to determine how far it has proceeded in
+        reading binary logs from the master and in processing its own
+        relay logs.
       </para>
 
+      <para>
+        The I/O thread updates the <filename>master.info</filename>
+        file. Before MySQL 4.1, the following table shows the
+        correspondence between the lines in the file and the columns
+        displayed by <literal>SHOW SLAVE STATUS</literal>.
+      </para>
+
       <informaltable>
         <tgroup cols="2">
           <colspec colwidth="15*"/>
@@ -854,10 +861,10 @@
       </informaltable>
 
       <para>
-        The <filename>relay-log.info</filename> file is updated by the
-        SQL thread. The correspondence between the lines in the file and
-        the columns displayed by <literal>SHOW SLAVE STATUS</literal> is
-        shown here:
+        The SQL thread updates the <filename>relay-log.info</filename>
+        file. The following table shows the correspondence between the
+        lines in the file and the columns displayed by <literal>SHOW
+        SLAVE STATUS</literal>.
       </para>
 
       <informaltable>
@@ -897,7 +904,7 @@
 
       <para>
         When you back up the slave's data, you should back up these two
-        small files as well, along with the relay log files. They are
+        status files as well, along with the relay log files. They are
         needed to resume replication after you restore the slave's data.
         If you lose the relay logs but still have the
         <filename>relay-log.info</filename> file, you can check it to
@@ -917,9 +924,9 @@
         these files to resume replication of any interrupted
         <literal>LOAD DATA INFILE</literal> operations. The directory
         location is specified using the
-        <option>--slave-load-tmpdir</option> option. Its default value,
-        if not specified, is the value of the <literal>tmpdir</literal>
-        variable.
+        <option>--slave-load-tmpdir</option> option. If this option is
+        not specified, the directory location is the value of the
+        <literal>tmpdir</literal> system variable.
       </para>
 
     </section>

Modified: trunk/refman-4.1/sql-syntax.xml
===================================================================
--- trunk/refman-4.1/sql-syntax.xml	2006-01-29 21:32:47 UTC (rev 1109)
+++ trunk/refman-4.1/sql-syntax.xml	2006-01-29 22:54:16 UTC (rev 1110)
@@ -14876,7 +14876,10 @@
               The most common <literal>State</literal> values are
               described in the rest of this section. Most of the other
               <literal>State</literal> values are useful only for
-              finding bugs in the server.
+              finding bugs in the server. See also
+              <xref linkend="replication-implementation-details"/>, for
+              additional information about process states for
+              replication servers.
             </para>
 
             <para>

Modified: trunk/refman-5.0/replication.xml
===================================================================
--- trunk/refman-5.0/replication.xml	2006-01-29 21:32:47 UTC (rev 1109)
+++ trunk/refman-5.0/replication.xml	2006-01-29 22:54:16 UTC (rev 1110)
@@ -214,55 +214,52 @@
     <para>
       MySQL replication capabilities are implemented using three threads
       (one on the master server and two on the slave). When a
-      <literal>START SLAVE</literal> is issued, the slave creates an I/O
-      thread, which connects to the master and asks it to send the
-      statements recorded in its binary logs. The master creates a
-      thread to send the binary log contents to the slave. This thread
-      can be identified as the <literal>Binlog Dump</literal> thread in
-      the output of <literal>SHOW PROCESSLIST</literal> on the master.
-      The slave I/O thread reads what the master <literal>Binlog
-      Dump</literal> thread sends and copies this data to local files,
-      known as <emphasis>relay logs</emphasis>, in the slave's data
-      directory. The third thread is the SQL thread, which the slave
-      creates to read the relay logs and to execute the updates they
-      contain.
+      <literal>START SLAVE</literal> statement is issued on a slave
+      server, the slave creates an I/O thread, which connects to the
+      master and asks it to send the updates recorded in its binary
+      logs. The master creates a thread to send the binary log contents
+      to the slave. This thread can be identified as the <literal>Binlog
+      Dump</literal> thread in the output of <literal>SHOW
+      PROCESSLIST</literal> on the master. The slave I/O thread reads
+      the updates that the master <literal>Binlog Dump</literal> thread
+      sends and copies them to local files, known as <emphasis>relay
+      logs</emphasis>, in the slave's data directory. The third thread
+      is the SQL thread, which the slave creates to read the relay logs
+      and to execute the updates they contain.
     </para>
 
     <para>
-      In the preceding description, there are three threads per slave. A
-      master that has multiple slaves creates one thread for each slave
-      that is currently connected slave; each slave has its own I/O and
-      SQL threads.
+      In the preceding description, there are three threads per
+      master/slave connection. A master that has multiple slaves creates
+      one thread for each currently-connected slave, and each slave has
+      its own I/O and SQL threads.
     </para>
 
     <para>
-      Reading of statements and executing them are thus separated into
-      two independent tasks. The task of reading statements is not
-      slowed down if statement execution is slow. For example, if the
-      slave server has not been running for a while, its I/O thread can
-      quickly fetch all the binary log contents from the master when the
-      slave starts, even if the SQL thread lags far behind. If the slave
-      stops before the SQL thread has executed all the fetched
-      statements, the I/O thread has at least fetched everything so that
-      a safe copy of the statements is stored locally in the slave's
-      relay logs, ready for execution the next time that the slave
-      starts. This allows the binary logs to be purged on the master,
-      because it no longer needs to wait for the slave to fetch their
-      contents.
+      The slave uses two threads so that reading updates from the master
+      and executing them can be separated into two independent tasks.
+      Thus, the task of reading statements is not slowed down if
+      statement execution is slow. For example, if the slave server has
+      not been running for a while, its I/O thread can quickly fetch all
+      the binary log contents from the master when the slave starts,
+      even if the SQL thread lags far behind. If the slave stops before
+      the SQL thread has executed all the fetched statements, the I/O
+      thread has at least fetched everything so that a safe copy of the
+      statements is stored locally in the slave's relay logs, ready for
+      execution the next time that the slave starts. This enables the
+      master server to purge its binary logs sooner because it no longer
+      needs to wait for the slave to fetch their contents.
     </para>
 
     <para>
       The <literal>SHOW PROCESSLIST</literal> statement provides
       information that tells you what is happening on the master and on
-      the slave regarding replication.
+      the slave regarding replication. The following example illustrates
+      how the three threads show up in the output from <literal>SHOW
+      PROCESSLIST</literal>.
     </para>
 
     <para>
-      The following example illustrates how the three threads show up in
-      <literal>SHOW PROCESSLIST</literal>.
-    </para>
-
-    <para>
       On the master server, the output from <literal>SHOW
       PROCESSLIST</literal> looks like this:
     </para>
@@ -282,10 +279,13 @@
 </programlisting>
 
     <para>
-      Here, thread 2 is a replication thread for a connected slave. The
+      Here, thread 2 is a <literal>Binlog Dump</literal> replication
+      thread for a connected slave. The <literal>State</literal>
       information indicates that all outstanding updates have been sent
       to the slave and that the master is waiting for more updates to
-      occur.
+      occur. If you see no <literal>Binlog Dump</literal> threads on a
+      master server, this means that replication is not running &mdash;
+      that is, that no slaves are currently connected.
     </para>
 
     <para>
@@ -325,8 +325,8 @@
     </para>
 
     <para>
-      Note that the value in the <literal>Time</literal> column can show
-      how late the slave is compared to the master. See
+      The value in the <literal>Time</literal> column can show how late
+      the slave is compared to the master. See
       <xref linkend="replication-faq"/>.
     </para>
 
@@ -337,7 +337,7 @@
       <para>
         The following list shows the most common states you may see in
         the <literal>State</literal> column for the master's
-        <literal>Binlog Dump</literal> thread. If you don't see any
+        <literal>Binlog Dump</literal> thread. If you see no
         <literal>Binlog Dump</literal> threads on a master server, this
         means that replication is not running &mdash; that is, that no
         slaves are currently connected.
@@ -406,9 +406,9 @@
         The following list shows the most common states you see in the
         <literal>State</literal> column for a slave server I/O thread.
         This state also appears in the <literal>Slave_IO_State</literal>
-        column displayed by <literal>SHOW SLAVE STATUS</literal>. This
-        means that you can get a good view of what is happening merely
-        by using this statement.
+        column displayed by <literal>SHOW SLAVE STATUS</literal>, so by
+        using that statement, you can get a good view of what is
+        happening.
       </para>
 
       <itemizedlist>
@@ -429,8 +429,8 @@
           </para>
 
           <para>
-            A state that occurs very briefly, immediately after the
-            connection to the master is established.
+            A state that occurs very briefly, after the connection to
+            the master is established.
           </para>
         </listitem>
 
@@ -440,8 +440,8 @@
           </para>
 
           <para>
-            A state that occurs very briefly immediately after the
-            connection to the master is established.
+            A state that occurs very briefly after the connection to the
+            master is established.
           </para>
         </listitem>
 
@@ -451,11 +451,10 @@
           </para>
 
           <para>
-            A state that occurs very briefly, immediately after the
-            connection to the master is established. The thread sends to
-            the master a request for the contents of its binary logs,
-            starting from the requested binary log filename and
-            position.
+            A state that occurs very briefly, after the connection to
+            the master is established. The thread sends to the master a
+            request for the contents of its binary logs, starting from
+            the requested binary log filename and position.
           </para>
         </listitem>
 
@@ -496,7 +495,7 @@
             if the master is idle. If the wait lasts for
             <literal>slave_read_timeout</literal> seconds, a timeout
             occurs. At that point, the thread considers the connection
-            to be broken and make an attempt to reconnect.
+            to be broken and makes an attempt to reconnect.
           </para>
         </listitem>
 
@@ -547,10 +546,10 @@
           <para>
             You are using a non-zero
             <literal>relay_log_space_limit</literal> value, and the
-            relay logs have grown until their combined size exceeds this
-            value. The I/O thread is waiting until the SQL thread frees
-            enough space by processing relay log contents so that it can
-            delete some relay log files.
+            relay logs have grown large enough that their combined size
+            exceeds this value. The I/O thread is waiting until the SQL
+            thread frees enough space by processing relay log contents
+            so that it can delete some relay log files.
           </para>
         </listitem>
 
@@ -630,42 +629,44 @@
       <title>&title-slave-logs;</title>
 
       <para>
-        By default, relay logs are named using filenames of the form
+        By default, relay logs filenames have the form
         <filename><replaceable>host_name</replaceable>-relay-bin.<replaceable>nnnnnn</replaceable></filename>,
         where <replaceable>host_name</replaceable> is the name of the
         slave server host and <replaceable>nnnnnn</replaceable> is a
         sequence number. Successive relay log files are created using
         successive sequence numbers, beginning with
-        <literal>000001</literal>. The slave tracks relay logs currently
-        in use in an index file. The default relay log index filename is
+        <literal>000001</literal>. The slave uses an index file to track
+        the relay log files currently in use. The default relay log
+        index filename is
         <filename><replaceable>host_name</replaceable>-relay-bin.index</filename>.
-        By default, these files are created in the slave's data
-        directory. The default filenames may be overridden with the
+        By default, the slave server creates relay log files in its data
+        directory. The default filenames can be overridden with the
         <option>--relay-log</option> and
         <option>--relay-log-index</option> server options. See
         <xref linkend="replication-options"/>.
       </para>
 
       <para>
-        Relay logs have the same format as binary logs, and can be read
-        using <command>mysqlbinlog</command>. A relay log is
-        automatically deleted by the SQL thread as soon as it has
-        executed all its events and no longer needs it. There is no
-        explicit mechanism for deleting relay logs because the SQL
+        Relay logs have the same format as binary logs and can be read
+        using <command>mysqlbinlog</command>. The SQL thread
+        automatically deletes each relay log file as soon as it has
+        executed all events in the file and no longer needs it. There is
+        no explicit mechanism for deleting relay logs because the SQL
         thread takes care of doing so. However, <literal>FLUSH
         LOGS</literal> rotates relay logs, which influences when the SQL
         thread deletes them.
       </para>
 
       <para>
-        A new relay log is created under the following conditions:
+        A slave server creates a new relay log file under the following
+        conditions:
       </para>
 
       <itemizedlist>
 
         <listitem>
           <para>
-            A new relay log is created each time the I/O thread starts.
+            Each time the I/O thread starts.
           </para>
         </listitem>
 
@@ -687,15 +688,16 @@
 
             <listitem>
               <para>
-                <literal>max_relay_log_size</literal>, if
-                <literal>max_relay_log_size</literal> &gt; 0
+                If the value of <literal>max_relay_log_size</literal> is
+                greater than 0, that is the maximum relay log file size.
               </para>
             </listitem>
 
             <listitem>
               <para>
-                <literal>max_binlog_size</literal>, if
-                <literal>max_relay_log_size</literal> = 0
+                If the value of <literal>max_relay_log_size</literal> is
+                0, <literal>max_binlog_size</literal> determines the
+                maximum relay log file size.
               </para>
             </listitem>
 
@@ -708,23 +710,30 @@
         A slave replication server creates two additional small files in
         the data directory. These <emphasis>status files</emphasis> are
         named <filename>master.info</filename> and
-        <filename>relay-log.info</filename> by default. They contain
-        information like that shown in the output of the <literal>SHOW
-        SLAVE STATUS</literal> statement (see
-        <xref linkend="replication-slave-sql"/>, for a description of
-        this statement). As disk files, they survive a slave server's
-        shutdown. The next time the slave starts up, it reads these
-        files to determine how far it has proceeded in reading binary
-        logs from the master and in processing its own relay logs.
+        <filename>relay-log.info</filename> by default. Their names can
+        be changed by using the <option>--master-info-file</option> and
+        <option>--relay-log-info-file</option> options. See
+        <xref linkend="replication-options"/>.
       </para>
 
       <para>
-        The <filename>master.info</filename> file is updated by the I/O
-        thread. The correspondence between the lines in the file and the
-        columns displayed by <literal>SHOW SLAVE STATUS</literal> is as
-        follows:
+        The two status files contain information like that shown in the
+        output of the <literal>SHOW SLAVE STATUS</literal> statement,
+        which is discussed in <xref linkend="replication-slave-sql"/>.
+        Because the status files are stored on disk, they survive a
+        slave server's shutdown. The next time the slave starts up, it
+        reads the two files to determine how far it has proceeded in
+        reading binary logs from the master and in processing its own
+        relay logs.
       </para>
 
+      <para>
+        The I/O thread updates the <filename>master.info</filename>
+        file. The following table shows the correspondence between the
+        lines in the file and the columns displayed by <literal>SHOW
+        SLAVE STATUS</literal>.
+      </para>
+
       <informaltable>
         <tgroup cols="2">
           <colspec colwidth="15*"/>
@@ -795,10 +804,10 @@
       </informaltable>
 
       <para>
-        The <filename>relay-log.info</filename> file is updated by the
-        SQL thread. The correspondence between the lines in the file and
-        the columns displayed by <literal>SHOW SLAVE STATUS</literal> is
-        shown here:
+        The SQL thread updates the <filename>relay-log.info</filename>
+        file. The following table shows the correspondence between the
+        lines in the file and the columns displayed by <literal>SHOW
+        SLAVE STATUS</literal>.
       </para>
 
       <informaltable>
@@ -838,7 +847,7 @@
 
       <para>
         When you back up the slave's data, you should back up these two
-        small files as well, along with the relay log files. They are
+        status files as well, along with the relay log files. They are
         needed to resume replication after you restore the slave's data.
         If you lose the relay logs but still have the
         <filename>relay-log.info</filename> file, you can check it to
@@ -858,9 +867,9 @@
         these files to resume replication of any interrupted
         <literal>LOAD DATA INFILE</literal> operations. The directory
         location is specified using the
-        <option>--slave-load-tmpdir</option> option. Its default value,
-        if not specified, is the value of the <literal>tmpdir</literal>
-        variable.
+        <option>--slave-load-tmpdir</option> option. If this option is
+        not specified, the directory location is the value of the
+        <literal>tmpdir</literal> system variable.
       </para>
 
     </section>

Modified: trunk/refman-5.0/sql-syntax.xml
===================================================================
--- trunk/refman-5.0/sql-syntax.xml	2006-01-29 21:32:47 UTC (rev 1109)
+++ trunk/refman-5.0/sql-syntax.xml	2006-01-29 22:54:16 UTC (rev 1110)
@@ -16208,7 +16208,10 @@
               The most common <literal>State</literal> values are
               described in the rest of this section. Most of the other
               <literal>State</literal> values are useful only for
-              finding bugs in the server.
+              finding bugs in the server. See also
+              <xref linkend="replication-implementation-details"/>, for
+              additional information about process states for
+              replication servers.
             </para>
 
             <para>

Modified: trunk/refman-5.1/replication.xml
===================================================================
--- trunk/refman-5.1/replication.xml	2006-01-29 21:32:47 UTC (rev 1109)
+++ trunk/refman-5.1/replication.xml	2006-01-29 22:54:16 UTC (rev 1110)
@@ -392,55 +392,52 @@
     <para>
       MySQL replication capabilities are implemented using three threads
       (one on the master server and two on the slave). When a
-      <literal>START SLAVE</literal> is issued, the slave creates an I/O
-      thread, which connects to the master and asks it to send the
-      statements recorded in its binary logs. The master creates a
-      thread to send the binary log contents to the slave. This thread
-      can be identified as the <literal>Binlog Dump</literal> thread in
-      the output of <literal>SHOW PROCESSLIST</literal> on the master.
-      The slave I/O thread reads what the master <literal>Binlog
-      Dump</literal> thread sends and copies this data to local files,
-      known as <emphasis>relay logs</emphasis>, in the slave's data
-      directory. The third thread is the SQL thread, which the slave
-      creates to read the relay logs and to execute the updates they
-      contain.
+      <literal>START SLAVE</literal> statement is issued on a slave
+      server, the slave creates an I/O thread, which connects to the
+      master and asks it to send the updates recorded in its binary
+      logs. The master creates a thread to send the binary log contents
+      to the slave. This thread can be identified as the <literal>Binlog
+      Dump</literal> thread in the output of <literal>SHOW
+      PROCESSLIST</literal> on the master. The slave I/O thread reads
+      the updates that the master <literal>Binlog Dump</literal> thread
+      sends and copies them to local files, known as <emphasis>relay
+      logs</emphasis>, in the slave's data directory. The third thread
+      is the SQL thread, which the slave creates to read the relay logs
+      and to execute the updates they contain.
     </para>
 
     <para>
-      In the preceding description, there are three threads per slave. A
-      master that has multiple slaves creates one thread for each slave
-      that is currently connected slave; each slave has its own I/O and
-      SQL threads.
+      In the preceding description, there are three threads per
+      master/slave connection. A master that has multiple slaves creates
+      one thread for each currently-connected slave, and each slave has
+      its own I/O and SQL threads.
     </para>
 
     <para>
-      Reading of statements and executing them are thus separated into
-      two independent tasks. The task of reading statements is not
-      slowed down if statement execution is slow. For example, if the
-      slave server has not been running for a while, its I/O thread can
-      quickly fetch all the binary log contents from the master when the
-      slave starts, even if the SQL thread lags far behind. If the slave
-      stops before the SQL thread has executed all the fetched
-      statements, the I/O thread has at least fetched everything so that
-      a safe copy of the statements is stored locally in the slave's
-      relay logs, ready for execution the next time that the slave
-      starts. This allows the binary logs to be purged on the master,
-      because it no longer needs to wait for the slave to fetch their
-      contents.
+      The slave uses two threads so that reading updates from the master
+      and executing them can be separated into two independent tasks.
+      Thus, the task of reading statements is not slowed down if
+      statement execution is slow. For example, if the slave server has
+      not been running for a while, its I/O thread can quickly fetch all
+      the binary log contents from the master when the slave starts,
+      even if the SQL thread lags far behind. If the slave stops before
+      the SQL thread has executed all the fetched statements, the I/O
+      thread has at least fetched everything so that a safe copy of the
+      statements is stored locally in the slave's relay logs, ready for
+      execution the next time that the slave starts. This enables the
+      master server to purge its binary logs sooner because it no longer
+      needs to wait for the slave to fetch their contents.
     </para>
 
     <para>
       The <literal>SHOW PROCESSLIST</literal> statement provides
       information that tells you what is happening on the master and on
-      the slave regarding replication.
+      the slave regarding replication. The following example illustrates
+      how the three threads show up in the output from <literal>SHOW
+      PROCESSLIST</literal>.
     </para>
 
     <para>
-      The following example illustrates how the three threads show up in
-      <literal>SHOW PROCESSLIST</literal>.
-    </para>
-
-    <para>
       On the master server, the output from <literal>SHOW
       PROCESSLIST</literal> looks like this:
     </para>
@@ -460,10 +457,13 @@
 </programlisting>
 
     <para>
-      Here, thread 2 is a replication thread for a connected slave. The
+      Here, thread 2 is a <literal>Binlog Dump</literal> replication
+      thread for a connected slave. The <literal>State</literal>
       information indicates that all outstanding updates have been sent
       to the slave and that the master is waiting for more updates to
-      occur.
+      occur. If you see no <literal>Binlog Dump</literal> threads on a
+      master server, this means that replication is not running &mdash;
+      that is, that no slaves are currently connected.
     </para>
 
     <para>
@@ -503,8 +503,8 @@
     </para>
 
     <para>
-      Note that the value in the <literal>Time</literal> column can show
-      how late the slave is compared to the master. See
+      The value in the <literal>Time</literal> column can show how late
+      the slave is compared to the master. See
       <xref linkend="replication-faq"/>.
     </para>
 
@@ -515,7 +515,7 @@
       <para>
         The following list shows the most common states you may see in
         the <literal>State</literal> column for the master's
-        <literal>Binlog Dump</literal> thread. If you don't see any
+        <literal>Binlog Dump</literal> thread. If you see no
         <literal>Binlog Dump</literal> threads on a master server, this
         means that replication is not running &mdash; that is, that no
         slaves are currently connected.
@@ -584,9 +584,9 @@
         The following list shows the most common states you see in the
         <literal>State</literal> column for a slave server I/O thread.
         This state also appears in the <literal>Slave_IO_State</literal>
-        column displayed by <literal>SHOW SLAVE STATUS</literal>. This
-        means that you can get a good view of what is happening merely
-        by using this statement.
+        column displayed by <literal>SHOW SLAVE STATUS</literal>, so by
+        using that statement, you can get a good view of what is
+        happening.
       </para>
 
       <itemizedlist>
@@ -607,8 +607,8 @@
           </para>
 
           <para>
-            A state that occurs very briefly, immediately after the
-            connection to the master is established.
+            A state that occurs very briefly, after the connection to
+            the master is established.
           </para>
         </listitem>
 
@@ -618,8 +618,8 @@
           </para>
 
           <para>
-            A state that occurs very briefly immediately after the
-            connection to the master is established.
+            A state that occurs very briefly after the connection to the
+            master is established.
           </para>
         </listitem>
 
@@ -629,11 +629,10 @@
           </para>
 
           <para>
-            A state that occurs very briefly, immediately after the
-            connection to the master is established. The thread sends to
-            the master a request for the contents of its binary logs,
-            starting from the requested binary log filename and
-            position.
+            A state that occurs very briefly, after the connection to
+            the master is established. The thread sends to the master a
+            request for the contents of its binary logs, starting from
+            the requested binary log filename and position.
           </para>
         </listitem>
 
@@ -674,7 +673,7 @@
             if the master is idle. If the wait lasts for
             <literal>slave_read_timeout</literal> seconds, a timeout
             occurs. At that point, the thread considers the connection
-            to be broken and make an attempt to reconnect.
+            to be broken and makes an attempt to reconnect.
           </para>
         </listitem>
 
@@ -725,10 +724,10 @@
           <para>
             You are using a non-zero
             <literal>relay_log_space_limit</literal> value, and the
-            relay logs have grown until their combined size exceeds this
-            value. The I/O thread is waiting until the SQL thread frees
-            enough space by processing relay log contents so that it can
-            delete some relay log files.
+            relay logs have grown large enough that their combined size
+            exceeds this value. The I/O thread is waiting until the SQL
+            thread frees enough space by processing relay log contents
+            so that it can delete some relay log files.
           </para>
         </listitem>
 
@@ -808,42 +807,44 @@
       <title>&title-slave-logs;</title>
 
       <para>
-        By default, relay logs are named using filenames of the form
+        By default, relay logs filenames have the form
         <filename><replaceable>host_name</replaceable>-relay-bin.<replaceable>nnnnnn</replaceable></filename>,
         where <replaceable>host_name</replaceable> is the name of the
         slave server host and <replaceable>nnnnnn</replaceable> is a
         sequence number. Successive relay log files are created using
         successive sequence numbers, beginning with
-        <literal>000001</literal>. The slave tracks relay logs currently
-        in use in an index file. The default relay log index filename is
+        <literal>000001</literal>. The slave uses an index file to track
+        the relay log files currently in use. The default relay log
+        index filename is
         <filename><replaceable>host_name</replaceable>-relay-bin.index</filename>.
-        By default, these files are created in the slave's data
-        directory. The default filenames may be overridden with the
+        By default, the slave server creates relay log files in its data
+        directory. The default filenames can be overridden with the
         <option>--relay-log</option> and
         <option>--relay-log-index</option> server options. See
         <xref linkend="replication-options"/>.
       </para>
 
       <para>
-        Relay logs have the same format as binary logs, and can be read
-        using <command>mysqlbinlog</command>. A relay log is
-        automatically deleted by the SQL thread as soon as it has
-        executed all its events and no longer needs it. There is no
-        explicit mechanism for deleting relay logs because the SQL
+        Relay logs have the same format as binary logs and can be read
+        using <command>mysqlbinlog</command>. The SQL thread
+        automatically deletes each relay log file as soon as it has
+        executed all events in the file and no longer needs it. There is
+        no explicit mechanism for deleting relay logs because the SQL
         thread takes care of doing so. However, <literal>FLUSH
         LOGS</literal> rotates relay logs, which influences when the SQL
         thread deletes them.
       </para>
 
       <para>
-        A new relay log is created under the following conditions:
+        A slave server creates a new relay log file under the following
+        conditions:
       </para>
 
       <itemizedlist>
 
         <listitem>
           <para>
-            A new relay log is created each time the I/O thread starts.
+            Each time the I/O thread starts.
           </para>
         </listitem>
 
@@ -865,15 +866,16 @@
 
             <listitem>
               <para>
-                <literal>max_relay_log_size</literal>, if
-                <literal>max_relay_log_size</literal> &gt; 0
+                If the value of <literal>max_relay_log_size</literal> is
+                greater than 0, that is the maximum relay log file size.
               </para>
             </listitem>
 
             <listitem>
               <para>
-                <literal>max_binlog_size</literal>, if
-                <literal>max_relay_log_size</literal> = 0
+                If the value of <literal>max_relay_log_size</literal> is
+                0, <literal>max_binlog_size</literal> determines the
+                maximum relay log file size.
               </para>
             </listitem>
 
@@ -886,23 +888,30 @@
         A slave replication server creates two additional small files in
         the data directory. These <emphasis>status files</emphasis> are
         named <filename>master.info</filename> and
-        <filename>relay-log.info</filename> by default. They contain
-        information like that shown in the output of the <literal>SHOW
-        SLAVE STATUS</literal> statement (see
-        <xref linkend="replication-slave-sql"/>, for a description of
-        this statement). As disk files, they survive a slave server's
-        shutdown. The next time the slave starts up, it reads these
-        files to determine how far it has proceeded in reading binary
-        logs from the master and in processing its own relay logs.
+        <filename>relay-log.info</filename> by default. Their names can
+        be changed by using the <option>--master-info-file</option> and
+        <option>--relay-log-info-file</option> options. See
+        <xref linkend="replication-options"/>.
       </para>
 
       <para>
-        The <filename>master.info</filename> file is updated by the I/O
-        thread. The correspondence between the lines in the file and the
-        columns displayed by <literal>SHOW SLAVE STATUS</literal> is as
-        follows:
+        The two status files contain information like that shown in the
+        output of the <literal>SHOW SLAVE STATUS</literal> statement,
+        which is discussed in <xref linkend="replication-slave-sql"/>.
+        Because the status files are stored on disk, they survive a
+        slave server's shutdown. The next time the slave starts up, it
+        reads the two files to determine how far it has proceeded in
+        reading binary logs from the master and in processing its own
+        relay logs.
       </para>
 
+      <para>
+        The I/O thread updates the <filename>master.info</filename>
+        file. The following table shows the correspondence between the
+        lines in the file and the columns displayed by <literal>SHOW
+        SLAVE STATUS</literal>.
+      </para>
+
       <informaltable>
         <tgroup cols="2">
           <colspec colwidth="15*"/>
@@ -973,10 +982,10 @@
       </informaltable>
 
       <para>
-        The <filename>relay-log.info</filename> file is updated by the
-        SQL thread. The correspondence between the lines in the file and
-        the columns displayed by <literal>SHOW SLAVE STATUS</literal> is
-        shown here:
+        The SQL thread updates the <filename>relay-log.info</filename>
+        file. The following table shows the correspondence between the
+        lines in the file and the columns displayed by <literal>SHOW
+        SLAVE STATUS</literal>.
       </para>
 
       <informaltable>
@@ -1016,7 +1025,7 @@
 
       <para>
         When you back up the slave's data, you should back up these two
-        small files as well, along with the relay log files. They are
+        status files as well, along with the relay log files. They are
         needed to resume replication after you restore the slave's data.
         If you lose the relay logs but still have the
         <filename>relay-log.info</filename> file, you can check it to
@@ -1036,9 +1045,9 @@
         these files to resume replication of any interrupted
         <literal>LOAD DATA INFILE</literal> operations. The directory
         location is specified using the
-        <option>--slave-load-tmpdir</option> option. Its default value,
-        if not specified, is the value of the <literal>tmpdir</literal>
-        variable.
+        <option>--slave-load-tmpdir</option> option. If this option is
+        not specified, the directory location is the value of the
+        <literal>tmpdir</literal> system variable.
       </para>
 
     </section>

Modified: trunk/refman-5.1/sql-syntax.xml
===================================================================
--- trunk/refman-5.1/sql-syntax.xml	2006-01-29 21:32:47 UTC (rev 1109)
+++ trunk/refman-5.1/sql-syntax.xml	2006-01-29 22:54:16 UTC (rev 1110)
@@ -16725,7 +16725,10 @@
               The most common <literal>State</literal> values are
               described in the rest of this section. Most of the other
               <literal>State</literal> values are useful only for
-              finding bugs in the server.
+              finding bugs in the server. See also
+              <xref linkend="replication-implementation-details"/>, for
+              additional information about process states for
+              replication servers.
             </para>
 
             <para>

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