MySQL主从延迟Seconds_Behind_Master的计算方式

mysql> show slave status\G
*************************** 1. row ***************************
               Slave_IO_State: Waiting for master to send event
                  Master_Host: xxx.xxx.xxx.xxx
                  Master_User: repl
                  Master_Port: 13307
                Connect_Retry: 60
              Master_Log_File: mysql-bin.000006
          Read_Master_Log_Pos: 304804759
               Relay_Log_File: mysql-relay-bin.000004
                Relay_Log_Pos: 57925450
        Relay_Master_Log_File: mysql-bin.000006
             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: 57925237
              Relay_Log_Space: 304805432
              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: 1749
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: 12713307
                  Master_UUID: fe3729d3-5d01-11e9-b003-061b88000461
             Master_Info_File: mysql.slave_master_info
                    SQL_Delay: 0
          SQL_Remaining_Delay: NULL
      Slave_SQL_Running_State: Waiting for Slave Workers to free pending events
           Master_Retry_Count: 86400
                  Master_Bind: 
      Last_IO_Error_Timestamp: 
     Last_SQL_Error_Timestamp: 
               Master_SSL_Crl: 
           Master_SSL_Crlpath: 
           Retrieved_Gtid_Set: fe3729d3-5d01-11e9-b003-061b88000461:1-100371
            Executed_Gtid_Set: fe3729d3-5d01-11e9-b003-061b88000461:1-27
                Auto_Position: 1
         Replicate_Rewrite_DB: 
                 Channel_Name: 
           Master_TLS_Version: 

mysql> show processlist\G;
*************************** 1. row ***************************
     Id: 2
   User: root
   Host: localhost:59853
     db: NULL
Command: Query
   Time: 0
  State: starting
   Info: show processlist
*************************** 2. row ***************************
     Id: 21
   User: system user
   Host: 
     db: NULL
Command: Connect
   Time: 4095
  State: Waiting for master to send event
   Info: NULL
*************************** 3. row ***************************
     Id: 56
   User: system user
   Host: 
     db: NULL
Command: Connect
   Time: 2
  State: Slave has read all relay log; waiting for more updates
   Info: NULL
*************************** 4. row ***************************
     Id: 57
   User: system user
   Host: 
     db: wxl
Command: Connect
   Time: 1613
  State: altering table
   Info: alter table t1 add names2 varchar(1000) not null
*************************** 5. row ***************************
     Id: 58
   User: system user
   Host: 
     db: NULL
Command: Connect
   Time: 1344
  State: Waiting for an event from Coordinator
   Info: NULL
......
19 rows in set (0.00 sec)

if (SQL thread is running)
{
   if (SQL thread processed all the available relay log)
   {
   if (IO thread is running)
      print 0;
   else
      print NULL;
   }
   else
      compute Seconds_Behind_Master;
}
else
   print NULL;

//判断SQL线程运行是否正常
 if (mi->rli->slave_running)
  {
    /*
      判断io线程拉取的主库最大文件名和位置与SQL线程当前执行的文件和位置是否一致（Master_Log_File=Relay_Master_Log_File 和Read_Master_Log_Pos=Exec_Master_Log_Pos）,即SQL线程是否处理了所有可用的中继日志。
    */
    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())))
    {
      //SQL线程处理了所有可用的中继日志后判断io线程是否正常，正常则将Seconds_Behind_Master设置为0，否则设置为NULL。
      if (mi->slave_running == MYSQL_SLAVE_RUN_CONNECT)
        protocol->store(0LL);
      else
        protocol->store_null();
    }
    else
    {
      long time_diff= ((long)(time(0) - mi->rli->last_master_timestamp)
                       - mi->clock_diff_with_master);
      /*
        当计算后的time_diff如果小于0或者位不可能的值（1970的时间戳）的话，将值修改为0，确保Seconds_Behind_Master不会有负数。
        在某些系统上，可能会出现时间差可以小于0，原因如下：
        1、在级联复制的情况下，当前的主是另外一个主的从，相对于binlog中记录的事务的真正执行时间可能差距较大。
        2、在主上显示的使用set timestamp更改了时间戳
        3、与粒度到秒的时间函数有关（与MySQL本身无关），如：假设主从的时间完全同步，在从机连接到主机的时候，会先读取主机的时间戳（假设为1），并且很短的时候后接着读取从机的时间戳（假设为2）。在线上slave status时，假设slave当前的时间戳和rli->last_master_timestamp之间的差为0（即它们在同一秒内），则最后得到的Seconds_Behind_Master=0-（2-1）=-1，这会迷惑用户。
        
        last_master_timestamp == 0（1970年这个不可能的时间戳）是一个特殊标记，表示为“复制已经赶上了”。
      */
      protocol->store((longlong)(mi->rli->last_master_timestamp ?
                                   max(0L, time_diff) : 0));
    }
  }
  else
  {
    //SQL线程未运行的情况下，将Seconds_Behind_Master设置成NULL
    protocol->store_null();
  }

情况一：
/*
    Even if we don't execute this event, we keep the master timestamp,
      so that seconds behind master shows correct delta (there are events
      that are not replayed, so we keep falling behind).


      If it is an artificial event, or a relay log event (IO thread generated
      event) or ev->when is set to 0, or a FD from master, or a heartbeat
      event with server_id '0' then  we don't update the last_master_timestamp.


      In case of parallel execution last_master_timestamp is only updated when
      a job is taken out of GAQ. Thus when last_master_timestamp is 0 (which
      indicates that GAQ is empty, all slave workers are waiting for events from
      the Coordinator), we need to initialize it with a timestamp from the first
      event to be executed in parallel.  
*/
if ((!rli->is_parallel_exec() || rli->last_master_timestamp == 0) &&
         !(ev->is_artificial_event() || ev->is_relay_log_event() ||
          (ev->common_header->when.tv_sec == 0) ||
          ev->get_type_code() == binary_log::FORMAT_DESCRIPTION_EVENT ||
          ev->server_id == 0))
    {
      rli->last_master_timestamp= ev->common_header->when.tv_sec +
                                  (time_t) ev->exec_time;
      DBUG_ASSERT(rli->last_master_timestamp >= 0);
    }
    
情况二：
另外一种情况是sql线程在等待io线程获取binlog时，会将last_master_timestamp设为0，按上面的算法Seconds_Behind_Master为0，此时任务备库是没有延迟的。
if (!rli->is_parallel_exec())
          rli->last_master_timestamp= 0;

last_master_timestamp= new_ts;


new_ts的计算方式：
/*
  更新rli->last_master_timestamp,如果gaq为空，则将其设置为零。否则，用从机work队列的第一个作业的时间戳更新它。它是在log_event:：get_slave_worker（）函数中分配的。
*/
ts= rli->gaq->empty()
    ? 0
    : reinterpret_cast<Slave_job_group*>(rli->gaq->head_queue())->ts;
  rli->reset_notified_checkpoint(cnt, ts, need_data_lock, true);