MySQL 发生同步延迟时Seconds_Behind_Master还为0的原因


Posted in MySQL onJune 21, 2021
目录
  • 问题描述
  • 原理简析
  • 问题分析
  • 拓展一下
  • 总结一下

 

问题描述

用户在主库上执行了一个 alter 操作,持续约一小时。操作完成之后,从库发现存在同步延迟,但是监控图表中的 Seconds_Behind_Master 指标显示为 0,且 binlog 的延迟距离在不断上升。

 

原理简析

既然是分析延迟时间,那么自然先从延迟的计算方式开始入手。为了方便起见,此处引用官方版本 5.7.31 的源代码进行阅读。找到计算延迟时间的代码:

./sql/rpl_slave.cc

bool show_slave_status_send_data(THD *thd, Master_info *mi,
                                 char* io_gtid_set_buffer,
                                 char* sql_gtid_set_buffer)
......
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)
        protocol->store(0LL);
      else
        protocol->store_null();
    }
    else
    {
      long time_diff= ((long)(time(0) - mi->rli->last_master_timestamp)
                       - mi->clock_diff_with_master);

      protocol->store((longlong)(mi->rli->last_master_timestamp ?
                                   max(0L, time_diff) : 0));
    }
......

从 time_diff 的计算方式来看,可以发现这个延迟基本上就是一个时间差值,然后再算上主从之间的时间差。不过 if 挺多的,所以借用源代码文件中的注释:

/*
     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
            print NULL;
       }
        else
          compute Seconds_Behind_Master;
      }
      else
       print NULL;
  */

可以知道,Seconds_Behind_Master的计算分为两个部分:

  • SQL 线程正常,且回放完所有的 relaylog 时,如果 IO 线程正常,那么直接置 0。
  • SQL 线程正常,且回放完所有的 relaylog 时,如果 IO 线程不正常,那么直接置 NULL。
  • SQL 线程正常,且没有回放完所有的 relaylog 时,计算延迟时间。

那么在最后计算延迟时间的时候,看看那几个变量代表的意义:

  • time(0):当前的时间戳,timestamp 格式的。
  • last_master_timestamp:这个 event 在主库上执行的时刻,timestamp 格式。
  • clock_diff_with_master:slave 和 master 的时间差,在 IO 线程启动时获取的。

由此可见,延迟计算的时候,实际上是以 slave 本地的时间来减掉回放的这个 event 在 master 执行的时刻,再补偿两者之间的时间差,最后得到的一个数值。从逻辑上看是没什么问题的,由于 time(0) 和 clock_diff_with_master 在大多数时候是没有什么出问题的机会的,所以这次的问题,应该是出在 last_master_timestamp 上了。

PS:虽说大部分时候没问题,但是 time(0) 取的是本地时间,因此 slave 的本地时间有问题的话,这个最终的值也会出错,不过不在本案例的问题讨论范围之内了。

那么找一下执行 event 的时候,计算last_master_timestamp的逻辑,结合注释可以发现普通复制和并行复制用了不同的计算方式,第一个是普通的复制,计算时间点在执行 event 之前:

./sql/rpl_slave.cc

......
  if (ev)
  {
    enum enum_slave_apply_event_and_update_pos_retval exec_res;

    ptr_ev= &ev;
    /*
      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);
    }
......

last_master_timestamp的值是取了 event 的开始时间并加上执行时间,在 5.7 中有不少 event 是没有执行时间这个数值的,8.0 给很多 event 添加了这个数值,因此也算是升级 8.0 之后带来的好处。

而并行复制的计算方式,参考如下这一段代码:

./sql/rpl\_slave.cc

......
  /*
    We need to ensure that this is never called at this point when
    cnt is zero. This value means that the checkpoint information
    will be completely reset.
  */

  /*
    Update the rli->last_master_timestamp for reporting correct Seconds_behind_master.

    If GAQ is empty, set it to zero.
    Else, update it with the timestamp of the first job of the Slave_job_queue
    which was assigned in the Log_event::get_slave_worker() function.
  */
  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);
  /* end-of "Coordinator::"commit_positions" */

......

在 Coordinator 的 commit_positions 这个逻辑中,如果 gaq 队列为空,那么last_master_timestamp直接置 0,否则会选择 gaq 队列的第一个 job 的时间戳。需要补充一点的是,这个计算并不是实时的,而是间歇性的,在计算逻辑前面,有如下的逻辑:

/*
    Currently, the checkpoint routine is being called by the SQL Thread.
    For that reason, this function is called call from appropriate points
    in the SQL Thread's execution path and the elapsed time is calculated
    here to check if it is time to execute it.
  */
  set_timespec_nsec(&curr_clock, 0);
  ulonglong diff= diff_timespec(&curr_clock, &rli->last_clock);
  if (!force && diff < period)
  {
    /*
      We do not need to execute the checkpoint now because
      the time elapsed is not enough.
    */
    DBUG_RETURN(FALSE);
  }

即在这个 period 的时间间隔之内,会直接 return,并不会更新这个last_master_timestamp,所以有时候也会发现并行复制会时不时出现 Seconds_Behind_Master 在数值上从 0 到 1 的变化。

而 gaq 队列的操作,估计是类似于入栈退栈的操作,所以留在 gaq 的总是没有执行完的事务,因此时间计算从一般场景的角度来看是没问题。

 

问题分析

原理简析中简要阐述了整个计算的逻辑,那么回到这个问题本身,腾讯云数据库 MySQL 默认是开启了并行复制的,因此会存在 gaq 队列,而 alter 操作耗时非常的长,不论 alter 操作是否会被放在一组并行事务中执行(大概率,DDL 永远是一个单独的事务组),最终都会出现 gaq 队列持续为空,那么就会把last_master_timestamp置 0,而参考 Seconds_Behind_Master 的计算逻辑,最终的 time_diff 也会被置 0,因此 alter 操作结束前的延迟时间一直会是 0。而当 alter 操作执行完之后,gaq 队列会填充新的 event 和事务,所以会出现延迟之前一直是 0,但是突然跳到非常高的现象。

 

拓展一下

对比普通复制和并行复制计算方式上的差异,可以知道以下几个特点:

  • 开启并行复制之后,延迟时间会经常性的在 0 和 1 之间跳变。
  • alter 操作,单个大事务等在并行复制的场景下容易导致延迟时间不准,而普通的复制方式不会。
  • 由于主从时间差是在 IO 线程启动时就计算好的,所以期间 slave 的时间出现偏差之后,延迟时间也会出现偏差。

 

总结一下

严谨的延迟判断,还是依靠 GTID 的差距和 binlog 的 position 差距会比较好,从 8.0 的 event 执行时间变化来看,至少 Oracle 官方还是在认真干活的,希望这些小毛病能尽快的修复吧。

以上就是MySQL 发生同步延迟时Seconds_Behind_Master还为0的原因的详细内容,更多关于MySQL 同步延迟Seconds_Behind_Master为0的资料请关注三水点靠木其它相关文章!

MySQL 相关文章推荐
MySQL表的增删改查(基础)
Apr 05 MySQL
MySQL通过binlog恢复数据
May 27 MySQL
MySQL中in和exists区别详解
Jun 03 MySQL
MySQL系列之开篇 MySQL关系型数据库基础概念
Jul 02 MySQL
MySQL一些常用高级SQL语句
Jul 03 MySQL
MySQL约束超详解
Sep 04 MySQL
Mysql Innodb存储引擎之索引与算法
Feb 15 MySQL
Mysql数据库表中为什么有索引却没有提高查询速度
Feb 24 MySQL
关于k8s环境部署mysql主从的问题
Mar 13 MySQL
MySQL 主从复制数据不一致的解决方法
Mar 18 MySQL
聊聊mysql都有哪几种分区方式
Apr 13 MySQL
MySQL安装失败的原因及解决步骤
Jun 14 MySQL
分析mysql中一条SQL查询语句是如何执行的
MySQL如何使用使用Xtrabackup进行备份和恢复
Jun 21 #MySQL
MySQL 数据恢复的多种方法汇总
Jun 21 #MySQL
Mysql数据库值的添加、修改、删除及清空操作实例
Unity连接MySQL并读取表格数据的实现代码
新手入门Mysql--sql执行过程
MySQL 外键约束和表关系相关总结
Jun 20 #MySQL
You might like
PHP 5.0对象模型深度探索之属性和方法
2008/03/27 PHP
C# Assembly类访问程序集信息
2009/06/13 PHP
php 获取一个月第一天与最后一天的代码
2010/05/16 PHP
php图像处理类实例
2015/07/28 PHP
WordPress中设置Post Type自定义文章类型的实例教程
2016/05/10 PHP
Laravel中如何增加自定义全局函数详解
2017/05/09 PHP
javascript基础知识大集锦(二) 推荐收藏
2011/01/13 Javascript
跨浏览器通用、可重用的选项卡tab切换js代码
2011/09/20 Javascript
Jquery修改页面标题title其它JS失效的解决方法
2014/10/31 Javascript
JS获取html元素的标记名实现方法
2016/10/08 Javascript
JS组件系列之MVVM组件 vue 30分钟搞定前端增删改查
2017/04/28 Javascript
AngularJS表单验证功能
2017/10/19 Javascript
jQuery.extend 与 jQuery.fn.extend的用法及区别实例分析
2018/07/25 jQuery
解决vue-cli单页面手机应用input点击手机端虚拟键盘弹出盖住input问题
2018/08/25 Javascript
解决vue单页面 回退页面 keeplive 缓存问题
2020/07/22 Javascript
如何利用JavaScript编写更好的条件语句详解
2020/08/10 Javascript
python中列表的含义及用法
2020/05/26 Python
在tensorflow以及keras安装目录查询操作(windows下)
2020/06/19 Python
python文件读取失败怎么处理
2020/06/23 Python
详解Python高阶函数
2020/08/15 Python
Agoda台湾官网:国内外订房2折起
2018/03/20 全球购物
7 For All Mankind官网:美国加州洛杉矶的高级牛仔服装品牌
2018/12/20 全球购物
Sisley法国希思黎中国官网:享誉全球的奢华植物美容品牌
2019/06/30 全球购物
几个判断型的面试题
2012/07/03 面试题
卫校中专生的自我评价
2014/01/15 职场文书
公司请假条范文
2014/04/11 职场文书
员工安全承诺书
2014/05/22 职场文书
研修心得体会
2014/09/04 职场文书
学校政风行风整改方案
2014/10/25 职场文书
优秀教师单行材料
2014/12/16 职场文书
2015年审计人员工作总结
2015/05/26 职场文书
企业财务管理制度范本
2015/08/04 职场文书
导游词之南京夫子庙
2019/12/09 职场文书
python实现简单的聊天小程序
2021/07/07 Python
Spring Boot配合PageHelper优化大表查询数据分页
2022/04/20 Java/Android
java开发双人五子棋游戏
2022/05/06 Java/Android