List:Commits« Previous MessageNext Message »
From:paul Date:January 30 2006 4:32am
Subject:svn commit - mysqldoc@docsrva: r1120 - in trunk: . refman-4.1 refman-5.0 refman-5.1
View as plain text  
Author: paul
Date: 2006-01-30 05:32:31 +0100 (Mon, 30 Jan 2006)
New Revision: 1120

Log:
 r6890@frost:  paul | 2006-01-29 22:31:26 -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:6889
bf112a9c-6c03-0410-a055-ad865cd57414:/mysqldoc-local/mysqldoc/trunk:2588
   + b5ec3a16-e900-0410-9ad2-d183a3acac99:/mysqldoc-local/mysqldoc/trunk:6890
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-30 04:32:17 UTC (rev 1119)
+++ trunk/refman-4.1/replication.xml	2006-01-30 04:32:31 UTC (rev 1120)
@@ -4249,49 +4249,54 @@
 
     <para>
       If you have followed the instructions, and your replication setup
-      is not working, first check the following:
+      is not working, the first thing to do is <emphasis>check the error
+      log for messages</emphasis>. Many users have lost time by not
+      doing this soon enough after encountering problems.
     </para>
 
+    <para>
+      If you cannot tell from the error log what the problem was, try
+      the following techniques:
+    </para>
+
     <itemizedlist>
 
       <listitem>
         <para>
-          <emphasis role="bold">Check the error log for
-          messages</emphasis>. Many users have lost time by not doing
-          this early enough after encountering problems.
+          Verify that the master has binary logging enabled by issuing a
+          <literal>SHOW MASTER STATUS</literal> statement. If logging is
+          enabled, <literal>Position</literal> is non-zero. If binary
+          logging is not enabled, verify that you are running the master
+          with the <option>--log-bin</option> and
+          <option>--server-id</option> options.
         </para>
       </listitem>
 
       <listitem>
         <para>
-          Is the master logging to the binary log? Check with
-          <literal>SHOW MASTER STATUS</literal>. If it is,
-          <literal>Position</literal> is non-zero. If not, verify that
-          you are running the master with the <literal>log-bin</literal>
-          and <literal>server-id</literal> options.
-        </para>
-      </listitem>
-
-      <listitem>
-        <para>
-          Is the slave running? Use <literal>SHOW SLAVE STATUS</literal>
-          to check whether the <literal>Slave_IO_Running</literal> and
+          Verify that the slave is running. Use <literal>SHOW SLAVE
+          STATUS</literal> to check whether the
+          <literal>Slave_IO_Running</literal> and
           <literal>Slave_SQL_Running</literal> values are both
           <literal>Yes</literal>. If not, verify the options that were
-          used when starting the slave server.
+          used when starting the slave server. For example,
+          <option>--skip-slave-start</option> prevents the slave threads
+          from starting until you issue a <literal>START SLAVE</literal>
+          statement.
         </para>
       </listitem>
 
       <listitem>
         <para>
-          If the slave is running, did it establish a connection to the
-          master? Use <literal>SHOW PROCESSLIST</literal>, find the I/O
-          and SQL threads and check their <literal>State</literal>
-          column to see how they display. See
+          If the slave is running, check whether it established a
+          connection to the master. Use <literal>SHOW
+          PROCESSLIST</literal>, find the I/O and SQL threads and check
+          their <literal>State</literal> column to see what they
+          display. See
           <xref linkend="replication-implementation-details"/>. If the
           I/O thread state says <literal>Connecting to master</literal>,
           verify the privileges for the replication user on the master,
-          master hostname, your DNS setup, whether the master is
+          the master hostname, your DNS setup, whether the master is
           actually running, and whether it is reachable from the slave.
         </para>
       </listitem>
@@ -4302,9 +4307,9 @@
           reason usually is that some statement that succeeded on the
           master failed on the slave. This should never happen if you
           have taken a proper snapshot of the master, and never modified
-          the data on the slave outside of the slave thread. If it does,
-          it is a bug or you have encountered one of the known
-          replication limitations described in
+          the data on the slave outside of the slave thread. If the
+          slave stops unexpectedly, it is a bug or you have encountered
+          one of the known replication limitations described in
           <xref linkend="replication-features"/>. If it is a bug, see
           <xref linkend="replication-bugs"/>, for instructions on how to
           report it.
@@ -4314,19 +4319,19 @@
       <listitem>
         <para>
           If a statement that succeeded on the master refuses to run on
-          the slave, and it is not feasible to do a full database
-          resynchronization (that is, to delete the slave's database and
-          copy a new snapshot from the master), try the following:
+          the slave, try the following procedure if it is not feasible
+          to do a full database resynchronization by deleting the
+          slave's databases and copying a new snapshot from the master:
         </para>
 
         <orderedlist>
 
           <listitem>
             <para>
-              Determine whether the slave's table is different from the
-              master's. Try to understand how this happened. Then make
-              the slave's table identical to the master's and run
-              <literal>START SLAVE</literal>.
+              Determine whether the affected table on the slave is
+              different from the master table. Try to understand how
+              this happened. Then make the slave's table identical to
+              the master's and run <literal>START SLAVE</literal>.
             </para>
           </listitem>
 
@@ -4368,9 +4373,10 @@
               synchronized with the master, and that no one has updated
               the tables involved outside of the slave thread, then
               presumably the discrepancy is the result of a bug. If you
-              are running the most recent version, please report the
-              problem. If you are running an older version of MySQL, try
-              upgrading to the latest production release.
+              are running the most recent version of MySQL, please
+              report the problem. If you are running an older version,
+              try upgrading to the latest production release to
+              determine whether the problem persists.
             </para>
           </listitem>
 
@@ -4395,10 +4401,10 @@
 
     <para>
       If you have a repeatable test case that demonstrates the bug,
-      please enter it into our bugs database at
-      <ulink url="http://bugs.mysql.com/"/>. If you have a
+      please enter it into our bugs database using the instructions
+      given in <xref linkend="bug-reports"/>. If you have a
       <quote>phantom</quote> problem (one that you cannot duplicate at
-      will), then use the following procedure:
+      will), use the following procedure:
     </para>
 
     <orderedlist>
@@ -4411,7 +4417,7 @@
           updates. In this case, the slave thread stops and waits for
           you to clean up the tables manually to bring them into
           synchrony. <emphasis>This is not a replication problem. It is
-          a problem with outside interference causing replication to
+          a problem of outside interference causing replication to
           fail.</emphasis>
         </para>
       </listitem>
@@ -4457,7 +4463,7 @@
           <listitem>
             <para>
               The output of <literal>SHOW SLAVE STATUS</literal> from
-              the master at the time you discovered the problem
+              the slave at the time you discovered the problem
             </para>
           </listitem>
 
@@ -4473,24 +4479,27 @@
       <listitem>
         <para>
           Use <command>mysqlbinlog</command> to examine the binary logs.
-          The following should be helpful to find the problem query, for
-          example:
+          The following should be helpful to find the problem query.
+          <replaceable>log_pos</replaceable> and
+          <replaceable>log_file</replaceable> are the
+          <literal>Master_Log_File</literal> and
+          <literal>Read_Master_Log_Pos</literal> values from
+          <literal>SHOW SLAVE STATUS</literal>.
         </para>
 
 <programlisting>
-shell&gt; <userinput>mysqlbinlog -j pos_from_slave_status \</userinput>
-           <userinput><replaceable>/path/to/log_from_slave_status</replaceable> | head</userinput>
+shell&gt; <userinput>mysqlbinlog -j <replaceable>log_pos</replaceable> \</userinput>
+           <userinput><replaceable>log_file</replaceable> | head</userinput>
 </programlisting>
       </listitem>
 
     </orderedlist>
 
     <para>
-      Once you have collected the evidence for the phantom problem, try
-      hard to isolate it into a separate test case first. Then enter the
-      problem into our bugs database at
-      <ulink url="http://bugs.mysql.com/"/> with as much information as
-      possible.
+      After you have collected the evidence for the problem, try to
+      isolate it as a separate test case first. Then enter the problem
+      with as much information as possible into our bugs database using
+      the instructions at <xref linkend="bug-reports"/>.
     </para>
 
   </section>

Modified: trunk/refman-5.0/replication.xml
===================================================================
--- trunk/refman-5.0/replication.xml	2006-01-30 04:32:17 UTC (rev 1119)
+++ trunk/refman-5.0/replication.xml	2006-01-30 04:32:31 UTC (rev 1120)
@@ -4140,49 +4140,54 @@
 
     <para>
       If you have followed the instructions, and your replication setup
-      is not working, first check the following:
+      is not working, the first thing to do is <emphasis>check the error
+      log for messages</emphasis>. Many users have lost time by not
+      doing this soon enough after encountering problems.
     </para>
 
+    <para>
+      If you cannot tell from the error log what the problem was, try
+      the following techniques:
+    </para>
+
     <itemizedlist>
 
       <listitem>
         <para>
-          <emphasis role="bold">Check the error log for
-          messages</emphasis>. Many users have lost time by not doing
-          this early enough after encountering problems.
+          Verify that the master has binary logging enabled by issuing a
+          <literal>SHOW MASTER STATUS</literal> statement. If logging is
+          enabled, <literal>Position</literal> is non-zero. If binary
+          logging is not enabled, verify that you are running the master
+          with the <option>--log-bin</option> and
+          <option>--server-id</option> options.
         </para>
       </listitem>
 
       <listitem>
         <para>
-          Is the master logging to the binary log? Check with
-          <literal>SHOW MASTER STATUS</literal>. If it is,
-          <literal>Position</literal> is non-zero. If not, verify that
-          you are running the master with the <literal>log-bin</literal>
-          and <literal>server-id</literal> options.
-        </para>
-      </listitem>
-
-      <listitem>
-        <para>
-          Is the slave running? Use <literal>SHOW SLAVE STATUS</literal>
-          to check whether the <literal>Slave_IO_Running</literal> and
+          Verify that the slave is running. Use <literal>SHOW SLAVE
+          STATUS</literal> to check whether the
+          <literal>Slave_IO_Running</literal> and
           <literal>Slave_SQL_Running</literal> values are both
           <literal>Yes</literal>. If not, verify the options that were
-          used when starting the slave server.
+          used when starting the slave server. For example,
+          <option>--skip-slave-start</option> prevents the slave threads
+          from starting until you issue a <literal>START SLAVE</literal>
+          statement.
         </para>
       </listitem>
 
       <listitem>
         <para>
-          If the slave is running, did it establish a connection to the
-          master? Use <literal>SHOW PROCESSLIST</literal>, find the I/O
-          and SQL threads and check their <literal>State</literal>
-          column to see how they display. See
+          If the slave is running, check whether it established a
+          connection to the master. Use <literal>SHOW
+          PROCESSLIST</literal>, find the I/O and SQL threads and check
+          their <literal>State</literal> column to see what they
+          display. See
           <xref linkend="replication-implementation-details"/>. If the
           I/O thread state says <literal>Connecting to master</literal>,
           verify the privileges for the replication user on the master,
-          master hostname, your DNS setup, whether the master is
+          the master hostname, your DNS setup, whether the master is
           actually running, and whether it is reachable from the slave.
         </para>
       </listitem>
@@ -4193,9 +4198,9 @@
           reason usually is that some statement that succeeded on the
           master failed on the slave. This should never happen if you
           have taken a proper snapshot of the master, and never modified
-          the data on the slave outside of the slave thread. If it does,
-          it is a bug or you have encountered one of the known
-          replication limitations described in
+          the data on the slave outside of the slave thread. If the
+          slave stops unexpectedly, it is a bug or you have encountered
+          one of the known replication limitations described in
           <xref linkend="replication-features"/>. If it is a bug, see
           <xref linkend="replication-bugs"/>, for instructions on how to
           report it.
@@ -4205,19 +4210,19 @@
       <listitem>
         <para>
           If a statement that succeeded on the master refuses to run on
-          the slave, and it is not feasible to do a full database
-          resynchronization (that is, to delete the slave's database and
-          copy a new snapshot from the master), try the following:
+          the slave, try the following procedure if it is not feasible
+          to do a full database resynchronization by deleting the
+          slave's databases and copying a new snapshot from the master:
         </para>
 
         <orderedlist>
 
           <listitem>
             <para>
-              Determine whether the slave's table is different from the
-              master's. Try to understand how this happened. Then make
-              the slave's table identical to the master's and run
-              <literal>START SLAVE</literal>.
+              Determine whether the affected table on the slave is
+              different from the master table. Try to understand how
+              this happened. Then make the slave's table identical to
+              the master's and run <literal>START SLAVE</literal>.
             </para>
           </listitem>
 
@@ -4259,9 +4264,10 @@
               synchronized with the master, and that no one has updated
               the tables involved outside of the slave thread, then
               presumably the discrepancy is the result of a bug. If you
-              are running the most recent version, please report the
-              problem. If you are running an older version of MySQL, try
-              upgrading to the latest production release.
+              are running the most recent version of MySQL, please
+              report the problem. If you are running an older version,
+              try upgrading to the latest production release to
+              determine whether the problem persists.
             </para>
           </listitem>
 
@@ -4286,10 +4292,10 @@
 
     <para>
       If you have a repeatable test case that demonstrates the bug,
-      please enter it into our bugs database at
-      <ulink url="http://bugs.mysql.com/"/>. If you have a
+      please enter it into our bugs database using the instructions
+      given in <xref linkend="bug-reports"/>. If you have a
       <quote>phantom</quote> problem (one that you cannot duplicate at
-      will), then use the following procedure:
+      will), use the following procedure:
     </para>
 
     <orderedlist>
@@ -4302,7 +4308,7 @@
           updates. In this case, the slave thread stops and waits for
           you to clean up the tables manually to bring them into
           synchrony. <emphasis>This is not a replication problem. It is
-          a problem with outside interference causing replication to
+          a problem of outside interference causing replication to
           fail.</emphasis>
         </para>
       </listitem>
@@ -4348,7 +4354,7 @@
           <listitem>
             <para>
               The output of <literal>SHOW SLAVE STATUS</literal> from
-              the master at the time you discovered the problem
+              the slave at the time you discovered the problem
             </para>
           </listitem>
 
@@ -4364,23 +4370,27 @@
       <listitem>
         <para>
           Use <command>mysqlbinlog</command> to examine the binary logs.
-          The following should be helpful to find the problem query, for
-          example:
+          The following should be helpful to find the problem query.
+          <replaceable>log_pos</replaceable> and
+          <replaceable>log_file</replaceable> are the
+          <literal>Master_Log_File</literal> and
+          <literal>Read_Master_Log_Pos</literal> values from
+          <literal>SHOW SLAVE STATUS</literal>.
         </para>
 
 <programlisting>
-shell&gt; <userinput>mysqlbinlog -j pos_from_slave_status \</userinput>
-           <userinput><replaceable>/path/to/log_from_slave_status</replaceable> | head</userinput>
+shell&gt; <userinput>mysqlbinlog -j <replaceable>log_pos</replaceable> \</userinput>
+           <userinput><replaceable>log_file</replaceable> | head</userinput>
 </programlisting>
       </listitem>
 
     </orderedlist>
 
     <para>
-      Once you have collected the evidence for the problem, try to
+      After you have collected the evidence for the problem, try to
       isolate it as a separate test case first. Then enter the problem
-      into our bugs database at <ulink url="http://bugs.mysql.com/"/>
-      with as much information as possible.
+      with as much information as possible into our bugs database using
+      the instructions at <xref linkend="bug-reports"/>.
     </para>
 
   </section>

Modified: trunk/refman-5.1/replication.xml
===================================================================
--- trunk/refman-5.1/replication.xml	2006-01-30 04:32:17 UTC (rev 1119)
+++ trunk/refman-5.1/replication.xml	2006-01-30 04:32:31 UTC (rev 1120)
@@ -4665,49 +4665,54 @@
 
     <para>
       If you have followed the instructions, and your replication setup
-      is not working, first check the following:
+      is not working, the first thing to do is <emphasis>check the error
+      log for messages</emphasis>. Many users have lost time by not
+      doing this soon enough after encountering problems.
     </para>
 
+    <para>
+      If you cannot tell from the error log what the problem was, try
+      the following techniques:
+    </para>
+
     <itemizedlist>
 
       <listitem>
         <para>
-          <emphasis role="bold">Check the error log for
-          messages</emphasis>. Many users have lost time by not doing
-          this early enough after encountering problems.
+          Verify that the master has binary logging enabled by issuing a
+          <literal>SHOW MASTER STATUS</literal> statement. If logging is
+          enabled, <literal>Position</literal> is non-zero. If binary
+          logging is not enabled, verify that you are running the master
+          with the <option>--log-bin</option> and
+          <option>--server-id</option> options.
         </para>
       </listitem>
 
       <listitem>
         <para>
-          Is the master logging to the binary log? Check with
-          <literal>SHOW MASTER STATUS</literal>. If it is,
-          <literal>Position</literal> is non-zero. If not, verify that
-          you are running the master with the <literal>log-bin</literal>
-          and <literal>server-id</literal> options.
-        </para>
-      </listitem>
-
-      <listitem>
-        <para>
-          Is the slave running? Use <literal>SHOW SLAVE STATUS</literal>
-          to check whether the <literal>Slave_IO_Running</literal> and
+          Verify that the slave is running. Use <literal>SHOW SLAVE
+          STATUS</literal> to check whether the
+          <literal>Slave_IO_Running</literal> and
           <literal>Slave_SQL_Running</literal> values are both
           <literal>Yes</literal>. If not, verify the options that were
-          used when starting the slave server.
+          used when starting the slave server. For example,
+          <option>--skip-slave-start</option> prevents the slave threads
+          from starting until you issue a <literal>START SLAVE</literal>
+          statement.
         </para>
       </listitem>
 
       <listitem>
         <para>
-          If the slave is running, did it establish a connection to the
-          master? Use <literal>SHOW PROCESSLIST</literal>, find the I/O
-          and SQL threads and check their <literal>State</literal>
-          column to see how they display. See
+          If the slave is running, check whether it established a
+          connection to the master. Use <literal>SHOW
+          PROCESSLIST</literal>, find the I/O and SQL threads and check
+          their <literal>State</literal> column to see what they
+          display. See
           <xref linkend="replication-implementation-details"/>. If the
           I/O thread state says <literal>Connecting to master</literal>,
           verify the privileges for the replication user on the master,
-          master hostname, your DNS setup, whether the master is
+          the master hostname, your DNS setup, whether the master is
           actually running, and whether it is reachable from the slave.
         </para>
       </listitem>
@@ -4718,9 +4723,9 @@
           reason usually is that some statement that succeeded on the
           master failed on the slave. This should never happen if you
           have taken a proper snapshot of the master, and never modified
-          the data on the slave outside of the slave thread. If it does,
-          it is a bug or you have encountered one of the known
-          replication limitations described in
+          the data on the slave outside of the slave thread. If the
+          slave stops unexpectedly, it is a bug or you have encountered
+          one of the known replication limitations described in
           <xref linkend="replication-features"/>. If it is a bug, see
           <xref linkend="replication-bugs"/>, for instructions on how to
           report it.
@@ -4730,19 +4735,19 @@
       <listitem>
         <para>
           If a statement that succeeded on the master refuses to run on
-          the slave, and it is not feasible to do a full database
-          resynchronization (that is, to delete the slave's database and
-          copy a new snapshot from the master), try the following:
+          the slave, try the following procedure if it is not feasible
+          to do a full database resynchronization by deleting the
+          slave's databases and copying a new snapshot from the master:
         </para>
 
         <orderedlist>
 
           <listitem>
             <para>
-              Determine whether the slave's table is different from the
-              master's. Try to understand how this happened. Then make
-              the slave's table identical to the master's and run
-              <literal>START SLAVE</literal>.
+              Determine whether the affected table on the slave is
+              different from the master table. Try to understand how
+              this happened. Then make the slave's table identical to
+              the master's and run <literal>START SLAVE</literal>.
             </para>
           </listitem>
 
@@ -4784,9 +4789,10 @@
               synchronized with the master, and that no one has updated
               the tables involved outside of the slave thread, then
               presumably the discrepancy is the result of a bug. If you
-              are running the most recent version, please report the
-              problem. If you are running an older version of MySQL, try
-              upgrading to the latest production release.
+              are running the most recent version of MySQL, please
+              report the problem. If you are running an older version,
+              try upgrading to the latest production release to
+              determine whether the problem persists.
             </para>
           </listitem>
 
@@ -4811,10 +4817,10 @@
 
     <para>
       If you have a repeatable test case that demonstrates the bug,
-      please enter it into our bugs database at
-      <ulink url="http://bugs.mysql.com/"/>. If you have a
+      please enter it into our bugs database using the instructions
+      given in <xref linkend="bug-reports"/>. If you have a
       <quote>phantom</quote> problem (one that you cannot duplicate at
-      will), then use the following procedure:
+      will), use the following procedure:
     </para>
 
     <orderedlist>
@@ -4827,7 +4833,7 @@
           updates. In this case, the slave thread stops and waits for
           you to clean up the tables manually to bring them into
           synchrony. <emphasis>This is not a replication problem. It is
-          a problem with outside interference causing replication to
+          a problem of outside interference causing replication to
           fail.</emphasis>
         </para>
       </listitem>
@@ -4873,7 +4879,7 @@
           <listitem>
             <para>
               The output of <literal>SHOW SLAVE STATUS</literal> from
-              the master at the time you discovered the problem
+              the slave at the time you discovered the problem
             </para>
           </listitem>
 
@@ -4889,23 +4895,27 @@
       <listitem>
         <para>
           Use <command>mysqlbinlog</command> to examine the binary logs.
-          The following should be helpful to find the problem query, for
-          example:
+          The following should be helpful to find the problem query.
+          <replaceable>log_pos</replaceable> and
+          <replaceable>log_file</replaceable> are the
+          <literal>Master_Log_File</literal> and
+          <literal>Read_Master_Log_Pos</literal> values from
+          <literal>SHOW SLAVE STATUS</literal>.
         </para>
 
 <programlisting>
-shell&gt; <userinput>mysqlbinlog -j pos_from_slave_status \</userinput>
-           <userinput><replaceable>/path/to/log_from_slave_status</replaceable> | head</userinput>
+shell&gt; <userinput>mysqlbinlog -j <replaceable>log_pos</replaceable> \</userinput>
+           <userinput><replaceable>log_file</replaceable> | head</userinput>
 </programlisting>
       </listitem>
 
     </orderedlist>
 
     <para>
-      Once you have collected the evidence for the problem, try to
+      After you have collected the evidence for the problem, try to
       isolate it as a separate test case first. Then enter the problem
-      into our bugs database at <ulink url="http://bugs.mysql.com/"/>
-      with as much information as possible.
+      with as much information as possible into our bugs database using
+      the instructions at <xref linkend="bug-reports"/>.
     </para>
 
   </section>

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