Author: jstephens
Date: 2008-02-08 11:18:40 +0100 (Fri, 08 Feb 2008)
New Revision: 9745
Log:
More info about Seconds_Behind_Master - when "0" might not mean that the
slave has completely caught up; transient values (adixon/from dev
comments in sql/slave.cc)
Brought 4.1 description more into line with that given in other versions
Modified:
trunk/refman-4.1/dba-core.xml
trunk/refman-4.1/replication.xml
trunk/refman-5.0/replication-configuration.xml
trunk/refman-5.1/replication-configuration.xml
trunk/refman-6.0/replication-configuration.xml
Modified: trunk/refman-4.1/dba-core.xml
===================================================================
--- trunk/refman-4.1/dba-core.xml 2008-02-08 06:46:48 UTC (rev 9744)
+++ trunk/refman-4.1/dba-core.xml 2008-02-08 10:18:40 UTC (rev 9745)
Changed blocks: 1, Lines Added: 2, Lines Deleted: 1; 551 bytes
@@ -10,7 +10,8 @@
<remark role="dynamic-dependency-list"/>
&eol-warning;
- <para>
+
+ <para>
MySQL Server (<command>mysqld</command>) is the main program that
does most of the work in a MySQL installation. This section provides
an overview of MySQL Server and covers topics that deal with
Modified: trunk/refman-4.1/replication.xml
===================================================================
--- trunk/refman-4.1/replication.xml 2008-02-08 06:46:48 UTC (rev 9744)
+++ trunk/refman-4.1/replication.xml 2008-02-08 10:18:40 UTC (rev 9745)
Changed blocks: 1, Lines Added: 34, Lines Deleted: 2; 2489 bytes
@@ -4250,8 +4250,40 @@
<para>
<emphasis role="bold">A</emphasis>: If the slave is 4.1.1 or
newer, read the <literal>Seconds_Behind_Master</literal> column in
- <literal>SHOW SLAVE STATUS</literal>. For older versions, the
- following applies. This is possible only if <literal>SHOW SLAVE
+ <literal>SHOW SLAVE STATUS</literal>, which shows the number of
+ seconds that the slave SQL thread is behind processing the master
+ binary log. A high number (or an increasing one) can indicate that
+ the slave is unable to cope with the large number of queries from
+ the master.
+ </para>
+
+ <para>
+ A value of 0 for <literal>Seconds_Behind_Master</literal> can
+ usually be interpreted as meaning that the slave has caught up
+ with the master, but there are some cases where this is not
+ strictly true. For example, this can occur if the network
+ connection between master and slave is broken but the slave I/O
+ thread has not yet noticed this — that is,
+ <literal>slave_net_timeout</literal> has not yet elapsed.
+ </para>
+
+ <para>
+ It is also possible that transient values for
+ <literal>Seconds_Behind_Master</literal> may not reflect the
+ situation accurately. When the slave SQL thread has caught up on
+ I/O, <literal>Seconds_Behind_Master</literal> displays 0; but when
+ the slave I/O thread is still queuing up a new event,
+ <literal>Seconds_Behind_Master</literal> may show a large value
+ until the SQL thread finishes executing the new event. This is
+ especially likely when the events have old timestamps; in such
+ cases, if you execute <literal>SHOW SLAVE STATUS</literal> several
+ times in a relatively short peiod, you may see this value change
+ back and forth repeatedly between 0 and a relatively large value.
+ </para>
+
+ <para>
+ For versions of MySQL prior to 4.1.1, it is possible to determine
+ how far behind the slave is only if <literal>SHOW SLAVE
STATUS</literal> on the slave shows that the SQL thread is running
(or for MySQL 3.23, that the slave thread is running), and that
the thread has executed at least one event from the master. See
Modified: trunk/refman-5.0/replication-configuration.xml
===================================================================
--- trunk/refman-5.0/replication-configuration.xml 2008-02-08 06:46:48 UTC (rev 9744)
+++ trunk/refman-5.0/replication-configuration.xml 2008-02-08 10:18:40 UTC (rev 9745)
Changed blocks: 1, Lines Added: 26, Lines Deleted: 0; 1919 bytes
@@ -2839,6 +2839,32 @@
increasing one) can indicate that the slave is unable to
cope with the large number of queries from the master.
</para>
+
+ <para>
+ A value of 0 for <literal>Seconds_Behind_Master</literal>
+ can usually be interpreted as meaning that the slave has
+ caught up with the master, but there are some cases where
+ this is not strictly true. For example, this can occur if
+ the network connection between master and slave is broken
+ but the slave I/O thread has not yet noticed this —
+ that is, <literal>slave_net_timeout</literal> has not yet
+ elapsed.
+ </para>
+
+ <para>
+ It is also possible that transient values for
+ <literal>Seconds_Behind_Master</literal> may not reflect the
+ situation accurately. When the slave SQL thread has caught
+ up on I/O, <literal>Seconds_Behind_Master</literal> displays
+ 0; but when the slave I/O thread is still queuing up a new
+ event, <literal>Seconds_Behind_Master</literal> may show a
+ large value until the SQL thread finishes executing the new
+ event. This is especially likely when the events have old
+ timestamps; in such cases, if you execute <literal>SHOW
+ SLAVE STATUS</literal> several times in a relatively short
+ peiod, you may see this value change back and forth
+ repeatedly between 0 and a relatively large value.
+ </para>
</listitem>
</itemizedlist>
Modified: trunk/refman-5.1/replication-configuration.xml
===================================================================
--- trunk/refman-5.1/replication-configuration.xml 2008-02-08 06:46:48 UTC (rev 9744)
+++ trunk/refman-5.1/replication-configuration.xml 2008-02-08 10:18:40 UTC (rev 9745)
Changed blocks: 1, Lines Added: 26, Lines Deleted: 0; 1919 bytes
@@ -3531,6 +3531,32 @@
increasing one) can indicate that the slave is unable to
cope with the large number of queries from the master.
</para>
+
+ <para>
+ A value of 0 for <literal>Seconds_Behind_Master</literal>
+ can usually be interpreted as meaning that the slave has
+ caught up with the master, but there are some cases where
+ this is not strictly true. For example, this can occur if
+ the network connection between master and slave is broken
+ but the slave I/O thread has not yet noticed this —
+ that is, <literal>slave_net_timeout</literal> has not yet
+ elapsed.
+ </para>
+
+ <para>
+ It is also possible that transient values for
+ <literal>Seconds_Behind_Master</literal> may not reflect the
+ situation accurately. When the slave SQL thread has caught
+ up on I/O, <literal>Seconds_Behind_Master</literal> displays
+ 0; but when the slave I/O thread is still queuing up a new
+ event, <literal>Seconds_Behind_Master</literal> may show a
+ large value until the SQL thread finishes executing the new
+ event. This is especially likely when the events have old
+ timestamps; in such cases, if you execute <literal>SHOW
+ SLAVE STATUS</literal> several times in a relatively short
+ peiod, you may see this value change back and forth
+ repeatedly between 0 and a relatively large value.
+ </para>
</listitem>
</itemizedlist>
Modified: trunk/refman-6.0/replication-configuration.xml
===================================================================
--- trunk/refman-6.0/replication-configuration.xml 2008-02-08 06:46:48 UTC (rev 9744)
+++ trunk/refman-6.0/replication-configuration.xml 2008-02-08 10:18:40 UTC (rev 9745)
Changed blocks: 1, Lines Added: 26, Lines Deleted: 0; 1919 bytes
@@ -3251,6 +3251,32 @@
increasing one) can indicate that the slave is unable to
cope with the large number of queries from the master.
</para>
+
+ <para>
+ A value of 0 for <literal>Seconds_Behind_Master</literal>
+ can usually be interpreted as meaning that the slave has
+ caught up with the master, but there are some cases where
+ this is not strictly true. For example, this can occur if
+ the network connection between master and slave is broken
+ but the slave I/O thread has not yet noticed this —
+ that is, <literal>slave_net_timeout</literal> has not yet
+ elapsed.
+ </para>
+
+ <para>
+ It is also possible that transient values for
+ <literal>Seconds_Behind_Master</literal> may not reflect the
+ situation accurately. When the slave SQL thread has caught
+ up on I/O, <literal>Seconds_Behind_Master</literal> displays
+ 0; but when the slave I/O thread is still queuing up a new
+ event, <literal>Seconds_Behind_Master</literal> may show a
+ large value until the SQL thread finishes executing the new
+ event. This is especially likely when the events have old
+ timestamps; in such cases, if you execute <literal>SHOW
+ SLAVE STATUS</literal> several times in a relatively short
+ peiod, you may see this value change back and forth
+ repeatedly between 0 and a relatively large value.
+ </para>
</listitem>
</itemizedlist>
| Thread |
|---|
| • svn commit - mysqldoc@docsrva: r9745 - in trunk: refman-4.1 refman-5.0 refman-5.1 refman-6.0 | jon | 8 Feb |
