Mysql主从复制—判断是否延迟

Posted 翔之天空

tags:

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

 

参考:主从32讲的:27节、从库Seconds_Behind_Master的计算方式

                               28、从库Seconds_Behind_Master延迟总结

 

 

版本:5.7.24

 

 


--一、查看从库状态
mysql> show slave status\\G
*************************** 1. row ***************************
               Slave_IO_State: Connecting to master                //IO线程状态
                  Master_Host: 192.168.56.61                       //连接的master IP
                  Master_User: repl                                //连接的master username
                  Master_Port: 3306                                //连接的master port
                Connect_Retry: 60                                  
             Master_Log_File: mysql-bin.000023                     //IO线程读到的master的binlog
          Read_Master_Log_Pos: 682                                 //IO线程读到的master的binlog的pos
               Relay_Log_File: mysql-relay-bin.000018              //SQL线程执行到的relay log
                Relay_Log_Pos: 4                                   //SQL线程执行到的relay log的pos
        Relay_Master_Log_File: mysql-bin.000023                    //SQL线程执行到对应master的binlog
             Slave_IO_Running: Connecting                          //IO线程状态
            Slave_SQL_Running: Yes                                 //SQL线程状态
              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: 682                                  //SQL线程执行到对应master的binlog的pos
              Relay_Log_Space: 2064
              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差距的时间 单位:秒  (即使是延迟0秒 也可能又复制延迟 详见如下:)
Master_SSL_Verify_Server_Cert: No
                Last_IO_Errno: 2003                                                                                    //最近一个IO线程错误 id
                Last_IO_Error: error connecting to master 'repl@192.168.56.61:3306' - retry-time: 60  retries: 149     //最近一个IO线程错误 log
               Last_SQL_Errno: 0                                                                                       //最近一个SQL线程错误 id
               Last_SQL_Error:                                                                                         //最近一个SQL线程错误 log
  Replicate_Ignore_Server_Ids:
             Master_Server_Id: 0
                  Master_UUID: c959bdb9-f94c-11e9-b3b8-0800277143f5                                                    //master的uuid
             Master_Info_File: mysql.slave_master_info
                    SQL_Delay: 0
          SQL_Remaining_Delay: NULL
      Slave_SQL_Running_State: Slave has read all relay log; waiting for more updates
           Master_Retry_Count: 86400                    
                  Master_Bind:
      Last_IO_Error_Timestamp: 191216 16:44:04
     Last_SQL_Error_Timestamp:
               Master_SSL_Crl:
           Master_SSL_Crlpath:
           Retrieved_Gtid_Set: c959bdb9-f94c-11e9-b3b8-0800277143f5:5-6                                                 //接受到的GTID集合
            Executed_Gtid_Set: c959bdb9-f94c-11e9-b3b8-0800277143f5:1-6,                                                //执行过的GTID集合
f7b23f20-f3ea-11e9-bdb9-080027781379:1-1183171
                Auto_Position: 1                                                                                        //GTID为自动指定位置
         Replicate_Rewrite_DB:
                 Channel_Name:
           Master_TLS_Version:
1 row in set (0.03 sec)






--二、Seconds_Behind_Master 为0秒也可能延迟的情况。

Seconds_Behind_Master的计算:
show_slave_status_send_data 方法

......
if (mi->rli->slave_running)
  
    /*
       Check if SQL thread is at the end of relay log
       Checking should be done using two conditions
       condition1: compare the log positions and
       condition2: compare the file names (to handle rotation case)
    */
    if ((mi->get_master_log_pos() == mi->rli->get_group_master_log_pos()) &&           //1、计算IO线程读取到的主库binlog日志位置和SQL线程在备库应用主库binlog的位置 比较。如果一致说明不延迟 继续
        (!strcmp(mi->get_master_log_name(), mi->rli->get_group_master_log_name())))    //就是判断Read_Master_Log_Pos和Exec_Master_Log_Pos ,Master_Log_File和Relay_Master_Log_File  是否一致
    
      if (mi->slave_running == MYSQL_SLAVE_RUN_CONNECT)
        protocol->store(0LL);                                                          //2、如果IO线程还在 Seconds_Behind_Master为0, 否则 Seconds_Behind_Master为NULL
      else
        protocol->store_null();
    
    else                                                                               
    
      long time_diff= ((long)(time(0) - mi->rli->last_master_timestamp)                //3、如果不一样 说明延迟,就计算相差的时间,就是:Seconds_Behind_Master。 具体计算如下:
                       - mi->clock_diff_with_master);
      protocol->store((longlong)(mi->rli->last_master_timestamp ?
                                   max(0L, time_diff) : 0));
    
  
  else
  
    protocol->store_null();
  
......



time(0):为当前从库的系统时间
mi->clock_diff_with_master: 为主库和备库的系统时间差。只是在从库IO线程启动时候 计算的时间差。可参考 handle_slave_io 线程方法中的 get_master_version_and_clock()方法。 
mi->rli->last_master_timestamp:分为以下的DML和DDL。
DML:dml普通语句 就是 各个EVENT的header的timestamp。  MTS的情况是XID_EVENT的header的timestamp
DDL:就是当前时间(QUERY_EVENT的header的timestamp) + 执行DDL的时间



准确查看:
在传统模式下,查看主库和从库的 binlog 的file和pos 是否一致  主从是否有延迟。
在GTID下,查看主库和从库的 执行过的GTID集合(executed_gtid_set) 是否一致  主从是否有延迟。





 

 

--三、延迟可能:
--1、SQL线程执行完了所有的binlog日志,  Seconds_Behind_Master也显示0  看起来虽然不延迟, 但如果有网络问题导致 IO线程读取的慢  也有延迟的可能性。
--2、如果在从库的IO线程启动后 修改了 从库的系统时间,影响了mi->clock_diff_with_master ,可能会有延迟的可能性。
--3、如果是DML语句,事务长时间没有提交 也可能造成延迟。 但Seconds_Behind_Master 延迟不会从0开始 会突然到这个事务所花费的时间, 因为在开头的GTID_EVENT和结尾XID_EVENT 事件都是事务提交时间(可参考《Mysql—binlog二进制日志 解析》 章节),
--4、如果是DDL语句,大表的DDL操作 也可能造成延迟。 但Seconds_Behind_Master 延迟是从0开始。
--5、没有主键或者索引 造成的延迟,参数slave_rows_search_algorithms(参考《Mysql主从复制的参数—slave_rows_search_algorithms 》 章节 ) 可设置index_scan和hash_scan 但不能完全消除问题。
--6、sync_relay_log=1 参数的设置 导致大量的relay log刷盘 ,可能造成延迟。
--7、从库是否开启了log_slave_updates参数(从库 开启binlog日志)。 如果从库不是级联库  5.7之后可以不开启,降低延迟的可能
--8、行锁和mdl索 操作的影响  有延迟的可能性。
--9、MTS中的slave_checkpoint_period参数。默认300毫秒检查一次。  如果设置为1分钟  可能Seconds_Behind_Master显示延迟可能。 todo.....

以上是关于Mysql主从复制—判断是否延迟的主要内容,如果未能解决你的问题,请参考以下文章

Mysql主从复制—判断是否延迟

MySQL主从同步延迟的原因及解决办法

MySQL主从同步延迟的原因及解决办法

MySQL主从同步延迟的原因及解决办法

mysql 主从复制延迟及解决

关于mysql主从是否正常的判断