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 and
           condition2: compare the file names (to handle rotation case)
      */
      if ((mi->get_master_log_pos() == mi->rli->get_group_master_log_pos()) &&
           (!strcmp(mi->get_master_log_name(), mi->rli->get_group_master_log_name())))
      {
        if (mi->slave_running == MYSQL_SLAVE_RUN_CONNECT)    #IO SQL   runing      time_diff=0
          protocol->store(0LL);
        else
          protocol->store_null();
      }
      else
      {
        long time_diff= ((long)(time(0) - mi->rli->last_master_timestamp)    #    
                                - mi->clock_diff_with_master);
      /*
        Apparently on some systems time_diff can be <0. Here are possible
        reasons related to MySQL:
        - the master is itself a slave of another master whose time is ahead.
        - somebody used an explicit SET TIMESTAMP on the master.
        Possible reason related to granularity-to-second of time functions
        (nothing to do with MySQL), which can explain a value of -1:
        assume the master's and slave's time are perfectly synchronized, and
        that at slave's connection time, when the master's timestamp is read,
        it is at the very end of second 1, and (a very short time later) when
        the slave's timestamp is read it is at the very beginning of second
        2. Then the recorded value for master is 1 and the recorded value for
        slave is 2. At SHOW SLAVE STATUS time, assume that the difference
        between timestamp of slave and rli->last_master_timestamp is 0
        (i.e. they are in the same second), then we get 0-(2-1)=-1 as a result.
        This confuses users, so we don't go below 0: hence the max().

        last_master_timestamp == 0 (an "impossible" timestamp 1970) is a
        special marker to say "consider we have caught up".
      */
        protocol->store((longlong)(mi->rli->last_master_timestamp ?
                                   max(0L, time_diff) : 0));                               #diff_tiime< 0   0  。
      }
    }
    else
    {
      protocol->store_null(); #IO SQL   NO，     NO，Seconds_Behind_Master NULL
    }

요약:
1. 위의 소스 코드 부분 에서 보 듯 이 SecondsBehind_마스터 = 현재 노예 시스템 시간 빼 기 sqlthread 가 최근 에 받 은 binlog 의 timestamp 는 master 와 slave 의 시스템 시간 차 를 줄 입 니 다.당직 < 0, 0 으로 처리 되 었 습 니 다.
위 에서 도 볼 수 있 듯 이 (long) (time (0) - mi - > rli - > last master timestamp)   #계산 공식
                                - mi->clock_diff_with_master);
지연 시간 은 master 와 slave 의 시간 대 와 무관 하 다 는 것 을 분석 할 수 있 습 니 다.M +7   S +8  M 은 10 시 에 실 행 됩 니 다. diff_time = (11 - 10) - (11 - 10) = 0, S 가 지연 되 지 않 는 한.
2. IO 또는 SQL 스 레 드 시 NO 또는 동시에 NO, SecondsBehind_Master 는 NULL 입 니 다. 이것 도 복사 가 중단 되 었 을 때 NULL 로 보 입 니 다.
음수 가 나 오 더 라 도 이미 0 으로 처 리 된 것 이 궁금 하 다.
3. * 음수 가 나타 나 는 경우:
1. 인위적인 set master 시스템 시간 은 slave 보다 작 습 니 다.
2. A--->B-->C  ：C 지연 binlog 를 계산 하 는 시간 은 A 의 시간 을 취하 고 주종 이외 의 노드 의 시간 값 에 계산 을 추가 하여 마이너스 가 나타 날 수 있 습 니 다.