二十三:从库的SQL 线程(MTS协调线程)和sql_slave_skip_counter参数(笔记)

本文涉及的产品
RDS MySQL Serverless 基础系列,0.5-2RCU 50GB
云数据库 RDS PostgreSQL,高可用系列 2核4GB
云数据库 RDS MySQL,高可用系列 2核4GB
简介: 一、调用流程大概如下handle_slave_sql ->是否开启了slave_preserve_commit_order和log_slave_updates参数,开启的话需要设置提交顺序管理器 if (opt_slave_preserve_commit_order && rli->op...

一、调用流程大概如下

handle_slave_sql
 ->是否开启了slave_preserve_commit_order和log_slave_updates参数,开启的话需要设置提交顺序管理器
   if (opt_slave_preserve_commit_order && rli->opt_slave_parallel_workers > 0 &&
       opt_bin_log && opt_log_slave_updates)
     commit_order_mngr= new Commit_order_manager(rli->opt_slave_parallel_workers); //order commit 管理器
 
   rli->set_commit_order_manager(commit_order_mngr);
 ->如果是MTS则需要启动worker线程
   if (slave_start_workers(rli, rli->opt_slave_parallel_workers, &mts_inited) != 0)//启动worker线程
  {
    mysql_cond_broadcast(&rli->start_cond);
    mysql_mutex_unlock(&rli->run_lock);
    rli->report(ERROR_LEVEL, ER_SLAVE_FATAL_ERROR, ER(ER_SLAVE_FATAL_ERROR),
                "Failed during slave workers initialization");
    goto err;
  ->检查rep table是否是事务类型的如果不是则报警告
     if (!rli->is_transactional()) //是否是 table或者是file类型是table类型则支持事物
    rli->report(WARNING_LEVEL, 0,
    "If a crash happens this configuration does not guarantee that the relay "
    "log info will be consistent");
  -> 初始化 relay log 的访问位置
      if (rli->init_relay_log_pos(rli->get_group_relay_log_name(),
                              rli->get_group_relay_log_pos(),
                              true/*need_data_lock=true*/, &errmsg,
                              1 /*look for a description_event*/)) //初始化 relay log 的访问位置
     这个位置比较关键也就是从哪里开始读取我们的relay log。如果出现错误将会导致读取的relay log错误。
     因此我们需要保证rep info的安全,如果设置了recover relay log 那么将会初始化为最新一个relay log的
     开始位置,因为所有的未执行的binlog event将会从新拉取,老的relay log 已经不重要了。后面再说。
     
  -> GTID event没有办法使用sql_slave_skip_counter 其具体含义参考:
    Log_event::do_shall_skip
  
    mysql> set global sql_slave_skip_counter=1;
    ERROR 1858 (HY000): sql_slave_skip_counter can not be set when the server is running with 
    @@GLOBAL.GTID_MODE = ON. Instead, for each transaction that you want to skip, generate an 
    empty transaction with the same GTID as the transaction
   
  进入循环 知道SQL线程被杀死
  
  -> 进入状态stage_reading_event_from_the_relay_log
  -> 进行一段skip event的判断和日志输出
  
    GTID event没有办法使用sql_slave_skip_counter 其具体含义参考:
    Log_event::do_shall_skip
  
    mysql> set global sql_slave_skip_counter=1;
    ERROR 1858 (HY000): sql_slave_skip_counter can not be set when the server is running with 
    @@GLOBAL.GTID_MODE = ON. Instead, for each transaction that you want to skip, generate an 
    empty transaction with the same GTID as the transaction  
    
  -> exec_relay_log_event 读取应用 一个event的上层接口
    ->next_event 读取下一个Event 完成MTS的检查点
      ->获取开始位置 rli->set_event_start_pos(my_b_tell(cur_log));
      ->Log_event::read_log_event
      
      ->如果是MTS 是否需要进行检查点
        1、是否超过检查点周期
           周期检查在函数mts_checkpoint_routine内部
           
             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);
              }
           
        2、是否已经GAQ已经满了 
          bool force= (rli->checkpoint_seqno > (rli->checkpoint_group - 1)); //如果达到了 GAQ的大小 设置为force 强制checkpoint 
           
      ->是否relay log 大小已经达到最大 是否需要relay log切换
        但是需要注意如果本事物没有结束不能进行切换
        
    /*                                                                                                                                          
              If we have reached the limit of the relay space and we  如果我们达到 relay_log_space_limit 上限 需要通知IO THREAD进行切换 清理空间```
              are going to sleep, waiting for more events:                                                                                      
                                                                                                                                             
              1. If outside a group, SQL thread asks the IO thread                                                                              
                 to force a rotation so that the SQL thread purges                                                                              
                 logs next time it processes an event (thus space is                                                                            
                 freed).                                                                                                                        
                                                                                                                                        
              2. If in a group, SQL thread asks the IO thread to                                                                                
                 ignore the limit and queues yet one more event                                                                                 
                 so that the SQL thread finishes the group and                                                                                  
                 is are able to rotate and purge sometime soon.                                                                                 
             */                                                                                                                                 
            if (rli->log_space_limit &&                                                                                                         
                rli->log_space_limit < rli->log_space_total)                                                                                    
            {                                                                                                                                   
              /* force rotation if not in an unfinished group */                                                                                
              if (!rli->is_parallel_exec())                                                                                                     
              {                                                                                                                                 
                rli->sql_force_rotate_relay= !rli->is_in_group(); //如果不是一组就需要切换                                                      
              }                                                                                                                                 
              else                                                                                                                              
              {                                                                                                                                 
                rli->sql_force_rotate_relay=                                                                                                    
                  (rli->mts_group_status != Relay_log_info::MTS_IN_GROUP);                                                                      
              }                                                                                                                                 
              /* ask for one more event */                                                                                                      
              rli->ignore_log_space_limit= true;//是一组 不能切换                                                                               
            }           
->如果读取了当前relay log的全部的relay log event,
 ->如果是当前relay log
   ->空闲状态下等待io 线程的唤醒,如果是MTS还需要定期醒来进行检查点,如下:
         if (rli->is_parallel_exec() && (opt_mts_checkpoint_period != 0 ||
          DBUG_EVALUATE_IF("check_slave_debug_group", 1, 0)))
      {
        int ret= 0;
        struct timespec waittime;
        ulonglong period= static_cast<ulonglong>(opt_mts_checkpoint_period * 1000000ULL);
        ulong signal_cnt= rli->relay_log.signal_cnt;
     
        mysql_mutex_unlock(log_lock);
        do
        {
          /*
            At this point the coordinator has no job to delegate to workers.
            However, workers are executing their assigned jobs and as such
            the checkpoint routine must be periodically invoked.
          */
          (void) mts_checkpoint_routine(rli, period, false, true/*need_data_lock=true*/); // TODO: ALFRANIO ERROR
          mysql_mutex_lock(log_lock);
     
          if (DBUG_EVALUATE_IF("check_slave_debug_group", 1, 0))
            period= 10000000ULL;
     
          set_timespec_nsec(&waittime, period);
          ret= rli->relay_log.wait_for_update_relay_log(thd, &waittime);
        } while ((ret == ETIMEDOUT || ret == ETIME) /* todo:remove */ &&
                 signal_cnt == rli->relay_log.signal_cnt && !thd->killed);
      }
      else
      {
        rli->relay_log.wait_for_update_relay_log(thd, NULL); //等待relay log 更改的信号 SQL THREAD 会等待在这里
      }        
         -> 如果不是当前relay log 那么 SQL线程应用或者分发完成完成后就可以清理了
            并且参数relay_log_purge需要设置为1     
            
            if (rli->relay_log.purge_first_log
            (rli,
rli->get_group_relay_log_pos() == rli->get_event_relay_log_pos()
&& !strcmp(rli->get_group_relay_log_name(),rli->get_event_relay_log_name())))//做relay log的清理
            
    -> 如果是单SQL现成 获取event的时间
       这一步 就是获取计算延迟的重要因素,但是注意MTS不是在这里实在检查点里面
       last_master_timestamp
   rli->last_master_timestamp= ev->common_header->when.tv_sec + //event header 的timestamp
                              (time_t) ev->exec_time; //获取event的 timestamp作为 计算last_master_timestamp的基础数据 query event才有的执行时间
   DBUG_ASSERT(rli->last_master_timestamp >= 0);       //但是对于MTS来讲应该注意是最后一个XID EVENT的 时间不是这里设置的 在mts_checkpoint_routine里面

    -> 如果GITD_MODE 且AUTO_POSITION 且是MTS需要由协调线程进行半事物的恢复 (partial transaction)    
构造回滚EVENT进行恢复,而对已非MTS会在gtid event做回滚。
这种情况可能出现在:
- AUTO_POSITION情况下如果重连,会重新发送已经传输的Event。
- AUTO_POSITION情况下如果从库异常宕机重启,并且recovery_relay_log=0的情况下,会重新发送已经传输的Event,并且relay log pos不会重置

因此我们前面在IO线程和DUMP线程中已经讨论了,每次sql线程的启动都会通过GTID去重新寻找需要拉取的
位置。

coord_handle_partial_binlogged_transaction(rli, ev) 

    -> apply_event_and_update_pos 非MTS 完成 应用 MTS完成分发
      -> 进行skip event操作
  
      -> 维护skip counter计数器
    if (reason == Log_event::EVENT_SKIP_COUNT)
       {
         --rli->slave_skip_counter;//维护skip count
         skip_event= TRUE;
       }
  我们看到slave_skip_counter是以event为单位的,但是对于最后一个event如果跨事务了
  那么整个事物都需要跳过。但是skip在GTID模式下是不能用的。       
      -> 如果不能跳过的事务 就需要应用了。MTS则完成分发
  ->完成延迟应用逻辑
    sql_delay_event(ev, thd, rli)
    
  ->ev->apply_event(rli); 这里单SQL线程应用 MTS完成分发,分发方式参考前面
    ->是否是进行 MTS recovery if (rli->is_mts_recovery())
       根据 bitmap 设置进行跳过处理 
      
        if (rli->is_mts_recovery())//如果是恢复 这个地方就是前面恢复扫描出来的位置
        {
          bool skip=
            bitmap_is_set(&rli->recovery_groups, rli->mts_recovery_index) &&
            (get_mts_execution_mode(::server_id,
                                    rli->mts_group_status ==
                                    Relay_log_info::MTS_IN_GROUP,
                                    rli->current_mts_submode->get_type() ==
                                    MTS_PARALLEL_TYPE_DB_NAME)
             == EVENT_EXEC_PARALLEL);
          if (skip)
          {
            DBUG_RETURN(0);
          }
          else
          {
            DBUG_RETURN(do_apply_event(rli));
          }
        }
     
相关实践学习
每个IT人都想学的“Web应用上云经典架构”实战
本实验从Web应用上云这个最基本的、最普遍的需求出发,帮助IT从业者们通过“阿里云Web应用上云解决方案”,了解一个企业级Web应用上云的常见架构,了解如何构建一个高可用、可扩展的企业级应用架构。
MySQL数据库入门学习
本课程通过最流行的开源数据库MySQL带你了解数据库的世界。 &nbsp; 相关的阿里云产品:云数据库RDS MySQL 版 阿里云关系型数据库RDS(Relational Database Service)是一种稳定可靠、可弹性伸缩的在线数据库服务,提供容灾、备份、恢复、迁移等方面的全套解决方案,彻底解决数据库运维的烦恼。 了解产品详情:&nbsp;https://www.aliyun.com/product/rds/mysql&nbsp;
相关文章
|
9月前
|
数据采集 Java API
Jsoup库能处理多线程下载吗?
Jsoup库能处理多线程下载吗?
|
1月前
|
缓存 Java
线程池的核心参数
线程池七大参数解析:核心线程数决定常驻线程,最大线程数控制并发上限,存活时间管理非核心线程生命周期,工作队列缓存待处理任务,线程工厂定制线程属性,拒绝策略应对任务过载,提升系统稳定性与资源利用率。
206 1
|
2月前
|
负载均衡 算法 安全
基于Reactor模式的高性能网络库之线程池组件设计篇
EventLoopThreadPool 是 Reactor 模式中实现“一个主线程 + 多个工作线程”的关键组件,用于高效管理多个 EventLoop 并在多核 CPU 上分担高并发 I/O 压力。通过封装 Thread 类和 EventLoopThread,实现线程创建、管理和事件循环的调度,形成线程池结构。每个 EventLoopThread 管理一个子线程与对应的 EventLoop(subloop),主线程(base loop)通过负载均衡算法将任务派发至各 subloop,从而提升系统性能与并发处理能力。
135 3
|
Java 存储
线程池的核心参数有哪些?
线程池七大核心参数:核心/最大线程数、线程保持时间及单位、阻塞队列、线程工厂与拒绝策略。
498 79
|
4月前
|
Linux 程序员 API
CentOS如何使用Pthread线程库
这就是在CentOS下使用Pthread线程库的全过程。可见,即使是复杂的并发编程,只要掌握了基本的知识与工具,就能够游刃有余。让我们积极拥抱并发编程的魅力,编写出高效且健壮的代码吧!
96 11
|
6月前
|
SQL 缓存 Java
框架源码私享笔记(02)Mybatis核心框架原理 | 一条SQL透析核心组件功能特性
本文详细解构了MyBatis的工作机制,包括解析配置、创建连接、执行SQL、结果封装和关闭连接等步骤。文章还介绍了MyBatis的五大核心功能特性:支持动态SQL、缓存机制(一级和二级缓存)、插件扩展、延迟加载和SQL注解,帮助读者深入了解其高效灵活的设计理念。
|
6月前
|
Java
线程池的核心参数有哪些 ?
corePoolSize 核心线程数量 maximumPoolSize 最大线程数量 keepAliveTime 线程保持时间,N个时间单位 unit 时间单位(比如秒,分) workQueue 阻塞队列 threadFactory 线程工厂 handler 线程池拒绝策略
|
9月前
|
SQL 存储 关系型数据库
SQL自学笔记(3):SQL里的DCL,DQL都代表什么?
本文介绍了SQL的基础语言类型(DDL、DML、DCL、DQL),并详细说明了如何创建用户和表格,最后推荐了几款适合初学者的免费SQL实践平台。
590 3
SQL自学笔记(3):SQL里的DCL,DQL都代表什么?
|
9月前
|
SQL 存储 关系型数据库
MySQL进阶突击系列(01)一条简单SQL搞懂MySQL架构原理 | 含实用命令参数集
本文从MySQL的架构原理出发,详细介绍其SQL查询的全过程,涵盖客户端发起SQL查询、服务端SQL接口、解析器、优化器、存储引擎及日志数据等内容。同时提供了MySQL常用的管理命令参数集,帮助读者深入了解MySQL的技术细节和优化方法。
|
9月前
|
SQL 数据挖掘 数据库
SQL自学笔记(2):如何用SQL做简单的检索
本文深入介绍了SQL的基本语法,包括数据查询、过滤、排序、分组及表连接等操作,并通过实际案例展示了SQL在用户研究中的应用,如用户行为分析、用户细分、用户留存分析及满意度调查数据分析。
151 0
SQL自学笔记(2):如何用SQL做简单的检索