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
因为它是驱动复制进程, 在本报告中提供很少的信息。