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> <userinput>mysqlbinlog -j pos_from_slave_status \</userinput>
- <userinput><replaceable>/path/to/log_from_slave_status</replaceable> | head</userinput>
+shell> <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> <userinput>mysqlbinlog -j pos_from_slave_status \</userinput>
- <userinput><replaceable>/path/to/log_from_slave_status</replaceable> | head</userinput>
+shell> <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> <userinput>mysqlbinlog -j pos_from_slave_status \</userinput>
- <userinput><replaceable>/path/to/log_from_slave_status</replaceable> | head</userinput>
+shell> <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.1 | paul | 30 Jan |
