17.1.5.1 Checking Replication Status 检查复制状态:

17.1.5 Common Replication Administration Tasks 通用的复制任务:

17.1.5.1 Checking Replication Status 检查 复制状态

17.1.5.2 Pausing Replication on the Slave 暂停复制

一旦复制已经开始 ,它应该执行不于鏊太多的常规管理。根据你的配置环境,你将要

检查复制状态,每天,甚至更加频繁。

17.1.5.1 Checking Replication Status 检查复制状态:

在管理复制过程中最常见的任务是确保复制是正在发生, 没有错误在slave和master之间。

主要的语句是SHOW SLAVE STATUS,你必须在每个slave上执行:

mysql> SHOW SLAVE STATUSG
***************** 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
Master_SSL_Verify_Server_Cert: No
Last_IO_Errno: 0
Last_IO_Error:
Last_SQL_Errno: 0
Last_SQL_Error:
Replicate_Ignore_Server_Ids: 0

状态报告的关键字如下:

Slave_IO_State：当前slave的状态

Slave_IO_State: Waiting for master to send event

Slave_IO_Running: I/O thread 读取master的binary log 正在运行,你希望是YES,

除非你没有启动复制或者 执行了STOP SLAVE

Slave_IO_Running: Yes

Slave_SQL_Running: SQL Thread执行 relay log 中的events 在运行,必须是YES

Slave_SQL_Running: Yes

Last_IO_Error, Last_SQL_Error: I/O和SQL threads 处理relay log 产生的错误,应该显示为空白,表示没有错误。

Seconds_Behind_Master: slave SQL thread 是落后 master binary log 多少秒。

一个大的数字表明slave不能及时处理master 的events .

Seconds_Behind_Master为0通常可以解释为slave可以追赶上master, 但在某些情况下,

这是不完全正确的。例如, 如果网络连接在master和slave 之间断开 但是slave I/O thread 没有注意到

, slave_net_timeout 尚未逝去。

也有可能 Seconds_Behind_Master的瞬时值不能反应正确的情况。

当slave SQL thread 已经赶上了I/O,Seconds_Behind_Master displays 0;

但是当slave I/O thread 仍旧是排队一个新的events,

Seconds_Behind_Master 可能显示一个大的值直到SQL thread 完成执行新的events.

这是可能的 当evnets 有旧的时间戳, 在这种情况下,如果执行SHOW SLAVE STATUS多次在相对较短的时间内，你可以看到这个值

的变化来回反复0个比较大的值之间。

几个领域提供的信息关于slave进程从master 的binary log 读取events和在relay log中处理它们:

(Master_Log_file, Read_Master_Log_Pos): 在master binary log 中的坐标表明

slave从master 的binary log 已经读取的events.

(Relay_Master_Log_File, Exec_Master_Log_Pos): master binary log 中的坐标表明

SQL的SQL thread 已经从接到到的日志已经被执行的情况

(Relay_Log_File, Relay_Log_Pos): slave relay log 中的坐标表明 slave SQL thread 已经执行relay log的情况。

这些对应去之前的坐标,但是现实在slave relay log 坐标而不是Master binary log 坐标。

在master上, 你可以检查连接的slave的状态使用SHOW PROCESSLIST 来检查运行的列表,

Slave 连接有Binlog Dump 在命令行域:

mysql> 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

因为它是驱动复制进程, 在本报告中提供很少的信息。