1
Slave_IO_State:SHOW PROCESSLIST输出的State字段的拷贝。
Master_User:被用于连接主服务器的当前用户。
Master_Port:当前的主服务器接口。
Connect_Retry:–master-connect-retry选项的当前值，连接重试时间
Master_Log_File:I/O线程当前正在读取的主服务器二进制日志文件的名称。
Read_Master_Log_Pos:在当前的主服务器二进制日志中，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_Ignore_DB
搭建主从复制时使用–replicate-do-db和–replicate-ignore-db选项指定的数据库清单
Replicate_Do_Table,
Replicate_Ignore_Table,
Replicate_Wild_Do_Table,
Replicate_Wild_Ignore_Table
使用–replicate-do-table,–replicate-ignore-table,–replicate-wild-do-table和–replicate-wild-ignore_table选项指定的表清单
Last_Errno,Last_Error:被多数最近被执行的查询返回的错误数量和错误消息。错误数量为0并且消息为空字符串意味着“没有错误”。如果Last_Error值不是空值，它也会在从服务器的错误日志中作为消息显示。
Skip_Counter:最近被使用的用于SQL_SLAVE_SKIP_COUNTER的值。
Exec_Master_Log_Pos:表示SQL线程已经执行的Relay log相对于主库二进制日志偏移量的位置，一般gtid复制出错使用该项去主库中查询。
Relay_Log_Space:表示所有原有的中继日志结合起来的总大小
Until_Condition:如果没有指定UNTIL子句，则没有值。如果从属服务器正在读取，直到达到主服务器的二进制日志的给定位置为止，则值为Master，如果从属服务器正在读取，直到达到其中继日志的给定位置为止，则值为Relay。
Until_Log_File
Until_Log_Pos
Until_Log_File和Until_Log_Pos用于指示日志文件名和位置值，日志文件名和位置值定义了SQL线程在哪个点中止执行。
Master_SSL_Allowed:显示了从服务器是否使用SSL连接到主服务器。如果允许对主服务器进行SSL连接，则值为Yes；如果不允许对主服务器进行SSL连接，则值为No；如果允许SSL连接，但是从服务器没有让SSL支持被启用，则值为Ignored。
Master_SSL_CA_File
Master_SSL_CA_Path
Master_SSL_Cert
Master_SSL_Cipher
Master_SSL_Key
如果Slave使用SSL连接Master服务器，这里就会显示对应的证书和私钥信息。使用CHANGE MASTER与SSL相关的选项有：–master-ca,–master-capath,–master-cert,–master-cipher和–master-key等。
Seconds_Behind_Master:表示主从之间延迟的时间，单位是秒。就是SQL线程当前执行的binlog（实际上是relay log）中的timestamp和IO线程最新的timestamp的差值。
实质上，此字段计算Slave SQL线程和Slave i/o线程之间的时间差 (以秒为单位)。如果主节点和从服务器之间的网络连接速度较快，则Slave i/o线程非常接近主服务器，因此此字段是对从SQL线程与主服务器进行比较的后的一个很好的近似值。如果网络很慢，这不是一个好的近似；从SQL线程可能经常被从i/o线程所捕获，因此Seconds_Behind_Master通常显示值为0，即使i/o线程比主服务器慢很多。换言之，此列仅适用于快速网络，后续将专门出一篇文章对这个SBM的值进行说明。
Master_SSL_Verify_Server_Cert:显示是否认证Master证书。
Last_IO_Error，Last_SQL_Error:类似last_error,在出现IO线程错误和SQL线程错误的时候会有值
Replicate_Ignore_Server_Ids: :slave当前会跳过的事件号
Master_Server_Id:显示主服务器的Server_id。
Master_UUID:记录Master的UUID。
Master_Info_File:记录Master info信息的存储位置。
SQL_Delay:记录Slave设置延迟复制的时间，0表示无延迟，主动延迟复制在某些情况下有助于恢复。
SQL_Remaining_Delay:当 Slave_SQL_Running_State 等待，直到MASTER_DELAY秒后，Master执行的事件， 此字段包含一个整数，表示有多少秒左右的延迟。在其他时候，这个字段是0。
Slave_SQL_Running_State
可以通过监控show slave status\G命令输出的Seconds_Behind_Master参数的值来判断，是否有发生主从延时。
以上是show slave status\G的输出结果，需要监控下面三个参数：
1）Slave_IO_Running：该参数可作为io_thread的监控项，Yes表示io_thread的和主库连接正常并能实施复制工作，No则说明与主库通 讯异常，多数情况是由主从间网络引起的问题；
2）Slave_SQL_Running：该参数代表sql_thread是否正常，YES表示正常，NO表示执行失败，具体就是语句是否执行通过，常会遇到 主键重复或是某个表不存在。
3）Seconds_Behind_Master：是通过比较sql_thread执行的event的timestamp和io_thread复制好的event的timestamp(简写为ts)进行 比较，而得到的这么一个差值；
NULL—表示io_thread或是sql_thread有任何一个发生故障，也就是该线程的Running状态是No，而非Yes。
0 — 该值为零，是我们极为渴望看到的情况，表示主从复制良好，可以认为lag不存在。
正值 — 表示主从已经出现延时，数字越大表示从库落后主库越多。
负值 — 几乎很少见，我只是听一些资深的DBA说见过，其实，这是一个BUG值，该参数是不支持负值的，也就是不应该出现。
Seconds_Behind_Master的计算方式可能带来的问题：
relay-log和主库的bin-log里面的内容完全一样，在记录sql语句的同时会被记录上当时的ts，所以比较参考的值来自于binlog，其实主从没有必要与NTP进行同步，也就是说无需保证主从时钟的一致。其实比较动作真正是发生在io_thread与sql_thread之间，而io_thread才真正与主库有关联，于是，问题就出来了，当主库I/O负载很大或是网络阻塞，io_thread不能及时复制binlog（没有中断，也在复制），而sql_thread一直都能跟上io_thread的脚本，这时Seconds_Behind_Master的值是0，也就是我们认为的无延时，但是，实际上不是，你懂得。这也就是为什么大家要批判用这个参数来监控数据库是否发生延时不准的原因，但是这个值并不是总是不准，如果当io_thread与master网络很好的情况下，那么该值也是很有价值的。之前，提到Seconds_Behind_Master这个参数会有负值出现，我们已经知道该值是io_thread的最近跟新的ts与sql_thread执行到的ts差值，前者始终是大于后者的，唯一的肯能就是某个event的ts发生了错误，比之前的小了，那么当这种情况发生时，负值出现就成为可能。
如何正确判断slave的延迟情况：
1）首先看 Relay_Master_Log_File 和 Master_Log_File 是否有差异；
2）如果Relay_Master_Log_File 和 Master_Log_File 是一样的话，再来看Exec_Master_Log_Pos 和 Read_Master_Log_Pos 的差异，对比SQL 线程比IO线程慢了多少个binlog事件；
3）如果Relay_Master_Log_File 和 Master_Log_File 不一样，那说明延迟可能较大，需要从MASTER上取得binlog status，判断当前的 binlog和MASTER上的差距；
因此，相对更加严谨的做法是：
在第三方监控节点上，对MASTER和slave同时发起SHOW BINARY LOGS和SHOW slave STATUS\G的请求，最后判断二者binlog的差 异，以及 Exec_Master_Log_Pos 和Read_Master_Log_Pos 的差异。
例如：
在MASTER上执行SHOW BINARY LOGS 的结果是：
+------------------+--------------+
| Log_name | File_size |
+------------------+--------------+
| mysql-bin.000009 | 1073742063 |
| mysql-bin.000010 | 107374193 |
+------------------+--------------+
而在slave上执行SHOW slave STATUS\G 的结果是：
Master_Log_File: mysql-bin.000009
Read_Master_Log_Pos: 668711237
Relay_Master_Log_File: mysql-bin.000009
slave_IO_Running: Yes
slave_SQL_Running: Yes
***
Exec_Master_Log_Pos: 654409041
***
Seconds_Behind_Master: 3296
***
这时候，slave实际的延迟应该是：
mysql-bin.000009 这个binlog中的binlog position 1073742063 和 slave上读取到的binlog position之间的差异延迟，即：
1073742063 - 654409041 = 419333022 个binlog event
并且还要加上 mysql-bin.000010这个binlog已经产生的107374193个binlog event，共
107374193 + 419333022 = 526707215 个binlog event
原文链接：https://www.cnblogs.com/kevingrace/p/5685511.html
