MySQL Innodb Purge简介

本文涉及的产品
RDS MySQL Serverless 基础系列,0.5-2RCU 50GB
云数据库 RDS MySQL,集群系列 2核4GB
推荐场景:
搭建个人博客
RDS MySQL Serverless 高可用系列,价值2615元额度,1个月
简介: 前言 为什么MySQL InnoDB需要Purge操作?明确这个问题的答案,首先还得从InnoDB的并发机制开始。为了更好的支持并发,InnoDB的多版本一致性读是采用了基于回滚段的的方式。另外,对于更新和删除操作,InnoDB并不是真正的删除原来的记录,而是设置记录的delete mark为1。

前言

为什么MySQL InnoDB需要Purge操作?明确这个问题的答案,首先还得从InnoDB的并发机制开始。为了更好的支持并发,InnoDB的多版本一致性读是采用了基于回滚段的的方式。另外,对于更新和删除操作,InnoDB并不是真正的删除原来的记录,而是设置记录的delete mark为1。因此为了解决数据Page和Undo Log膨胀的问题,需要引入purge机制进行回收。下面我们来描述下purge整个过程。(代码分析基于MySQL 5.7)

Purge数据产生的背景

  • Undo log和Undo history list
  • Mark deleted数据

Undo log

Undo log保存了记录修改前的镜像。在InnoDB存储引擎中,undo log分为:

  • insert undo log
  • update undo log

insert undo log是指在insert操作中产生的undo log。由于insert操作的记录,只是对本事务可见,其他事务不可见,所以undo log可以在事务提交后直接删除,而不需要purge操作。

update undo log是指在delete和update操作中产生的undo log。该undo log会被后续用于MVCC当中,因此不能提交的时候删除。提交后会放入undo log的链表,等待purge线程进行最后的删除。

下面列出了undo log类型,后续在purge工作线程的时候会针对性的讲述不同的处理方式:

  • 从表中删除一行记录
    TRX_UNDO_DEL_MARK_REC (将主键记入日志),在删除一条记录时,并不是真正的将数据从数据库中删除,只是标记为已删除。
  • 向表中插入一行记录
    TRX_UNDO_INSERT_REC (仅将主键记入日志)
    TRX_UNDO_UPD_DEL_REC (将主键记入日志) 当表中有一条被标记为删除的记录和要插入的数据主键相同时, 实际的操作是更新这个被标记为删除的记录。
  • 更新表中的一条记录
    TRX_UNDO_UPD_EXIST_REC (将主键和被更新了的字段内容记入日志)
    TRX_UNDO_DEL_MARK_REC和TRX_UNDO_INSERT_REC,当更新主键字段时,实际执行的过程是删除旧的记录然后,再插入一条新的记录。

Undo history list

事务提交后,对于有update_undo的事务,首先会调用trx_serialisation_number_get函数生成一个当前最大的事务号,并且把该事务加到全局trx_serial_list链表中。接下来会根据该事务所在的回滚段信息

last_page_no == FIL_NULL,来决定是否讲该回滚段加入到purge_sys->ib_bh全局队列当中。其次,会调用trx_undo_update_cleanup->trx_purge_add_update_undo_to_history函数,将undo log加入到history list上,同时记录这个回滚段上第一个需要purge的undo log信息,防止rseg再次被添加到purge队列中,然后唤醒purge线程。

	/* Add the log as the first in the history list */
	flst_add_first(rseg_header + TRX_RSEG_HISTORY,
		       undo_header + TRX_UNDO_HISTORY_NODE, mtr);

......

	if (rseg->last_page_no == FIL_NULL) {
		rseg->last_page_no = undo->hdr_page_no;
		rseg->last_offset = undo->hdr_offset;
		rseg->last_trx_no = trx->no;
		rseg->last_del_marks = undo->del_marks;
	}

注意insert_undo并不会放到History list上。

Mark deleted数据

Mark deleted的数据可能会是由于一次delete操作或者一次update操作,InnoDB会调用btr_rec_set_deleted_flag->rec_set_deleted_flag_old/rec_set_deleted_flag_new设置record的delete标志位。

那么可以标记为mark delete的数据都有哪些类型呢?包括主键记录、二级索引记录:

btr_cur_del_mark_set_clust_rec

btr_cur_del_mark_set_sec_rec

更新主键索引的情况

ha_innobase::update_row -> row_update_for_mysql -> row_upd_step -> row_upd -> row_upd_clust_step -> row_upd_clust_rec_by_insert -> btr_cur_del_mark_set_clust_rec -> row_ins_index_entry

更新非主键值,但是影响二级索引的情况

ha_innobase::update_row -> row_update_for_mysql -> row_upd_step -> row_upd -> row_upd_sec_step -> row_upd_sec_index_entry -> btr_cur_del_mark_set_sec_rec -> row_ins_sec_index_entry

Purge操作流程

  • 创建srv_purge_coordinator_thread协调线程和srv_worker_thread工作线程
  • 启动purge流程
    • 初始化purge
    • purge工作线程流程
    • 清理回滚段undo数据

创建srv_purge_coordinator_thread协调线程和srv_worker_thread工作线程

 
Purge线程包括协调线程和工作线程,总共数量由innodb_purge_threads设置,最大不能超过32个,线程在Innodb启动时在函数innobase_start_or_create_for_mysql中创建。
 
	/* Create the master thread which does purge and other utility
	operations */

	if (!srv_read_only_mode) {
		os_thread_create(
			srv_master_thread,
			NULL, thread_ids + (1 + SRV_MAX_N_IO_THREADS));
	}

	if (!(srv_read_only_mode)
	    && srv_force_recovery < SRV_FORCE_NO_BACKGROUND) {

		os_thread_create(
			srv_purge_coordinator_thread,
			NULL, thread_ids + 5 + SRV_MAX_N_IO_THREADS);

		ut_a(UT_ARR_SIZE(thread_ids)
		     > 5 + srv_n_purge_threads + SRV_MAX_N_IO_THREADS);

		/* We've already created the purge coordinator thread above. */
		for (i = 1; i < srv_n_purge_threads; ++i) {
			os_thread_create(
				srv_worker_thread, NULL,
				thread_ids + 5 + i + SRV_MAX_N_IO_THREADS);
		}

		srv_start_wait_for_purge_to_start();

	} else {
		purge_sys->state = PURGE_STATE_DISABLED;
	}
 
另外,启动过程还要调用trx_purge_sys_init初始化purge_sys相关的变量和创建purge view,后续会讲到purge view的作用。

启动purge流程

purge的主要任务是将数据库中已经mark del的数据删除,另外也会批量回收undo pages。数据库的数据页很多,要清除被删除的数据,不可能遍历所有的数据页。由于所有的变更都有undo log, 因此,从undo作为切入点,在清理过期的undo的同时,也将数据页中的被删除的记录一并清除。 整个purge操作的入口函数是srv_do_purge->trx_purge。

  • 初始化Purge的记录:

Purge操作会克隆最老旧的read_view:purge_sys->view->open_purge(),这个purge view包括了重要的两个信息:

m_low_limit_no:trx_sys->trx_serial_list最小的提交事务号no,不是事务id。

m_up_limit_id:当前最老read_view中,最小的活跃事务id。

然后,开始获取那些可以被purge掉的undo records(trx_purge_attach_undo_recs->trx_purge_fetch_next_rec),然后转化为purge_rec, 轮流放在purge thread的上下文purge_node_t *node->undo_recs中。

那么从什么位置开始purge还需要关心purge_sys的两个变量:

	purge_iter_t	iter;		/* Limit up to which we have read and
					parsed the UNDO log records.  Not
					necessarily purged from the indexes.
					Note that this can never be less than
					the limit below, we check for this
					invariant in trx0purge.cc */
	purge_iter_t	limit;		/* The 'purge pointer' which advances
					during a purge, and which is used in
					history list truncation */

 

下面看看如何获取更新这两个变量:

首先,先需要确定purge_sys->iter是不能大于purge_sys->limit的,原因是由于purge->limit是用来truncate对应的undo log并且更新history list,而iter用于找到对应del的data record进行purge,我们一定要保证purge del的data后才能purge对应的undo log。

		/* Track the max {trx_id, undo_no} for truncating the
		UNDO logs once we have purged the records. */

		if (purge_sys->iter.trx_no > limit->trx_no
		    || (purge_sys->iter.trx_no == limit->trx_no
			&& purge_sys->iter.undo_no >= limit->undo_no)) {

			*limit = purge_sys->iter;
		}

其次,需要根据purge_sys->next_stored判断是否当前purge系统中有保存的purge record,如果没有就要通过purge queue中保存的需要purge的回滚段rseg来进行purge record的生成,详细见函数trx_purge_choose_next_log。在函数trx_purge_get_rseg_with_min_trx_id会更新purge_sys->iter.trx_no成为purge rseg的last_trx_no,也就是指定回滚段上最早提交的事务号。

最后,通过调用trx_purge_get_next_rec找到真正需要purge的undo log,并且更新purge_sys->iter。如果该rseg指向的last_page_no的page上并没有其他可以需要purge的mark del的undo log,那会继续调用trx_purge_rseg_get_next_history_log来获取下一个history list下的undo page。

在获取undo log的过程中,还有一个重要的判断:

	if (purge_sys->iter.trx_no >= purge_sys->view->low_limit_no()) {
		return(NULL);
	}

这意味着,如果purge_sys->iter的trx_no已经大于等于最老读事务的事务提交号,就放弃该undo log的purge过程,只处理目前已经可以purge的undo log。

目前purge一次处理的undo log为默认300个,可通过参数innodb_purge_batch_size参数调整。

  • Purge工作线程流程:

Purge工作线程启动,是借助于MySQL中的查询计划图(que0que.cc)来调度的,也就是借助了MySQL Innodb的执行Process Model。简单可以通过代码中的注释理解:

举例说明

X := 1;
WHILE X < 5 LOOP
 X := X + 1;
 X := X + 1;
X := 5

将会生成下面的架构,x轴代表下一个执行关系,Y轴代表父子关系

A - W - A
    |
    |
    A - A

A = assign_node_t, W = while_node_t.

 

启动并行purge的代码流程如下:

que_run_threads->que_run_threads_low-> que_thr_step-> row_purge_step-> row_purge

每个work thread需要处理的流程如下:

row_purge->row_purge_record
                  case TRX_UNDO_DEL_MARK_REC:
                            ->row_purge_del_mark->row_purge_remove_sec_if_poss
                                                                   ->row_purge_remove_clust_if_poss
                  case TRX_UNDO_UPD_EXIST_REC:
                            ->row_purge_upd_exist_or_extern->row_purge_remove_clust_if_poss

可以看出work thread要只需要处理两种情况,一种是由于删除或者更新导致的mark delete的数据能够删除老版本,包括可能的二级索引和一级索引,另一种是处理由于更新非mark delete的数据导致的可能的二级索引老版本。

另外还需要介绍两个函数row_purge_parse_undo_rec,也就是从undo log里解析出行引用信息和其他信息,返回值为true表明需要执行purge操作。通过函数trx_undo_rec_get_pars获得undo记录的类型,主要包括以下几个类型:

#define TRX_UNDO_INSERT_REC 11 /* fresh insert into clustered index */
#define TRX_UNDO_UPD_EXIST_REC        \
  12 /* update of a non-delete-marked \
     record */
#define TRX_UNDO_UPD_DEL_REC                \
  13 /* update of a delete marked record to \
     a not delete marked record; also the   \
     fields of the record can change */
#define TRX_UNDO_DEL_MARK_REC              \
  14 /* delete marking of a record; fields \
     do not change */
#define TRX_UNDO_CMPL_INFO_MULT           \
  16 /* compilation info is multiplied by \
     this and ORed to the type above */

#define TRX_UNDO_MODIFY_BLOB              \
  64 /* If this bit is set in type_cmpl,  \
     then the undo log record has support \
     for partial update of BLOBs. Also to \
     make the undo log format extensible, \
     introducing a new flag next to the   \
     type_cmpl flag. */

#define TRX_UNDO_UPD_EXTERN                \
  128 /* This bit can be ORed to type_cmpl \
      to denote that we updated external   \
      storage fields: used by purge to     \
      free the external storage */

通过trx_undo_update_rec_get_sys_cols函数获取对应的table_id,trx_id,和roll_ptr。另外,为了防止所有对表的DROP操作,还会对dict_operation_lock加S全局锁。

  • Purge一级索引(row_purge_remove_clust_if_poss):

Purge一级索引首先会尝试乐观删除,即直接删除leaf

row_purge_remove_clust_if_poss_low(BTR_MODIFY_LEAF)->btr_cur_optimistic_delete

失败后,会不断尝试(最多100次)悲观删除,即修改tree本身

row_purge_remove_clust_if_poss_low(BTR_MODIFY_TREE)->btr_cur_pessimistic_delete

  • Purge二级索引(row_purge_remove_sec_if_poss):

二级索引purge时,同样先乐观删除(row_purge_remove_sec_if_poss_leaf),失败再进行悲观删除(row_purge_remove_sec_if_poss_tree)。不同的是,需要通过row_purge_poss_sec判断该二级索引记录是否可以被Purge,当该二级索引记录对应的聚集索引记录没有delete mark并且其trx id比当前的purge view还旧时,不可以做Purge操作。 

参考资料

 

 

 

 

相关实践学习
如何快速连接云数据库RDS MySQL
本场景介绍如何通过阿里云数据管理服务DMS快速连接云数据库RDS MySQL,然后进行数据表的CRUD操作。
全面了解阿里云能为你做什么
阿里云在全球各地部署高效节能的绿色数据中心,利用清洁计算为万物互联的新世界提供源源不断的能源动力,目前开服的区域包括中国(华北、华东、华南、香港)、新加坡、美国(美东、美西)、欧洲、中东、澳大利亚、日本。目前阿里云的产品涵盖弹性计算、数据库、存储与CDN、分析与搜索、云通信、网络、管理与监控、应用服务、互联网中间件、移动服务、视频服务等。通过本课程,来了解阿里云能够为你的业务带来哪些帮助 &nbsp; &nbsp; 相关的阿里云产品:云服务器ECS 云服务器 ECS(Elastic Compute Service)是一种弹性可伸缩的计算服务,助您降低 IT 成本,提升运维效率,使您更专注于核心业务创新。产品详情: https://www.aliyun.com/product/ecs
相关文章
|
1天前
|
SQL 关系型数据库 MySQL
MySQL底层概述—10.InnoDB锁机制
本文介绍了:锁概述、锁分类、全局锁实战、表级锁(偏读)实战、行级锁升级表级锁实战、间隙锁实战、临键锁实战、幻读演示和解决、行级锁(偏写)优化建议、乐观锁实战、行锁原理分析、死锁与解决方案
MySQL底层概述—10.InnoDB锁机制
|
4天前
|
存储 缓存 关系型数据库
MySQL底层概述—5.InnoDB参数优化
本文介绍了MySQL数据库中与内存、日志和IO线程相关的参数优化,旨在提升数据库性能。主要内容包括: 1. 内存相关参数优化:缓冲池内存大小配置、配置多个Buffer Pool实例、Chunk大小配置、InnoDB缓存性能评估、Page管理相关参数、Change Buffer相关参数优化。 2. 日志相关参数优化:日志缓冲区配置、日志文件参数优化。 3. IO线程相关参数优化: 查询缓存参数、脏页刷盘参数、LRU链表参数、脏页刷盘相关参数。
MySQL底层概述—5.InnoDB参数优化
|
4天前
|
存储 SQL 关系型数据库
MySQL底层概述—4.InnoDB数据文件
本文介绍了InnoDB表空间文件结构及其组成部分,包括表空间、段、区、页和行。表空间是最高逻辑层,包含多个段;段由若干个区组成,每个区包含64个连续的页,页用于存储多条行记录。文章还详细解析了Page结构,分为通用部分(文件头与文件尾)、数据记录部分和页目录部分。此外,文中探讨了行记录格式,包括四种行格式(Redundant、Compact、Dynamic和Compressed),重点介绍了Compact行记录格式及其溢出机制。最后,文章解释了不同行格式的特点及应用场景,帮助理解InnoDB存储引擎的工作原理。
MySQL底层概述—4.InnoDB数据文件
|
4天前
|
存储 SQL 关系型数据库
MySQL底层概述—2.InnoDB磁盘结构
InnoDB磁盘结构主要包括表空间(Tablespaces)、数据字典(Data Dictionary)、双写缓冲区(Double Write Buffer)、重做日志(redo log)和撤销日志(undo log)。其中,表空间分为系统、独立、通用、Undo及临时表空间,分别用于存储不同类型的数据。数据字典从MySQL 8.0起不再依赖.frm文件,转而使用InnoDB引擎存储,支持事务原子性DDL操作。
156 100
MySQL底层概述—2.InnoDB磁盘结构
|
4天前
|
缓存 算法 关系型数据库
MySQL底层概述—1.InnoDB内存结构
本文介绍了InnoDB引擎的关键组件和机制,包括引擎架构、Buffer Pool、Page管理机制、Change Buffer、Log Buffer及Adaptive Hash Index。
150 97
MySQL底层概述—1.InnoDB内存结构
|
4天前
|
存储 缓存 关系型数据库
MySQL底层概述—3.InnoDB线程模型
InnoDB存储引擎采用多线程模型,包含多个后台线程以处理不同任务。主要线程包括:IO Thread负责读写数据页和日志;Purge Thread回收已提交事务的undo日志;Page Cleaner Thread刷新脏页并清理redo日志;Master Thread调度其他线程,定时刷新脏页、回收undo日志、写入redo日志和合并写缓冲。各线程协同工作,确保数据一致性和高效性能。
MySQL底层概述—3.InnoDB线程模型
|
9天前
|
存储 SQL 缓存
MySQL原理简介—2.InnoDB架构原理和执行流程
本文介绍了MySQL中更新语句的执行流程及其背后的机制,主要包括: 1. **更新语句的执行流程**:从SQL解析到执行器调用InnoDB存储引擎接口。 2. **Buffer Pool缓冲池**:缓存磁盘数据,减少磁盘I/O。 3. **Undo日志**:记录更新前的数据,支持事务回滚。 4. **Redo日志**:确保事务持久性,防止宕机导致的数据丢失。 5. **Binlog日志**:记录逻辑操作,用于数据恢复和主从复制。 6. **事务提交机制**:包括redo日志和binlog日志的刷盘策略,确保数据一致性。 7. **后台IO线程**:将内存中的脏数据异步刷入磁盘。
|
2月前
|
存储 缓存 关系型数据库
【MySQL进阶篇】存储引擎(MySQL体系结构、InnoDB、MyISAM、Memory区别及特点、存储引擎的选择方案)
MySQL的存储引擎是其核心组件之一,负责数据的存储、索引和检索。不同的存储引擎具有不同的功能和特性,可以根据业务需求 选择合适的引擎。本文详细介绍了MySQL体系结构、InnoDB、MyISAM、Memory区别及特点、存储引擎的选择方案。
【MySQL进阶篇】存储引擎(MySQL体系结构、InnoDB、MyISAM、Memory区别及特点、存储引擎的选择方案)
|
2月前
|
存储 关系型数据库 MySQL
MySQL存储引擎详述:InnoDB为何胜出?
MySQL 是最流行的开源关系型数据库之一,其存储引擎设计是其高效灵活的关键。InnoDB 作为默认存储引擎,支持事务、行级锁和外键约束,适用于高并发读写和数据完整性要求高的场景;而 MyISAM 不支持事务,适合读密集且对事务要求不高的应用。根据不同需求选择合适的存储引擎至关重要,官方推荐大多数场景使用 InnoDB。
82 7
|
3月前
|
存储 Oracle 关系型数据库
【赵渝强老师】MySQL InnoDB的数据文件与重做日志文件
本文介绍了MySQL InnoDB存储引擎中的数据文件和重做日志文件。数据文件包括`.ibd`和`ibdata`文件,用于存放InnoDB数据和索引。重做日志文件(redo log)确保数据的可靠性和事务的持久性,其大小和路径可由相关参数配置。文章还提供了视频讲解和示例代码。
200 11
【赵渝强老师】MySQL InnoDB的数据文件与重做日志文件