Slave_IO_State
:
等待
master
发生事件。显示了当前slave I/O线程的状态。状态信息和使用show processlist显示的内容一样。
slave I/O线程的状态,有以下几种:
1) waiting for master update
这是connecting to master状态之前的状态
2) connecting to master
I/O线程正尝试连接到master
3) checking master version
在与master建立连接后,会出现该状态。该状态出现的时间非常短暂。
4) registering slave on master
在与master建立连接后,会出现该状态。该状态出现的时间非常短暂。
5) requesting binlog dump
在与master建立连接后,会出现该状态。该状态出现的时间非常短暂。在这个状态下,I/O线程向master发送请求,请求binlog,位置从指定的binglog 名字和binglog的position位置开始。
6) waiting to reconnect after a failed binlog dump request
如果因为连接断开,导致binglog的请求失败,I/O线程会进入睡眠状态。然后定期尝试重连。尝试重连的时间间隔,可以使用命令"change master to master_connect_trt=X;"改变。
7) reconnecting after a failed binglog dump request
I/O进程正在尝试连接master
8) waiting for master to send event
说明,已经成功连接到master,正等待二进制日志时间的到达。如果master 空闲,这个状态会持续很长时间。如果等待的时间超过了slave_net_timeout(单位是秒)的值,会出现连接超时。在这种状态下,I/O线程会人为连接失败,并开始尝试重连
9) queueing master event to the relay log
此时,I/O线程已经读取了一个event,并复制到了relay log 中。这样SQL 线程可以执行此event
10) waiting to reconnect after a failed master event read
读取时出现的错误(因为连接断开)。在尝试重连之前,I/O线程进入sleep状态,sleep的时间是master_connect_try的值(默认是60秒)
11) reconnecting after a failed master event read
I/O线程正尝试重连master。如果连接建立,状态会变成"waiting for master to send event"
12) waiting for the slave sql thread to free enough relay log space
这是因为设置了relay_log_space_limit,并且relay log的大小已经整张到了最大值。I/O线程正在等待SQL线程通过删除一些relay log,来释放relay log的空间。
13) waiting for slave mutex on exit
I/O线程停止时会出现的状态,出现的时间非常短。
Master_Host
:
当前的主服务器主机
Master_User
:
被用于连接主服务器的当前用户
Master_Port
:
当前的主服务器接口
Connect_Retry
:
master
-
connect
-
retry选项的当前值。即连接中断后,重新尝试连接的时间间隔。默认为60秒。
Master_Log_File
:
SLAVE中的I
/
O线程当前正在读取的主服务器二进制日志文件的名称
Read_Master_Log_Pos
:
在当前的主服务器二进制日志中
,
SLAVE中的I
/
O线程已经读取的位置
Relay_Log_File
:
SQL线程当前正在读取和执行的中继日志文件的名称
Relay_Log_Pos
:
在当前的中继日志中
,
SQL线程已读取和执行的位置
Relay_Master_Log_File
:
由SQL线程执行的包含多数近期事件的主服务器二进制日志文件的名称
Slave_IO_Running
:
I
/
O线程是否被启动并成功地连接到主服务器上
Slave_SQL_Running
:
SQL线程是否被启动
Replicate_Do_DB
:
replicate
-
do
-
db选项的当前值
Replicate_Ignore_DB
:
replicate
-
ignore
-
db选项的当前值
Replicate_Do_Table
:
replicate
-
do
-
table选项的当前值
Replicate_Ignore_Table
:
replicate
-
ignore
-
table选项的当前值
Replicate_Wild_Do_Table
:
replicate
-
wild
-
do
-
table选项的当前值
Replicate_Wild_Ignore_Table
:
replicate
-
wild
-
ignore_table选项的当前值
Last_Errno
:
最近一次错误码
Last_Error
:
最近一次错误内容
Skip_Counter
:
最近被使用的用于SQL_SLAVE_SKIP_COUNTER的值
Exec_Master_Log_Pos
:
来自主服务器的二进制日志的由SQL线程执行的上一个时间的置。SQ L线程当前执行的时事件,在master二进制日志中的position。
在主服务器的二进制日志中的
(
Relay_Master_Log_File
,
Exec_Master_Log_Pos
)
对应于在中继日志中的
(
Relay_Log_File
,
Relay_Log_Pos
)
Relay_Log_Space
:
所有原有的中继日志结合起来的总大小
Until_Condition
:
如果没有指定UNTIL子句
,
则没有值
。
如果从属服务器正在读取
,
直到达到主服务器的二进制日志的给定位置为止
,
则值为Master
。
如果从属服务器正在读取
,
直到达到其中继日志的给定位置为止
,
则值为Relay
Until_Log_File
:
用于指示日志文件名
,
日志文件名和位置值定义了SQL线程在哪个点中止执行
Until_Log_Pos
:
用于指示日志位置值
,
日志文件名和位置值定义了SQL线程在哪个点中止执行
Master_SSL_Allowed
:
如果允许对主服务器进行SSL连接
,
则值为Yes
。
如果不允许对主服务器进行SSL连接
,
则值为No
。
如果允许SSL连接
,
但是从属服务器没有让SSL支持被启用
,
则值为Ignored
。
Master_SSL_CA_File
:
master
-
ca选项的当前值
Master_SSL_CA_Path
:
master
-
capath选项的当前值
Master_SSL_Cert
:
master
-
cert选项的当前值
Master_SSL_Cipher
:
master
-
cipher选项的当前值
Master_SSL_Key
:
master
-
key选项的当前值
Seconds_Behind_Master
:
是slave当前的时间戳和mater记录该事件时的时间戳的差值。
本字段是从属服务器
“
的
落后
”
多少一个指示
。
当从属SQL线程正在运行时
(
处理更新
),
本字段为在主服务器上由此线程执行的最近的一个事件的时间标记开始
,
已经过的秒数
。
当此线程被从属服务器I
/
O线程赶上
,
并进入闲置状态
,
等待来自I
/
O线程的更多的事件时
,
本字段为零
。
总之
,
本字段测量从属服务器SQL线程和从属服务器I
/
O线程之间的时间差距
,
单位以秒计
。
如果主服务器和从属服务器之间的网络连接较快
,
则从属服务器I
/
O线程会非常接近主服务器
,
所以本字段能够十分近似地指示
,
从属服务器SQL线程比主服务器落后多少
。
如果网络较慢
,
则这种指示不准确
;
从属SQL线程经常会赶上读取速度较慢地从属服务器I
/
O线程
,
因此
,
Seconds_Behind_Master经常显示值为0
。
即使I
/
O线程落后于主服务器时
,
也是如此
。
换句话说
,
本列只对速度快的网络有用
。
即使主服务器和从属服务器不具有相同的时钟
,
时间差计算也会起作用
(
当从属服务器I
/
O线程启动时
,
计算时间差
。
并假定从此时以后
,
时间差保持不变
)。
如果从属SQL线程不运行
,
或者如果从属服务器I
/
O线程不运行或未与主服务器连接
,
则Seconds_Behind_Master为NULL
(
意义为
“
未知
”)。
举例说明
,
如果在重新连接之前
,
从属服务器I
/
O线程休眠了master
-
connect
-
retry秒
,
则显示NULL
,
因为从属服务器不知道主服务器正在做什么
,
也不能有把握地说落后多少
。
本字段有一个限制
。
时间标记通过复制被保留
,
这意味着
,
如果一个主服务器M1本身是一个从属服务器M0
,
则来自M1的binlog的任何事件
(
通过复制来自M0的binlog的事件而产生
),
与原事件具有相同的时间标记
。
这可以使MySQL成功地复制TIMESTAMP
。
但是
,
Seconds_Behind_Master的缺点是
,
如果M1也收到来自客户端的直接更新
,
则值会随机变化
,
因为有时最近的M1时间来自M0
,
有时来自直接更新
,
最近的时间标记也是如此
。