MySQL复制中slave延迟监控

Posted

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了MySQL复制中slave延迟监控相关的知识,希望对你有一定的参考价值。

通常是根据 Seconds_Behind_Master 的值来判断slave的延迟。这么做大部分情况下尚可接受,但并不够准确,而应该考虑更多因素。

 

查看slave的状态

mysql> show slave status\G
*************************** 1. row ***************************
               Slave_IO_State: Waiting for master to send event
                  Master_Host: 192.168.0.20
                  Master_User: repl
                  Master_Port: 3306
                Connect_Retry: 60
              Master_Log_File: mysql-bin.000150
          Read_Master_Log_Pos: 226326418
               Relay_Log_File: abce-relay-bin.000003
                Relay_Log_Pos: 77106856
        Relay_Master_Log_File: mysql-bin.000149
             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: 1046292913
              Relay_Log_Space: 330964012
              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: 30510
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
1 row in set (0.00 sec)

mysql> 

从查询结果可以看出,slave落后master的时间是30510秒(即Seconds_Behind_Master的值)

查看一下slave上的复制进程在做什么:

mysql> show full processlist\G
*************************** 1. row ***************************
     Id: 4
   User: system user
   Host: 
     db: NULL
Command: Connect
   Time: 6018
  State: Waiting for master to send event
   Info: NULL
*************************** 2. row ***************************
     Id: 5
   User: system user
   Host: 
     db: abce
Command: Connect
   Time: 30501
  State: updating
   Info: delete from s_item_e
        where
          
           (
             ng_user_id = 23880
             and dt_shift_date in
              (  
                 ‘2017-10-30 00:00:00‘
              , 
                 ‘2017-10-29 00:00:00‘
              ) 
           )
          or  
           (
             ng_user_id = 24853
             and dt_shift_date in
              (  
                 ‘2017-10-30 00:00:00‘
              , 
                 ‘2017-10-29 00:00:00‘
              ) 
           )
		......

sql线程在做updating操作,具体内容是从表中删除数据。Time的值是30501。通常简单的sql不会执行30501秒。

在REPLICATION进程中,Time这列的值还可能有几种情况:
1、SQL线程当前执行的binlog(实际上是relay log)中的timestamp和IO线程最新的timestamp的差值,这就是通常大家认为的Seconds_Behind_Master值,并不是某个SQL的实际执行耗时;
2、SQL线程当前如果没有活跃SQL在执行的话,Time值就是SQL线程的idle time;

而IO线程的Time值则是该线程自从启动以来的总时长(多少秒),如果系统时间在IO线程启动后发生修改的话,可能会导致该Time值异常,比如变成负数,或者非常大。

 

可以根据以下顺序进行延迟的监控:

1.首先比较 Read_Master_Log_Pos 和 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上的差距;

  

查看主库的binary日志:

mysql> SHOW BINARY LOGS;
+------------------+------------+
| Log_name         | File_size  |
+------------------+------------+
| mysql-bin.000142 | 1073778812 |
| mysql-bin.000143 | 1073798740 |
| mysql-bin.000144 | 1073910052 |
| mysql-bin.000145 | 1073781405 |
| mysql-bin.000146 | 1073845859 |
| mysql-bin.000147 | 1073746199 |
| mysql-bin.000148 | 1073863295 |
| mysql-bin.000149 | 1073822822 |
| mysql-bin.000150 |  226343255 |
+------------------+------------+
9 rows in set (0.00 sec)

mysql> 

计算延迟应该是mysql-bin.000149的最大事件数减去已经被执行完的事件数,
即 1073822822 - 1046292913 = 27529909 个binlog event,再加上mysql-bin.000150这个binlog已经产生的226343255个binlog event,共226343255个binlog event。即:1073822822 - 1046292913 + 226343255

 

查看过程中也可以设置pager,只查看关注的几个status值:

mysql> pager cat | egrep -i ‘system user|Exec_Master_Log_Pos|Seconds_Behind_Master|Read_Master_Log_Pos‘
PAGER set to ‘cat | egrep -i ‘system user|Exec_Master_Log_Pos|Seconds_Behind_Master|Read_Master_Log_Pos‘‘
mysql> 

这时有活跃SQL,Time值是30583,Seconds_Behind_Master是30565 
mysql>  show processlist; show slave status\G
|  4 | system user |           | NULL   | Connect |  7168 | Waiting for master to send event | NULL                                                                                                 |
|  5 | system user |           | abce   | Connect | 30583 | updating                         | delete from s_item_e
3 rows in set (0.00 sec)

          Read_Master_Log_Pos: 226364447
          Exec_Master_Log_Pos: 1057661705
        Seconds_Behind_Master: 30565
1 row in set (0.00 sec)

mysql> 

  




以上是关于MySQL复制中slave延迟监控的主要内容,如果未能解决你的问题,请参考以下文章

MySQL 5.7下主从复制延迟解决方案

你遇到过哪些原因造成MySQL异步复制延迟?

zabbix监控mysql主从复制

mysql5.6以上版本的从库延迟复制

MySQL的主从复制延迟问题

MySQL的主从复制延迟问题