A copy of the State field of the
SHOW PROCESSLIST output for
the slave I/O thread. This tells you what the thread is
doing: trying to connect to the master, waiting for events
from the master, reconnecting to the master, and so on. For
a listing of possible states, see
Section 8.14.6, “Replication Slave I/O Thread States”. For versions of
MySQL prior to 5.0.12, it is necessary to check this field
for connection problems. In those versions, the thread could
be running while unsuccessfully trying to connect to the
master; only this field makes you aware of the problem. The
state of the SQL thread is not copied because it is simpler.
If it is running, there is no problem; if it is not, you can
find the error in the Last_Error field
(described later).

The name of the master binary log file from which the I/O
thread is currently reading.

Read_Master_Log_Pos

The position in the current master binary log file up to
which the I/O thread has read.

Relay_Log_File

The name of the relay log file from which the SQL thread is
currently reading and executing.

Relay_Log_Pos

The position in the current relay log file up to which the
SQL thread has read and executed.

Relay_Master_Log_File

The name of the master binary log file containing the most
recent event executed by the SQL thread.

Slave_IO_Running

Whether the I/O thread is started and has connected
successfully to the master. Internally, the state of this
thread is represented by one of the following three values:

MYSQL_SLAVE_NOT_RUN.
The slave I/O thread is not running. For this state,
Slave_IO_Running is
No.

MYSQL_SLAVE_RUN_NOT_CONNECT.
The slave I/O thread is running, but is not connected
to a replication master. For this state,
Slave_IO_Running depends on the
server version as shown in the following table.

MySQL Version

Slave_IO_Running

4.1 (4.1.13 and earlier); 5.0 (5.0.11 and earlier)

Yes

4.1 (4.1.14 and later); 5.0 (5.0.12 and later)

No

5.1

No

5.5

Connecting

MYSQL_SLAVE_RUN_CONNECT.
The slave I/O thread is running, and is connected to a
replication master. For this state,
Slave_IO_Running is
Yes.

The error number and error message returned by the most
recently executed statement. An error number of 0 and
message of the empty string mean “no error.” If
the Last_Error value is not empty, it
also appears as a message in the slave's error log. For
example:

The message indicates that the table z
existed on the master and was dropped there, but it did not
exist on the slave, so DROP
TABLE failed on the slave. (This might occur, for
example, if you forget to copy the table to the slave when
setting up replication.)

Note

When the slave SQL thread receives an error, it reports
the error first, then stops the SQL thread. This means
that there is a small window of time during which
SHOW SLAVE STATUS shows a
nonzero value for Last_Errno even
though Slave_SQL_Running still displays
Yes.

The position in the current master binary log file to which
the SQL thread has read and executed, marking the start of
the next transaction or event to be processed. You can use
this value with the CHANGE MASTER
TO statement's
MASTER_LOG_POS option when starting a new
slave from an existing slave, so that the new slave reads
from this point. The coordinates given by
(Relay_Master_Log_File,
Exec_Master_Log_Pos) in the master's
binary log correspond to the coordinates given by
(Relay_Log_File,
Relay_Log_Pos) in the relay log.

Relay_Log_Space

The total combined size of all existing relay log files.

Until_Condition,
Until_Log_File,
Until_Log_Pos

The values specified in the UNTIL clause
of the START SLAVE statement.

Until_Condition has these values:

None if no UNTIL
clause was specified

Master if the slave is reading until
a given position in the master's binary log

Relay if the slave is reading until a
given position in its relay log

Until_Log_File and
Until_Log_Pos indicate the log file name
and position that define the coordinates at which the SQL
thread stops executing.

When the slave is actively processing updates, this
field shows the difference between the current timestamp
on the slave and the original timestamp logged on the
master for the event currently being processed on the
slave.

When no event is currently being processed on the slave,
this value is 0.

In essence, this field measures the time difference in
seconds between the slave SQL thread and the slave I/O
thread. If the network connection between master and slave
is fast, the slave I/O thread is very close to the master,
so this field is a good approximation of how late the slave
SQL thread is compared to the master. If the network is
slow, this is not a good approximation;
the slave SQL thread may quite often be caught up with the
slow-reading slave I/O thread, so
Seconds_Behind_Master often shows a value
of 0, even if the I/O thread is late compared to the master.
In other words, this column is useful only for
fast networks.

This time difference computation works even if the master
and slave do not have identical clock times, provided that
the difference, computed when the slave I/O thread starts,
remains constant from then on. Any changes—including
NTP updates—can lead to clock skews that can make
calculation of Seconds_Behind_Master less
reliable.

This field is NULL (undefined or unknown)
if the slave SQL thread is not running, or if the slave I/O
thread is not running or is not connected to the master. For
example, if the slave I/O thread is running but is not
connected to the master and is sleeping for the number of
seconds given by the CHANGE MASTER
TO statement or
--master-connect-retry option
(default 60) before reconnecting, the value is
NULL. This is because the slave cannot
know what the master is doing, and so cannot say reliably
how late it is.

The value of Seconds_Behind_Master is
based on the timestamps stored in events, which are
preserved through replication. This means that if a master
M1 is itself a slave of M0, any event from M1's binary log
that originates from M0's binary log has M0's timestamp for
that event. This enables MySQL to replicate
TIMESTAMP successfully.
However, the problem for
Seconds_Behind_Master is that if M1 also
receives direct updates from clients, the
Seconds_Behind_Master value randomly
fluctuates because sometimes the last event from M1
originates from M0 and sometimes is the result of a direct
update on M1.

User Comments

Here's a quick php code snippet to read your master.info and relay-log.info and generate a change master sql command from it. Very useful if you get corrupted relay logs or have had to purge your relay logs, etc.