show slave status判断主从同步状态

本文详细解析了MySQL主从同步的工作原理及状态监控方法。通过展示show slave status命令的输出结果,介绍了Slave_IO线程与Slave_SQL线程的作用及其常见故障排查技巧。

show slave status\G 会显示主从同步状态

例如

mysql> show slave status\G
*************************** 1. row ***************************
               Slave_IO_State: Waiting for master to send event
                  Master_Host: XXX.XXX.XXX.XXX
                  Master_User: XXX
                  Master_Port: 3306
                Connect_Retry: 60
              Master_Log_File: mysql-bin.000145
 
        Read_Master_Log_Pos: 391789243
               Relay_Log_File: Report-relay-bin.000228
                Relay_Log_Pos: 480230500
        Relay_Master_Log_File: mysql-bin.000144
             Slave_IO_Running: Yes
            Slave_SQL_Running: No

              Replicate_Do_DB: dbXXX
          Replicate_Ignore_DB:
           Replicate_Do_Table:
       Replicate_Ignore_Table:
      Replicate_Wild_Do_Table:
  Replicate_Wild_Ignore_Table:
                   Last_Errno: 1205
                   Last_Error: Slave SQL thread retried transaction 10 time(s) i                                                                                        n vain, giving up. Consider raising the value of the slave_transaction_retries v                                                                                        ariable.
                 Skip_Counter: 0
          Exec_Master_Log_Pos: 480230337
              Relay_Log_Space: 1784477152
              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: NULL
Master_SSL_Verify_Server_Cert: No
                Last_IO_Errno: 0
                Last_IO_Error:
               Last_SQL_Errno: 1205
               Last_SQL_Error: Slave SQL thread retried transaction 10 time(s) i                                                                                        n vain, giving up. Consider raising the value of the slave_transaction_retries v                                                                                        ariable.
  Replicate_Ignore_Server_Ids:
             Master_Server_Id: 1
                  Master_UUID: 07b51a82-dcd0-11e4-a812-00163e020999
             Master_Info_File: /mnt/erp/programdata/data/master.info
                    SQL_Delay: 0
          SQL_Remaining_Delay: NULL
      Slave_SQL_Running_State:
           Master_Retry_Count: 86400
                  Master_Bind:
      Last_IO_Error_Timestamp:
     Last_SQL_Error_Timestamp: 150815 01:42:34
               Master_SSL_Crl:
           Master_SSL_Crlpath:
           Retrieved_Gtid_Set:
            Executed_Gtid_Set:
                Auto_Position: 0
1 row in set (0.00 sec)


其中首先关注的是两个线程的状态

  Slave_IO_Running: Yes
  Slave_SQL_Running: No

Yes表示正常,No表示异常

  Slave_IO线程负责把主库的bin日志(Master_Log)内容,抄写到从库的中继日志上(Relay_Log)。

  Slave_SQL线程负责把中继日志上的语句在从库上执行一遍。


Slave_IO线程相对比较简单,一般不容易出错,如果Slave_IO_Running显示为No,多为网络连接不上,权限不够等环境问题。

相对的Slave_SQL线程就比较容易出错,例如人为手动的在从库插入一条数据,造成主从不一致。但此时两个线程的状态任然是正常的,

等到主库也插入一条同样的数据时,通知从库做相同操作,从库会出现主键重复的错误。此时Slave_SQL_Running的状态会变为No,

而Last_SQL_Error,Last_SQL_Error_Timestamp会记录错误的原因和发生时间。

Slave_SQL线程会停止后续的SQL语句执行,因为它意识到往后执行会导致错误修复的难度增加。

但Slave_IO线程会继续抄log的工作。所以中继log依然是最新的。

这时候Master_Log_File: mysql-bin.000145 和  Relay_Master_Log_File: mysql-bin.000144之间就产生了偏差。

例如上面的情况,主库的日志已经写到了 mysql-bin.000145,而从库依然停留在 mysql-bin.000144等待人工修复错误。

那么当错误修复后,只需用stop slave和start slave重启下同步。Slave_SQL线程会重新的尝试工作。

如果没有问题,那么Slave_SQL的状态会变回Yes。但此时主从并没有完全同步,需要一点时间。

如何判断主从完全同步呢?

首先Master_Log_File和Relay_Master_Log_File所指向的文件必须一致。

其次Relay_Log_Pos和Exec_Master_Log_Pos的为止也要一致才行。

此时,Slave_SQL_Running_State:显示为wait 意思是中继日志的sql语句已经全部执行完毕,我没事作了


<think>嗯,用户的问题是如何查看MySQL主从同步状态。用户应该是数据库管理员或开发者,需要监控从复制的运行情况。 从引用内容来看,核心方法是使用`SHOW SLAVE STATUS\G`命令。关键指标有两个线程状态Slave_IO_Running和Slave_SQL_Running,需要同时为"Yes"才正常。引用3详细解释了这两个线程的作用和常见问题。 用户可能遇到主从同步异常的情况,所以需要补充常见错误场景和处理方法。比如网络中断导致IO线程停止,或者键冲突导致SQL线程停止。引用3提到可以用`sql_slave_skip_counter`跳过错误,但要注意这是应急方案。 考虑到用户可能需要深入排查,应该补充同步延迟的监控方法(Seconds_Behind_Master字段)和完全同步判断标准(日志文件和位置点一致)。引用3提到Master_Log_File和Relay_Master_Log_File必须一致这个细节很重要。 用户没有说明环境,所以补充了从库和库两种查看方式。如果是从库,用`SHOW SLAVE STATUS`;如果是库,可以用`SHOW SLAVE HOSTS`看从库连接情况。 最后需要强调安全操作:不要在从库直接写数据,避免键冲突。这点引用3也重点提醒了,因为人为操作导致SQL线程停止是最常见的问题之一。 相关问题设计要覆盖监控(如何实时监控)、优化(延迟处理)、故障(键冲突)和架构(半同步)等维度,这样用户后续遇到问题也能找到方向。</think>要查看MySQL主从同步状态要通过执行 `SHOW SLAVE STATUS` 命令实现。以下是详细步骤和关键指标解读: ### 查看方法 1. **连接到从库服务器** 使用MySQL客户端登录**从库**数据库: ```bash mysql -u用户名 -p密码 ``` 2. **执行状态查询命令** 在MySQL命令行执行: ```sql SHOW SLAVE STATUS\G ``` `\G` 替代分号可使结果垂直显示,便于阅读。 ### 关键指标解读(重点关注) | 字段名 | 正常值 | 说明 | |-------------------------|--------|----------------------------------------------------------------------| | `Slave_IO_Running` | `Yes` | I/O线程状态:负责从库拉取binlog到从库中继日志 | | `Slave_SQL_Running` | `Yes` | SQL线程状态:负责执行中继日志中的SQL语句 | | `Last_IO_Error` | 空 | I/O线程最后一次错误信息(为空表示正常) | | `Last_SQL_Error` | 空 | SQL线程最后一次错误信息(为空表示正常) | | `Seconds_Behind_Master` | `0` | 从库落后库的秒数(`0`=实时同步,`NULL`=异常) | | `Master_Log_File` | 一致 | 库当前binlog文件名,应与`Relay_Master_Log_File`相同 | | `Read_Master_Log_Pos` | 一致 | I/O线程读取库binlog的位置,应与库`SHOW MASTER STATUS`的`Position`匹配 | ### 同步状态判断 1. **完全同步**需同时满足: ```sql Slave_IO_Running = 'Yes' AND Slave_SQL_Running = 'Yes' AND Seconds_Behind_Master = 0 AND Master_Log_File = Relay_Master_Log_File -- 日志文件一致 AND Read_Master_Log_Pos = Exec_Master_Log_Pos -- 日志位置一致 ``` 2. **常见异常处理**: - **`Slave_IO_Running: No`** 通常因网络中断、库权限不足或binlog损坏导致。需检查: ```sql SHOW GRANTS FOR 'repl_user'@'从库IP'; -- 验证复制账号权限 SHOW MASTER STATUS; -- 库确认binlog状态 ``` - **`Slave_SQL_Running: No`** 多由从库写入冲突(如手动插入数据)引起。应急恢复: ```sql STOP SLAVE; SET GLOBAL sql_slave_skip_counter = 1; -- 跳过1个错误事件 START SLAVE; ``` > **警告**:跳过错误需人工确认数据一致性![^3] ### 补充命令 - **查看从库连接**: ```sql SHOW SLAVE HOSTS; -- 显示所有连接的从库 ``` - **查看binlog状态**: ```sql SHOW MASTER STATUS; -- 获取当前binlog文件及写入位置 ``` > **重要提示**:禁止直接在从库执行写操作(`INSERT/UPDATE/DELETE`),否则必然导致从中断![^3] ---
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值