The most common task when managing a replication process is to
ensure that replication is taking place and that there have been
no errors between the slave and the master. The primary
statement for this is
STATUS, which you must execute on each slave:
SHOW SLAVE STATUS\G*************************** 1. row *************************** Slave_IO_State: Waiting for master to send event Master_Host: master1 Master_User: root Master_Port: 3306 Connect_Retry: 60 Master_Log_File: mysql-bin.000004 Read_Master_Log_Pos: 931 Relay_Log_File: slave1-relay-bin.000056 Relay_Log_Pos: 950 Relay_Master_Log_File: mysql-bin.000004 Slave_IO_Running: Yes Slave_SQL_Running: Yes Replicate_Do_DB: Replicate_Ignore_DB: Replicate_Do_Table: Replicate_Ignore_Table: Replicate_Wild_Do_Table: Replicate_Wild_Ignore_Table: Last_Errno: 0 Last_Error: Skip_Counter: 0 Exec_Master_Log_Pos: 931 Relay_Log_Space: 1365 Until_Condition: None Until_Log_File: Until_Log_Pos: 0 Master_SSL_Allowed: No Master_SSL_CA_File: Master_SSL_CA_Path: Master_SSL_Cert: Master_SSL_Cipher: Master_SSL_Key: Seconds_Behind_Master: 0
The key fields from the status report to examine are:
Slave_IO_State: The current status of the slave. See Section 8.14.6, “Replication Slave I/O Thread States”, and Section 8.14.7, “Replication Slave SQL Thread States”, for more information.
Slave_IO_Running: Whether the I/O thread for reading the master's binary log is running. Normally, you want this to be
Yesunless you have not yet started replication or have explicitly stopped it with
Slave_SQL_Running: Whether the SQL thread for executing events in the relay log is running. As with the I/O thread, this should normally be
Last_Error: The last error registered when processing the relay log. Ideally this should be blank, indicating no error.
Seconds_Behind_Master: 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 handle events from the master in a timely fashion.
A value of 0 for
Seconds_Behind_Mastercan 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,
slave_net_timeouthas not yet elapsed.
It is also possible that transient values for
Seconds_Behind_Mastermay not reflect the situation accurately. When the slave SQL thread has caught up on I/O,
Seconds_Behind_Masterdisplays 0; but when the slave I/O thread is still queuing up a new event,
Seconds_Behind_Mastermay 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
SHOW SLAVE STATUSseveral times in a relatively short period, you may see this value change back and forth repeatedly between 0 and a relatively large value.
Several pairs of fields provide information about the progress of the slave in reading events from the master binary log and processing them in the relay log:
Read_Master_Log_Pos): Coordinates in the master binary log indicating how far the slave I/O thread has read events from that log.
Exec_Master_Log_Pos): Coordinates in the master binary log indicating how far the slave SQL thread has executed events received from that log.
Relay_Log_Pos): Coordinates in the slave relay log indicating how far the slave SQL thread has executed the relay log. These correspond to the preceding coordinates, but are expressed in slave relay log coordinates rather than master binary log coordinates.
On the master, you can check the status of connected slaves
SHOW PROCESSLIST to examine
the list of running processes. Slave connections have
Binlog Dump in the
SHOW PROCESSLIST \G;*************************** 4. row *************************** Id: 10 User: root Host: slave1:58371 db: NULL Command: Binlog Dump Time: 777 State: Has sent all binlog to slave; waiting for binlog to be updated Info: NULL
Because it is the slave that drives the replication process, very little information is available in this report.
For slaves that were started with the
--report-host option and are
connected to the master, the
HOSTS statement on the master shows basic information
about the slaves. The output includes the ID of the slave
server, the value of the
--report-host option, the
connecting port, and master ID:
SHOW SLAVE HOSTS;+-----------+--------+------+-------------------+-----------+ | Server_id | Host | Port | Rpl_recovery_rank | Master_id | +-----------+--------+------+-------------------+-----------+ | 10 | slave1 | 3306 | 0 | 1 | +-----------+--------+------+-------------------+-----------+ 1 row in set (0.00 sec)