内容简介
使用命令 SHOW SLAVE STATUS \G 可以查看 MySQL 的同步状态,它会输出一大堆的内容,这些内容会经常让人摸不着头绪,不知所云。
本文将揭开面纱,详细介绍输出中各个字段的含义,以及它们所代表的信息。
检查状态
在管理复制的过程中,最常见的任务是确保正在进行复制,并且主从之间没有错误。执行 SHOW SLAVE STATUS 语句来查看状态,必须在每个从库上执行。
下面将解释这些字段的含义以及他们所反映出来的问题。
关键字段
# Slave_IO_State – 从库的当前状态
Checking master version – 在建立与主站的连接之后,非常短暂地发生的状态。
Connecting to master – 线程正在尝试连接到主服务器。
Queueing master event to the relay log – 线程已读取事件,并将其复制到中继日志,以便SQL线程可以处理它。
Reconnecting after a failed binlog dump request – 线程正在尝试重新连接到主服务器。
Reconnecting after a failed master event read – 线程正在尝试重新连接到主服务器。 当再次建立连接时,状态变为:Waiting for master to send event
Registering slave on master – 建立与主站连接后非常短暂的状态。
Requesting binlog dump – 在建立与主站的连接之后,非常短暂地发生的状态。线程从请求的二进制日志文件名和位置开始向主机发送对其二进制日志内容的请求。
Waiting for master to send event – 线程已连接到主服务器并正在等待二进制日志事件到达。 如果主站空闲,这可能会持续很长时间。 如果等待持续slave_net_timeout秒,则发生超时。 此时,线程认为连接被破坏并尝试重新连接。
Waiting for master update – 在Connecting to master之前的初始状态
Waiting for slave mutex on exit – 线程停止时短暂发生的状态。
Waiting for the slave SQL thread to free enough relay log space – 您正在使用非零的relay_log_space_limit值,并且中继日志已经增长到足以使其组合大小超过此值。 「I/O线程」正在等待,直到SQL线程通过处理中继日志内容释放足够的空间,以便它可以删除一些中继日志文件。
Waiting to reconnect after a failed binlog dump request – 如果二进制日志转储请求失败(由于断开连接),则线程在休眠时进入此状态,然后尝试定期重新连接。 可以使用CHANGE MASTER TO语句指定重试之间的间隔。
Waiting to reconnect after a failed master event read – 读取时发生错误(由于断开连接)。 在尝试重新连接之前,线程会进入休眠,休眠时时间是由CHANGE MASTER TO语句(默认为60)设置的秒数。
# Slave_IO_Running – 用于读取主库二进制日志的「I/O线程」是否正在运行
除非尚未启动复制,或已使用STOP SLAVE明确停止复制,否则该字段的值通常为“Yes”。
# Slave_SQL_Running – 执行中继日志中事件的SQL线程是否正在运行
与「I/O线程」一样,通常应为“Yes”。
# Last_IO_Errno – 处理中继日志时「I/O线程」的最后一个错误编号
理想情况下,应该为零,表示没有错误。
# Last_IO_Error – 处理中继日志时「I/O线程」的最后一个错误
理想情况下,这些应为空白,表示没有错误。
# Last_SQL_Errno – 处理中继日志时SQL线程的最后一个错误编号
理想情况下,应该为零,表示没有错误。
# Last_SQL_Error – 处理中继日志时SQL线程的最后一个错误
理想情况下,这些应为空白,表示没有错误。
# Seconds_Behind_Master – 从库SQL线程处理主二进制日志的落后的秒数
较高数字(或数字增加)可以表示从库无法及时处理来自主库的事件。
如果Seconds_Behind_Master为0值,通常可以解释为意味着从库已经赶上了主库,但在某些情况下,这不是严格正确的。例如,如果主站和主库之间的网络连接断开,但从库的「I/O线程」尚未注意到这一点,即在slave_net_timeout设置的超时尚未过去时,则会发生这种情况。
如果Seconds_Behind_Master为瞬态值也可能无法准确反映情况。当从库SQL线程赶上I/O时,Seconds_Behind_Master显示0;但是当从库「I/O线程」仍在排队新事件时,Seconds_Behind_Master可能会显示一个较大的值,直到SQL线程完成执行新事件。当事件具有旧时间戳时,这尤其可能,在这种情况下,如果您在相对较短的时间内多次执行SHOW SLAVE STATUS,您可能会看到此值在0和相对较大的值之间反复来回变化。
同步进度
# Master_Log_File
表示「从库」的「I/O线程」当前正在从「主库」中读取的二进制日志文件。
# Read_Master_Log_Pos
它是「主库」二进制日志中的一个位置,表示从库的「I/O线程」已经读取到该位置。
可以在主库上执行SHOW MASTER STATUS语句,然后对比这两个值。
# Relay_Master_Log_File
表示「从库」正在执行「主库」的哪个二进制日志文件。这只是一种表示法,因为SQL线程真正执行的是中继日志文件。
# Exec_Master_Log_Pos
表示「从库」已经执行到「主库」的二进制日志的哪个位置。这依旧只是一种表示法。
# Relay_Log_File
表示「从库」的「SQL线程」当前正在执行的中继文件。
# Relay_Log_Pos
表示「从库」的「SQL线程」已经执行到的中继日志的哪个位置。
其他字段
Master_Host
主库的IP地址
Master_User
Master_Port
Connect_Retry
Replicate_Do_DB
Replicate_Ignore_DB
Replicate_Do_Table
Replicate_Ignore_Table
Replicate_Wild_Do_Table
Replicate_Wild_Ignore_Table
Last_Errno
Last_Error
Skip_Counter
Relay_Log_Space
Until_Condition
Until_Log_File
Until_Log_Pos
Master_SSL_Allowed
Master_SSL_CA_File
Master_SSL_CA_Path
Master_SSL_Cert
Master_SSL_Cipher
Master_SSL_Key
Master_SSL_Verify_Server_Cert
Replicate_Ignore_Server_Ids
Master_Server_Id
Master_UUID
Master_Info_File
SQL_Delay
SQL_Remaining_Delay
Slave_SQL_Running_State
Master_Retry_Count
Master_Bind
Last_IO_Error_Timestamp
Last_SQL_Error_Timestamp
Master_SSL_Crl
Master_SSL_Crlpath
Retrieved_Gtid_Set
Executed_Gtid_Set
Auto_Position
其他信息
语句SHOW STATUS也提供了一些与主从复制有关的信息。由语句SHOW STATUS显示的复制心跳信息允许您检查复制连接是否处于活动状态,即使主服务器最近未向从服务器发送事件也是如此。如果在比心跳间隔更长时间内,二进制日志中没有更新,并且没有未发送的事件,则主库向从库发送心跳信号。主库上的MASTER_HEARTBEAT_PERIOD设置(由CHANGE MASTER TO语句设置)指定心跳的频率,默认为从库的连接超时间隔的一半(slave_net_timeout)。语句SHOW STATUS的Slave_last_heartbeat变量显示复制从站上次收到心跳信号的时间。
在主库上,可以使用SHOW PROCESSLIST检查已连接从服务器的状态,以检查正在运行的进程列表。但是,由于是从库驱动的复制过程,所以显示的信息可能比较少。
对于使用–report-host选项启动,并连接到组库的从库,主库的SHOW SLAVE HOSTS语句显示有关从库的基本信息。输出包括从库的ID(Server_id)、–report-host选项的值、连接端口、主库ID(Master_id)。
常见错误
# Got fatal error 1236 from master when reading data from binary
-「MySQL Replication: ‘Got fatal error 1236’ causes and cures」
参考文献