mysql系列（一）细说show slave status参数详解（最全）

1. mysql系列（一）细说show slave status参数详解（最全）

1. mysql系列（一）细说show slave status参数详解（最全）
- 1.1. 参数详解
与master相关的日志的信息
- - 1.1.6. Master_Log_File: mysql-bin.001822
  - 1.1.7. Read_Master_Log_Pos: 290072815
与relay log相关的信息
slave I/O和SQL线程的状态（重要）
GTID模式相关
- - 1.1.30. Retrieved_Gtid_Set:
- 1.2. RESET命令的用法和解释：

在搭建好mysql主从之后，我们一般在从库上通过命令来查看主从的状态：

show slave status\G
*************************** 1. row ***************************
               Slave_IO_State: Waiting for master to send event
                  Master_Host: 192.168.1.100
                  Master_User: mysync
                  Master_Port: 3306
                Connect_Retry: 60
              Master_Log_File: mysql-bin.001822
          Read_Master_Log_Pos: 290072815
               Relay_Log_File: mysqld-relay-bin.005201
                Relay_Log_Pos: 256529594
        Relay_Master_Log_File: mysql-bin.001821
             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: 256529431
              Relay_Log_Space: 709504534
              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: 2923
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: 13ee75bb-99e2-11e6-be4d-b499baa80e6e
             Master_Info_File: /home/data/mysql/master.info
                    SQL_Delay: 0
          SQL_Remaining_Delay: NULL
      Slave_SQL_Running_State: Reading event from the relay log
           Master_Retry_Count: 86400
                  Master_Bind: 
      Last_IO_Error_Timestamp: 
     Last_SQL_Error_Timestamp: 
               Master_SSL_Crl: 
           Master_SSL_Crlpath: 
           Retrieved_Gtid_Set: 
            Executed_Gtid_Set: 
                Auto_Position: 0
1 row in set (0.02 sec)

1.1. 参数详解

1.1.1. Slave_IO_State

这里显示了当前slave I/O线程的状态(slave连接到master的状态)。状态信息和使用show processlist | grep "system user"(会显示两条信息，一条slave I/O线程的，一条是slave SQL线程的)显示的内容一样。

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线程停止时会出现的状态，出现的时间非常短。

1.1.2. Master_Host: 192.168.1.100

mysql主库的ip地址

1.1.3. Master_User: mysync

这个是master上面的一个用户。用来负责主从复制的用户，创建主从复制的时候建立的（具有reolication slave权限）。

1.1.4. Master_Port: 3306

master服务器的端口一般是3306

1.1.5. Connect_Retry: 60

连接中断后，重新尝试连接的时间间隔。默认值是60秒。

与master相关的日志的信息

1.1.6. Master_Log_File: mysql-bin.001822

当前I/O线程正在读取的主服务器二进制日志文件的名称。

1.1.7. Read_Master_Log_Pos: 290072815

当前I/O线程正在读取的二进制日志的位置。

与relay log相关的信息

1.1.8. Relay_Log_File: mysqld-relay-bin.005201

当前slave SQL线程正在读取并执行的relay log的文件名。

1.1.9. Relay_Log_Pos: 256529594

当前slave SQL线程正在读取并执行的relay log文件中的位置；（Relay_Log_File下的Relay_Log_Pos其实一一对应着Relay_Master_Log_File的Exec_Master_Log_Pos。）

1.1.10. Relay_Master_Log_File: mysql-bin.001821

当前slave SQL线程读取并执行的relay log的文件中多数近期事件，对应的主服务器二进制日志文件的名称。（说白点就是我SQL线程从relay日志中读取的正在执行的sql语句，对应主库的sql语句记录在主库的哪个binlog日志中）

slave I/O和SQL线程的状态（重要）

1.1.11. Slave_IO_Running: Yes

I/O线程是否被启动并成功地连接到主服务器上。

1.1.12. Slave_SQL_Running: Yes

SQL线程是否被启动。

1.1.13. Replicate_Do_DB

Replicate_Ignore_DB
Replicate_Do_Table
Replicate_Ignore_Table
Replicate_Wild_Do_Table
Replicate_Wild_Ignore_Table
这些参数都是为了用来指明哪些库或表在复制的时候不要同步到从库，但是这些参数用的时候要小心，因为当跨库使用的时候可能会出现问题。
一般情况下，限制的时候都用Replicate_Wild_Ignore_Table这个参数。

1.1.14. Last_Errno: 0

Last_Error
slave的SQL线程读取日志参数的的错误数量和错误消息。错误数量为0并且消息为空字符串表示没有错误。
如果Last_Error值不是空值，它也会在从属服务器的错误日志中作为消息显示。

1.1.15. Skip_Counter: 0

SQL_SLAVE_SKIP_COUNTER的值，用于设置跳过sql执行步数。

1.1.16. Exec_Master_Log_Pos: 256529431

slave SQL线程当前执行的事件，对应在master相应的二进制日志中的position。（结合Relay_Master_Log_File理解，而且在Relay_Master_Log_File这个值等于Master_Log_File值的时候，Exec_Master_Log_Pos是不可能超过Read_Master_Log_Pos的。）

1.1.17. Relay_Log_Space: 709504534

所有原有的中继日志结合起来的总大小。

1.1.18. Until_Condition: None

Until_Log_File:
Until_Log_Pos: 0
在START SLAVE语句的UNTIL子句中指定的值。
Until_Condition具有以下值：

如果没有指定UNTIL子句，则没有值
如果从属服务器正在读取，直到达到主服务器的二进制日志的给定位置为止，则值为Master
如果从属服务器正在读取，直到达到其中继日志的给定位置为止，则值为Relay
Until_Log_File和Until_Log_Pos用于指示日志文件名和位置值。日志文件名和位置值定义了SQL线程在哪个点中止执行。

1.1.19. Master_SSL_Allowed: No

Master_SSL_CA_File:
Master_SSL_CA_Path:
Master_SSL_Cert:
Master_SSL_Cipher:
Master_SSL_Key:
Master_SSL_Verify_Server_Cert: No
Master_SSL_Crl:
Master_SSL_Crlpath:
这些字段显示了被从属服务器使用加密相关的参数。这些参数用于连接主服务器。
Master_SSL_Allowed具有以下值：

如果允许对主服务器进行SSL连接，则值为Yes
如果不允许对主服务器进行SSL连接，则值为No
如果允许SSL连接，但是从属服务器没有让SSL支持被启用，则值为Ignored。
与SSL有关的字段的值对应于–master-ca,–master-capath,–master-cert,–master-cipher和–master-key选项的值。

1.1.20. seconds_Behind_Master: 2923

这个值是时间戳的差值。是slave当前的时间戳和master记录该事件时的时间戳的差值。

1.1.21. Last_IO_Errno: 0

Last_IO_Error:
Last_SQL_Errno: 0
Last_SQL_Error:
最后一次I/O线程或者SQL线程的错误号和错误消息。

1.1.22. Replicate_Ignore_Server_Ids:

主从复制，从库忽略的主库服务器Id号。就是不以这些服务器Id为主库。

1.1.23. Master_Server_Id: 1

Master_UUID: 13ee75bb-99e2-11e6-be4d-b499baa80e6e
Master_Info_File: /home/data/mysql/master.info
分别表示主库服务器id号，主库服务器的UUID好，还有在从库中保存主库服务器相关的目录位置。

1.1.24. SQL_Delay: 0

一个非负整数，表示秒数，Slave滞后多少秒于master。

1.1.25. SQL_Remaining_Delay: NULL

当 Slave_SQL_Running_State 等待，直到MASTER_DELAY秒后，Master执行的事件，此字段包含一个整数，表示有多少秒左右的延迟。在其他时候，这个字段是NULL。

1.1.26. Slave_SQL_Running_State: Reading event from the relay log

SQL线程运行状态：

Reading event from the relay log
线程已经从中继日志读取一个事件，可以对事件进行处理了。
Has read all relay log; waiting for the slave I/O thread to update it
线程已经处理了中继日志文件中的所有事件，现在正等待I/O线程将新事件写入中继日志。
Waiting for slave mutex on exit
线程停止时发生的一个很简单的状态。

1.1.27. Master_Retry_Count: 86400

连接主库失败最多的重试次数。

1.1.28. Master_Bind:

slave从库在多网络接口的情况下使用，以确定用哪一个slave网络接口连接到master。

1.1.29. Last_IO_Error_Timestamp:

Last_SQL_Error_Timestamp:
最后一次I/O线程或者SQL线程错误时的时间戳。

GTID模式相关

1.1.30. Retrieved_Gtid_Set:

获取到的GTID<IO线程>
Executed_Gtid_Set:
执行过的GTID<SQL线程>
Auto_Position: 0

理解与应用：
1、为什么执行stop slave; 再start slave;可以继续主从关系呢？
其实执行stop slave;就是分别关闭了I/O线程（stop slave IO_THREAD;）和SQL线程（stop slave SQL_THREAD;），I/O线程会维护master.info信息的更新，SQL线程会维护relay-log.info信息的更新，在执行start slave;时候，会依照master.info和relay-log.info信息，继续执行I/O线程和SQL线程。

转载于:https://blog.51cto.com/zhengmingjing/1910565

1.2. RESET命令的用法和解释：

1 RESET MASTER：
删除全部的binlog文件，重置mysql.index文件为空，然后重新生成一个binlog文件。

2 RESET QUERY CACHE:
删除查询缓存。

3 RESET SLAVE:
使从节点忘记它当前复制的位置，它会删除当前的relay log文件，对新的relay-log文件从0开始重新编号，但是不会改变 change master to的配置参数(这些参数是在内存中的)。

4 RESET SLAVE ALL:
是在reset slave的基础上，进一步重置了chagne master to的参数。这样的话，show slave status\G就没有显示。

【一】RESET MASTER参数

功能说明：删除所有的binglog日志文件，并将日志索引文件清空，重新开始所有新的日志文件。用于第一次进行搭建主从库时，进行主库binlog初始化工作；

注意reset master 不同于purge binary log的两处地方

1. reset master 将删除日志索引文件中记录的所有binlog文件，创建一个新的日志文件 起始值从000001 开始，然而purge binary log 命令并不会修改记录binlog的顺序的数值
2. reset master 不能用于有任何slave 正在运行的主从关系的主库。因为在slave 运行时刻 reset master 命令不被支持，reset master 将master 的binlog从000001 开始记录,slave 记录的master log 则是reset master 时主库的最新的binlog,从库会报错无法找的指定的binlog文件。

In MySQL 5.6.5 and later, RESET MASTER also clears the values of the gtid_purged system variable (known as gtid_lost in MySQL 5.6.8 and earlier) as well as the global value of the gtid_executed (gtid_done, prior to MySQL 5.6.9) system variable (but not its session value); that is, executing this statement sets each of these values to an empty string ('')

【二】reset slave

eset slave 将使slave 忘记主从复制关系的位置信息。该语句将被用于干净的启动, 它删除master.info文件和relay-log.info 文件以及所有的relay log 文件并重新启用一个新的relaylog文件。

使用reset slave之前必须使用stop slave 命令将复制进程停止。

注: 所有的relay log将被删除不管他们是否被SQL thread进程完全应用(这种情况发生于备库延迟以及在备库执行了stop slave 命令)，存储复制链接信息的master.info文件将被立即清除,如果SQL thread 正在复制临时表的过程中，执行了stop slave ，并且执行了reset slave，这些被复制的临时表将被删除。

【三】reset slave all

在 5.6 版本中 reset slave 并不会清理存储于内存中的复制信息比如 master host, master port, master user, or master password,也就是说如果没有使用change master 命令做重新定向，执行start slave 还是会指向旧的master 上面。
当从库执行reset slave之后,将mysqld shutdown 复制参数将被重置。

在5.6.3 版本以及以后使用使用 RESET SLAVE ALL 来完全的清理复制连接参数信息。(Bug #11809016)

RESET SLAVE ALL does not clear the IGNORE_SERVER_IDS list set by CHANGE MASTER TO. This issue is fixed in MySQL 5.7. (Bug #18816897)
In MySQL 5.6.7 and later, RESET SLAVE causes an implicit commit of an ongoing transaction. See Section 13.3.3, “Statements That Cause an Implicit Commit”.

posted @ 2025-07-07 11:43 数据库小白（专注）阅读(104) 评论(0) 收藏举报

刷新页面返回顶部

数据库小白（专注）