===想确认sql_thread线程是否应用完了io_thread接收到的了relay log,看 Master_Log_File=Relay_Master_Log_File , Read_Master_Log_Pos=Exec_Master_Log_Pos

Master_Log_File: mysql-bin.000004 #当前的slave已经读取了master的binlog文件--slave I/O thread
Read_Master_Log_Pos: 46187589 #当前的slave读取的master binlog---mysql_binlog.000004 位置是46187589--slave I/O thread
Relay_Log_File: relaylog.000008 #当前relay文件
Relay_Log_Pos: 46187752 #当前relay文件位置的点relaylog.000008,位置是46187752
Relay_Master_Log_File: mysql-bin.000004 #当前slave的sql线程应用到master的binlog的mysql-bin.000004,位置为下一行的 46187589--slave SQL thread
Slave_IO_Running: Yes
Slave_SQL_Running: Yes
Skip_Counter: 0
Exec_Master_Log_Pos: 46187589 #当前sql_thread线程执行到binlog的位置点,---slave SQL thread
Relay_Log_Space: 46187918 #The total combined size of all existing relay log files. 所有存在的relay log文件的总大小
Until_Condition: None

mysql 5.6 官方文档

(Master_Log_file, Read_Master_Log_Pos): Coordinates in the master binary log indicating how far the slave I/O thread has read events from that log.
(Relay_Master_Log_File, 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_File, 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.

SHOW SLAVE STATUS Syntax
This statement provides status information on essential parameters of the slave threads. It requires either
the SUPER or REPLICATION CLIENT privilege.
If you issue this statement using the mysql client, you can use a \G statement terminator rather than a
semicolon to obtain a more readable vertical layout:
mysql> SHOW SLAVE STATUS\G
*************************** 1. row ***************************
Slave_IO_State: Waiting for master to send event
Master_Host: localhost
Master_User: root
Master_Port: 13000
Connect_Retry: 60
Master_Log_File: master-bin.000002
Read_Master_Log_Pos: 1307
Relay_Log_File: slave-relay-bin.000003
Relay_Log_Pos: 1508
Relay_Master_Log_File: master-bin.000002
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: 1307
Relay_Log_Space: 1858
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:
Master_Server_Id: 1
Master_UUID: 3e11fa47-71ca-11e1-9e33-c80aa9429562
Master_Info_File: /var/mysqld.2/data/master.info
SQL_Delay: 0
SQL_Remaining_Delay: NULL
Slave_SQL_Running_State: Reading event from the relay log
Master_Retry_Count: 10
Master_Bind:
Last_IO_Error_Timestamp:
Last_SQL_Error_Timestamp:
Master_SSL_Crl:
Master_SSL_Crlpath:
Retrieved_Gtid_Set: 3e11fa47-71ca-11e1-9e33-c80aa9429562:1-5
Executed_Gtid_Set: 3e11fa47-71ca-11e1-9e33-c80aa9429562:1-5
Auto_Position: 1
Slave_IO_State
A copy of the State field of the SHOW PROCESSLIST output for the slave I/O thread. This tells you whatthe thread is doing: trying to connect to the master, waiting for events from the master, reconnecting to
the master, and so on. For a listing of possible states, see Section 8.14.6, “Replication Slave I/O ThreadStates”.
• Master_Host
The master host that the slave is connected to.
• Master_User
The user name of the account used to connect to the master.
• Master_Port
The port used to connect to the master.
• Connect_Retry
The number of seconds between connect retries (default 60). This can be set with the CHANGE MASTER
TO statement.
Master_Log_File
The name of the master binary log file from which the I/O thread is currently reading.
Read_Master_Log_Pos
The position in the current master binary log file up to which the I/O thread has read.
Relay_Log_File
The name of the relay log file from which the SQL thread is currently reading and executing.
Relay_Log_Pos
The position in the current relay log file up to which the SQL thread has read and executed.
Relay_Master_Log_File
The name of the master binary log file containing the most recent event executed by the SQL thread.
Slave_IO_Running
Whether the I/O thread is started and has connected successfully to the master. Internally, the state of
this thread is represented by one of the following three values:
• MYSQL_SLAVE_NOT_RUN. The slave I/O thread is not running. For this state,
Slave_IO_Running is No.
• MYSQL_SLAVE_RUN_NOT_CONNECT. The slave I/O thread is running, but is not connected to a
replication master. For this state, Slave_IO_Running is Connecting.
• MYSQL_SLAVE_RUN_CONNECT. The slave I/O thread is running, and is connected to a
replication master. For this state, Slave_IO_Running is Yes.
The value of the Slave_running system status variable corresponds with this value.
Slave_SQL_Running
Whether the SQL thread is started.
• Replicate_Do_DB, Replicate_Ignore_DB
The lists of databases that were specified with the --replicate-do-db and --replicate-ignoredb options, if any.
• Replicate_Do_Table, Replicate_Ignore_Table, Replicate_Wild_Do_Table,
Replicate_Wild_Ignore_Table
The lists of tables that were specified with the --replicate-do-table, --replicate-ignoretable, --replicate-wild-do-table, and --replicate-wild-ignore-table options, if any.
• Last_Errno, Last_Error
These columns are aliases for Last_SQL_Errno and Last_SQL_Error.
Issuing RESET MASTER or RESET SLAVE resets the values shown in these columns.
Note
When the slave SQL thread receives an error, it reports the error first, then stops the SQL thread. This means that there is a small window of time during which
SHOW SLAVE STATUS shows a nonzero value for Last_SQL_Errno even though Slave_SQL_Running still displays Yes.
• Skip_Counter
The current value of the sql_slave_skip_counter system variable. See Section 13.4.2.4, “SET
GLOBAL sql_slave_skip_counter Syntax”.
Exec_Master_Log_Pos
The position in the current master binary log file to which the SQL thread has read and executed,
marking the start of the next transaction or event to be processed. You can use this value with
the CHANGE MASTER TO statement's MASTER_LOG_POS option when starting a new slave from an existing slave, so that the new slave reads from this point. The coordinates given by
(Relay_Master_Log_File, Exec_Master_Log_Pos) in the master's binary log correspond to the coordinates given by (Relay_Log_File, Relay_Log_Pos) in the relay log.
When using a multithreaded slave (by setting slave_parallel_workers to a nonzero value), the value in this column actually represents a “low-water” mark, before which no uncommitted transactions
remain. Because the current implementation allows execution of transactions on different databases in a different order on the slave than on the master, this is not necessarily the position of the most recently
executed transaction.
• Relay_Log_Space
The total combined size of all existing relay log files.
• Until_Condition, Until_Log_File, Until_Log_Pos
The values specified in the UNTIL clause of the START SLAVE statement. Until_Condition has these values:
• None if no UNTIL clause was specified
• Master if the slave is reading until a given position in the master's binary log
• Relay if the slave is reading until a given position in its relay log
• SQL_BEFORE_GTIDS if the slave SQL thread is processing transactions until it has reached the first
transaction whose GTID is listed in the gtid_set.
• SQL_AFTER_GTIDS if the slave threads are processing all transactions until the last transaction in the
gtid_set has been processed by both threads.
• SQL_AFTER_MTS_GAPS if a multithreaded slave's SQL threads are running until no more gaps are
found in the relay log.
Until_Log_File and Until_Log_Pos indicate the log file name and position that define the
coordinates at which the SQL thread stops executing.
For more information on UNTIL clauses, see Section 13.4.2.5, “START SLAVE Syntax”.
• Master_SSL_Allowed, Master_SSL_CA_File, Master_SSL_CA_Path, Master_SSL_Cert,
Master_SSL_Cipher, Master_SSL_CRL_File, Master_SSL_CRL_Path, Master_SSL_Key,
Master_SSL_Verify_Server_Cert
These fields show the SSL parameters used by the slave to connect to the master, if any.
Master_SSL_Allowed has these values:
• Yes if an SSL connection to the master is permitted
• No if an SSL connection to the master is not permitted
• Ignored if an SSL connection is permitted but the slave server does not have SSL support enabled
The values of the other SSL-related fields correspond to the values of the MASTER_SSL_CA,
MASTER_SSL_CAPATH, MASTER_SSL_CERT, MASTER_SSL_CIPHER, MASTER_SSL_CRL,
MASTER_SSL_CRLPATH, MASTER_SSL_KEY, and MASTER_SSL_VERIFY_SERVER_CERT options to the
CHANGE MASTER TO statement. See Section 13.4.2.1, “CHANGE MASTER TO Syntax”.
Seconds_Behind_Master
This field is an indication of how “late” the slave is:
• When the slave is actively processing updates, this field shows the difference between the current timestamp on the slave and the original timestamp logged on the master for the event currently being processed on the slave.
• When no event is currently being processed on the slave, this value is 0. In essence, this field measures the time difference in seconds between the slave SQL thread and the slave I/O thread. If the network connection between master and slave is fast, the slave I/O thread is very
close to the master, so this field is a good approximation of how late the slave SQL thread is compared
to the master. If the network is slow, this is not a good approximation; the slave SQL thread may quite often be caught up with the slow-reading slave I/O thread, so Seconds_Behind_Master often shows
a value of 0, even if the I/O thread is late compared to the master. In other words, this column is useful only for fast networks.
This time difference computation works even if the master and slave do not have identical clock times, provided that the difference, computed when the slave I/O thread starts, remains constant from then
on. Any changes—including NTP updates—can lead to clock skews that can make calculation of Seconds_Behind_Master less reliable.
In MySQL 5.6.9 and later, this field is NULL (undefined or unknown) if the slave SQL thread is not
running, or if the SQL thread has consumed all of the relay log and the slave I/O thread is not running.
Previously, this field was NULL if the slave SQL thread or the slave I/O thread was not running or was
not connected to the master. (Bug #12946333) For example, if (prior to MySQL 5.6.9) the slave I/O
thread was running but was not connected to the master and was sleeping for the number of seconds
given by the CHANGE MASTER TO statement or --master-connect-retry option (default 60) before
reconnecting, the value was NULL. Now in such cases, the connection to the master is not tested;
instead, if the I/O thread is running but the relay log is exhausted, Seconds_Behind_Master is set to
0.
The value of Seconds_Behind_Master is based on the timestamps stored in events, which are
preserved through replication. This means that if a master M1 is itself a slave of M0, any event from M1's
binary log that originates from M0's binary log has M0's timestamp for that event. This enables MySQL
to replicate TIMESTAMP successfully. However, the problem for Seconds_Behind_Master is that if
M1 also receives direct updates from clients, the Seconds_Behind_Master value randomly fluctuates
because sometimes the last event from M1 originates from M0 and sometimes is the result of a direct
update on M1.
When using a multithreaded slave, you should keep in mind that this value is based on
Exec_Master_Log_Pos, and so may not reflect the position of the most recently committed
transaction.
• Last_IO_Errno, Last_IO_Error
The error number and error message of the most recent error that caused the I/O thread to stop. An
error number of 0 and message of the empty string mean “no error.” If the Last_IO_Error value is not
empty, the error values also appear in the slave's error log.
I/O error information includes a timestamp showing when the most recent I/O thread error occurred. This
timestamp uses the format YYMMDD HH:MM:SS, and appears in the Last_IO_Error_Timestamp
column.
Issuing RESET MASTER or RESET SLAVE resets the values shown in these columns.
• Last_SQL_Errno, Last_SQL_Error
The error number and error message of the most recent error that caused the SQL thread to stop. An
error number of 0 and message of the empty string mean “no error.” If the Last_SQL_Error value is
not empty, the error values also appear in the slave s error log.
SQL error information includes a timestamp showing when the most recent SQL thread
error occurred. This timestamp uses the format YYMMDD HH:MM:SS, and appears in the
Last_SQL_Error_Timestamp column.
Issuing RESET MASTER or RESET SLAVE resets the values shown in these columns.
• Replicate_Ignore_Server_Ids
In MySQL 5.6, you set a slave to ignore events from 0 or more masters using the IGNORE_SERVER_IDS
option of the CHANGE MASTER TO statement. By default this is blank, and is usually modified
only when using a circular or other multi-master replication setup. The message shown for
Replicate_Ignore_Server_Ids when not blank consists of a comma-delimited list of one or more
numbers, indicating the server IDs to be ignored. For example:
Replicate_Ignore_Server_Ids: 2, 6, 9
Note
Ignored_server_ids also shows the server IDs to be ignored, but is a
space-delimited list, which is preceded by the total number of server IDs to
be ignored. For example, if a CHANGE MASTER TO statement containing the
IGNORE_SERVER_IDS = (2,6,9) option has been issued to tell a slave to
ignore masters having the server ID 2, 6, or 9, that information appears as:
Ignored_server_ids: 3 2 6 9
where 3 is the total number of server IDs being ignored
Replicate_Ignore_Server_Ids filtering is performed by the I/O thread, rather than by the SQL
thread, which means that events which are filtered out are not written to the relay log. This differs from
the filtering actions taken by server options such --replicate-do-table, which apply to the SQL
thread.
• Master_Server_Id
The server_id value from the master.
• Master_UUID
The server_uuid value from the master.
• Master_Info_File
The location of the master.info file.
• SQL_Delay
The number of seconds that the slave must lag the master.
• SQL_Remaining_Delay
When Slave_SQL_Running_State is Waiting until MASTER_DELAY seconds after master
executed event, this field contains the number of delay seconds remaining. At other times, this field is
NULL.
• Slave_SQL_Running_State
The state of the SQL thread (analogous to Slave_IO_State). The value is identical to the State value
of the SQL thread as displayed by SHOW PROCESSLIST; Section 8.14.7, “Replication Slave SQL Thread
States”, provides a listing of possible states.
• Master_Retry_Count
The number of times the slave can attempt to reconnect to the master in the event of a lost connection.
This value can be set using the MASTER_RETRY_COUNT option of the CHANGE MASTER TO statement
(preferred) or the older --master-retry-count server option (still supported for backward
compatibility).
• Master_Bind
The network interface that the slave is bound to, if any. This is set using the MASTER_BIND option for the
CHANGE MASTER TO statement.
• Last_IO_Error_Timestamp
A timestamp in YYMMDD HH:MM:SS format that shows when the most recent I/O error took place.
• Last_SQL_Error_Timestamp
A timestamp in YYMMDD HH:MM:SS format that shows when the most recent SQL error occurred.
• Retrieved_Gtid_Set
The set of global transaction IDs corresponding to all transactions received by this slave. Empty if GTIDs
are not in use.
This is the set of all GTIDs that exist or have existed in the relay logs. Each GTID is added as soon as
the Gtid_log_event is received. This can cause partially transmitted transactions to have their GTIDs
included in the set.
When all relay logs are lost due to executing RESET SLAVE or CHANGE MASTER TO, or due to the
effects of the --relay-log-recovery option, the set is cleared. When relay_log_purge = 1, the
newest relay log is always kept, and the set is not cleared.
• Executed_Gtid_Set
The set of global transaction IDs written in the binary log. This is the same as the value for the global
gtid_executed system variable on this server, as well as the value for Executed_Gtid_Set in the
output of SHOW MASTER STATUS on this server. Empty if GTIDs are not in use. See GTID Sets for more
information.
• Auto_Position
1 if autopositioning is in use; otherwise 0.

mysql ,show slave status详解的更多相关文章

  1. SHOW SLAVE STATUS 详解

    MySQL同步功能由3个线程(master上1个,slave上2个)来实现.执行 DE>START SLAVEDE> 语句后,slave就创建一个I/O线程.I/O线程连接到master上 ...

  2. MySQL运行状态show status详解

    状态名 作用域 详细解释 Aborted_clients Global 由于客户端没有正确关闭连接导致客户端终止而中断的连接数 Aborted_connects Global 试图连接到MySQL服务 ...

  3. [转载]MySQL运行状态show status详解

    要查看MySQL运行状态,要优化MySQL运行效率都少不了要运行show status查看各种状态,下面是参考官方文档及网上资料整理出来的中文详细解释,不管你是初学mysql还是你是mysql专业级的 ...

  4. mysql的show status详解(转载)

    SHOW STATUS提供服务器的状态信息(象mysqladmin extended-status一样).输出类似于下面的显示,尽管格式和数字可以有点不同: +-------------------- ...

  5. mysql学习3:mysql之my.cnf详解

    mysql之my.cnf详解 本文转自:https://www.cnblogs.com/panwenbin-logs/p/8360703.html 以下是 my.cnf 配置文件参数解释: #*** ...

  6. MySQL权限授权认证详解

    MySQL权限授权认证详解 作者:尹正杰 版权声明:原创作品,谢绝转载!否则将追究法律责任. 一.MySQL权限系统介绍1>.权限系统的作用是授予来自某个主机的某个用户可以查询.插入.修改.删除 ...

  7. mysql数据恢复,binlog详解

    个人博客:mysql数据恢复,binlog详解 binlog日志恢复数据,是挽救错误操作和数据损坏一根救命稻草,所以认识和使用binglog对于技术人员还是很有必要的 binlog一般用于 主从复制 ...

  8. mysql配置文件my.cnf详解

    原文地址:mysql配置文件my.cnf详解 作者:gron basedir = path 使用给定目录作为根目录(安装目录). character-sets-dir = path 给出存放着字符集的 ...

  9. MySQL复制相关参数详解

    MySQL复制相关参数详解 作者:尹正杰  版权声明:原创作品,谢绝转载!否则将追究法律责任. 一.复制相关系统变量 1>.server_id 是必须设置在master和每个slave上的唯一标 ...

随机推荐

  1. vector push_back数量大的时候变慢

    才用15000个数据  push_back耗时就好几秒, 解决方法是 先resize 15000, 然后再 for (int i = 0; i < 15000; i++) { Data data ...

  2. ie7 动态改变select option时,宽度自动变短解决方法

    <html> <head> <title>JQuery</title> <meta http-equiv="pragma" c ...

  3. 51nod 1640 MST+二分

    http://www.51nod.com/onlineJudge/questionCode.html#!problemId=1640 1640 天气晴朗的魔法 题目来源: 原创 基准时间限制:1 秒 ...

  4. 亚马逊EC2

    亚马逊EC2编辑 本词条缺少信息栏,补充相关内容使词条更完整,还能快速升级,赶紧来编辑吧! 亚马逊弹性计算云(EC2,Elastic Compute Cloud)是一个让使用者可以租用云端电脑运行所需 ...

  5. Swagger实践和总结

    Swagger学习和实践 最近安装并使用了一下Swagger-ui.Swagger-editor和Swagger-codegen,感觉还不错. Swagger 是一个规范和完整的框架,用于生成.描述. ...

  6. 内存保护机制及绕过方案——利用未启用SafeSEH模块绕过SafeSEH

    前言:之前关于safeSEH保护机制的原理等信息,可在之前的博文(内存保护机制及绕过方案中查看). 利用未启用SafeSEH模块绕过SafeSEH ⑴.  原理分析: 一个不是仅包含中间语言(1L)且 ...

  7. ndoutils_mq项目: 发送Nagios的性能、报警、配置文件到RabbitMQ

    本人目前开发的一个项目,改造ndoutils,主要是它的ndomod. 将性能.报警.配置文件使用JSON格式发送到RabbitMQ. 由于NEB(Nagios Event Broker)使用C开发, ...

  8. poscms仿站知识点总结(二)

    1.相同类型div添加不同class 遇到一个样式上的问题,模板页面有8个子项,样式都是一样,至于数据是可以用for循环来添加的,但是for循环的时候,每个div的 类名是无法及时更改的,但是模板页面 ...

  9. Java并发编程之CyclicBarrier

    一.场景描述 有四个游戏玩家玩游戏,游戏有三个关卡,每个关卡必须要所有玩家都到达后才能允许通过.其实这个场景里的玩家中如果有玩家A先到了关卡1,他必须等到其他所有玩家都到达关卡1时才能通过,也就是说线 ...

  10. 【Java 并发】Executor框架机制与线程池配置使用

    [Java 并发]Executor框架机制与线程池配置使用 一,Executor框架Executor框架便是Java 5中引入的,其内部使用了线程池机制,在java.util.cocurrent 包下 ...