Seconds_Behind_Master的计算

     MySQL复制中seconds_behind_master的计算

1.seconds_behind_master定义为从库相对于主库的延迟时间。
    具体的计算公式为:
        clock_of_slave - last_timestamp_executed_by_SQL_thread-clock_diff_with_master.

    备注:位于rpl_mi.h中定义了clock_diff_with_master,该值为从库相对于主库的时间差。
          /*
     The difference in seconds between the clock of the master and the clock of
     the slave (second - first). It must be signed as it may be <0 or >0.
     clock_diff_with_master is computed when the I/O thread starts; for this the
     I/O thread does a SELECT UNIX_TIMESTAMP() on the master.
     "how late the slave is compared to the master" is computed like this:
     clock_of_slave - last_timestamp_executed_by_SQL_thread - clock_diff_with_master
  */
  long clock_diff_with_master;
  //  clock_diff_with_master
  // mi->clock_diff_with_master=
      (long) (time((time_t*) 0) - strtoul(master_row[0], 0, 10));
      master_row[0]就是在主库上执行SELECT UNIX_TIMESTAMP()的操作。
      从如下到(rpl_slave.cc)可以看出:
      start_slave_thread->  //启动start slave
            handle_slave_io-> //启动start io thread
                get_master_version_and_clock //获取当前slave和主机之间的时间差(clock_diff_with_master)

   /*
    Used to defer stopping the SQL thread to give it a chance
    to finish up the current group of events.
    The timestamp is set and reset in @c sql_slave_killed().
  */
  time_t last_event_start_time; //slave端最后执行的reply log的最后一个事件的时间
时间: 2024-11-02 20:09:16

Seconds_Behind_Master的计算的相关文章

MySQL &#183; 答疑解惑 &#183; 备库Seconds_Behind_Master计算

背景 在mysql主备环境下,主备同步过程如下,主库更新产生binlog, 备库io线程拉取主库binlog生成relay log.备库sql线程执行relay log从而保持和主库同步. 理论上主库有更新时,备库都存在延迟,且延迟时间为备库执行时间+网络传输时间即t4-t2. 那么mysql是怎么来计算备库延迟的? 先来看show slave status中的一些信息,io线程拉取主库binlog的位置: Master_Log_File: mysql-bin.000001 Read_Maste

MySQL主从不一致情形与解决方法

一.MySQL主从不同步情况 1.1 网络的延迟 由于mysql主从复制是基于binlog的一种异步复制 通过网络传送binlog文件,理所当然网络延迟是主从不同步的绝大多数的原因,特别是跨机房的数据同步出现这种几率非常的大,所以做读写分离,注意从业务层进行前期设计. 1.2 主从两台机器的负载不一致 由于mysql主从复制是主数据库上面启动1个io线程,而从上面启动1个sql线程和1个io线程,当中任何一台机器的负载很高,忙不过来,导致其中的任何一个线程出现资源不足,都将出现主从不一致的情况.

MySQL Replication--复制延迟(Seconds_Behind_Master)计算01

本人完全不懂MySQL源码,以下文字纯属瞎猜,如有误导,概不负责! 在sql/rpl_slave.cc文件中,time_diff的计算代码为: /* The pseudo code to compute Seconds_Behind_Master: if (SQL thread is running) { if (SQL thread processed all the available relay log) { if (IO thread is running) print 0; else

seconds_behind_master监控复制延迟的不足及pt-heartbeat改进方法

seconds_behind_master含义及不足 seconds_behind_master的值是通过将salve服务器当前的时间戳与二进制日志中的事件的时间戳相比得到的,所以只有执行事件时才会报告延迟. 1.1  如果备库复制线程没有运行,就会报延迟为null. 1.2  一些错误比如网络不稳定可能导致复制中断或停止复制线程,但是seconds_behind_master将显示为0,而不是显示错误 1.3  即使备库线程正在运行,备库有时候可能无法计算延时,如果发生这种情况,备库会报0或者

Seconds_Behind_Master之困惑与解释

1.以前一直对这个参数很模糊,今天闲下心来看源码文件 sql/rpl_slave.cc (MySQL 5.6.16) 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 an

MySQL slave状态之Seconds_Behind_Master

在MySQL的主从环境中,我们能够通过在slave上运行show slave status来查看slave的一些状态信息,当中有一个比較重要的參数Seconds_Behind_Master.那么你是否明确它的真正含义以及它是怎么计算的呢? 在之前我一直误以为Seconds_Behind_Master是表示slave比master落后多少,假设这个值为0的表示主从已经处于一致了(在非同步模式下,如今官方最多也仅仅在5.5中添加?了半同步复制).可是近期我最终认识到之前的错误理解.首先我们须要明确的

再议Seconds_Behind_Master

两年前就写过一篇文章解释Seconds_Behind_Master代表的含义以及它为什么不准确,今天同事高老师又提了一个有趣的问题:Seconds_Behind_Master到底是怎么计算的呢?高老师还特地去翻了一下源码来解释,我发现我之前的理解还是有出入的,于是自己也动手去翻了一下源码,下面就来更全面的解释一下它是怎么计算的,为什么不能完全可信. 我平时读MySQL源码比较少,一般来说通过源码也是查一些基本的问题,对于我来说如果对关键代码位置不熟,比较快捷的方法就是cd到源码的根目录,然后gr

MySQL slave状态之Seconds_Behind_Master zz

在MySQL的主从环境中,我们可以通过在slave上执行show slave status来查看slave的一些状态信息,其中有一个比较重要的参数Seconds_Behind_Master.那么你是否明白它的真正含义以及它是怎么计算的呢? 在之前我一直误以为Seconds_Behind_Master是表示slave比master落后多少,如果这个值为0的表示主从已经处于一致了(在非同步模式下,现在官方最多也只在5.5中增加了半同步复制).但是最近我终于认识到之前的错误理解.首先我们需要明白的一点

Mysql slave 状态之Seconds_Behind_Master

在MySQL的主从环境中,我们可以通过在slave上执行show slave status来查看slave的一些状态信息,其中有一个比较重要的参数Seconds_Behind_Master.那么你是否明白它的真正含义以及它是怎么计算的呢? 在之前我一直误以为Seconds_Behind_Master是表示slave比master落后多少,如果这个值为0的表示主从已经处于一致了(在非同步模式下,现在官方最多也只在5.5中增加了半同步复制).但是最近我终于认识到之前的错误理解.首先我们需要明白的一点