MySQL Innodb Purge简介

本文涉及的产品
RDS MySQL Serverless 基础系列,0.5-2RCU 50GB
云数据库 RDS PostgreSQL,高可用系列 2核4GB
云数据库 RDS MySQL,高可用系列 2核4GB
简介: 前言 为什么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操作。 

参考资料

 

 

 

 

相关实践学习
每个IT人都想学的“Web应用上云经典架构”实战
本实验从Web应用上云这个最基本的、最普遍的需求出发,帮助IT从业者们通过“阿里云Web应用上云解决方案”,了解一个企业级Web应用上云的常见架构,了解如何构建一个高可用、可扩展的企业级应用架构。
MySQL数据库入门学习
本课程通过最流行的开源数据库MySQL带你了解数据库的世界。 &nbsp; 相关的阿里云产品:云数据库RDS MySQL 版 阿里云关系型数据库RDS(Relational Database Service)是一种稳定可靠、可弹性伸缩的在线数据库服务,提供容灾、备份、恢复、迁移等方面的全套解决方案,彻底解决数据库运维的烦恼。 了解产品详情:&nbsp;https://www.aliyun.com/product/rds/mysql&nbsp;
相关文章
|
18天前
|
存储 关系型数据库 MySQL
介绍MySQL的InnoDB引擎特性
总结而言 , Inno DB 引搞 是 MySQL 中 高 性 能 , 高 可靠 的 存 储选项 , 宽泛 应用于要求强 复杂交易处理场景 。
59 15
|
5月前
|
存储 网络协议 关系型数据库
MySQL8.4创建keyring给InnoDB表进行静态数据加密
MySQL8.4创建keyring给InnoDB表进行静态数据加密
149 1
|
4月前
|
存储 SQL 关系型数据库
MySQL存储引擎简介
在选择相应的存储引擎时,需要充分考虑实际业务场景、性能需求和数据一致性要求,从而为数据管理提供最佳支持。
305 17
|
5月前
|
SQL 缓存 关系型数据库
使用温InnoDB缓冲池启动MySQL测试
使用温InnoDB缓冲池启动MySQL测试
104 0
|
9月前
|
存储 缓存 关系型数据库
【MySQL进阶篇】存储引擎(MySQL体系结构、InnoDB、MyISAM、Memory区别及特点、存储引擎的选择方案)
MySQL的存储引擎是其核心组件之一,负责数据的存储、索引和检索。不同的存储引擎具有不同的功能和特性,可以根据业务需求 选择合适的引擎。本文详细介绍了MySQL体系结构、InnoDB、MyISAM、Memory区别及特点、存储引擎的选择方案。
1660 57
【MySQL进阶篇】存储引擎(MySQL体系结构、InnoDB、MyISAM、Memory区别及特点、存储引擎的选择方案)
|
10月前
|
存储 Oracle 关系型数据库
【赵渝强老师】MySQL InnoDB的数据文件与重做日志文件
本文介绍了MySQL InnoDB存储引擎中的数据文件和重做日志文件。数据文件包括`.ibd`和`ibdata`文件,用于存放InnoDB数据和索引。重做日志文件(redo log)确保数据的可靠性和事务的持久性,其大小和路径可由相关参数配置。文章还提供了视频讲解和示例代码。
339 11
【赵渝强老师】MySQL InnoDB的数据文件与重做日志文件
|
9月前
|
存储 关系型数据库 MySQL
MySQL存储引擎详述:InnoDB为何胜出?
MySQL 是最流行的开源关系型数据库之一,其存储引擎设计是其高效灵活的关键。InnoDB 作为默认存储引擎,支持事务、行级锁和外键约束,适用于高并发读写和数据完整性要求高的场景;而 MyISAM 不支持事务,适合读密集且对事务要求不高的应用。根据不同需求选择合适的存储引擎至关重要,官方推荐大多数场景使用 InnoDB。
224 7
|
9月前
|
存储 关系型数据库 MySQL
Mysql索引:深入理解InnoDb聚集索引与MyisAm非聚集索引
通过本文的介绍,希望您能深入理解InnoDB聚集索引与MyISAM非聚集索引的概念、结构和应用场景,从而在实际工作中灵活运用这些知识,优化数据库性能。
552 7
|
9月前
|
存储 关系型数据库 MySQL
MySQL引擎InnoDB和MyISAM的区别?
InnoDB是MySQL默认的事务型存储引擎,支持事务、行级锁、MVCC、在线热备份等特性,主索引为聚簇索引,适用于高并发、高可靠性的场景。MyISAM设计简单,支持压缩表、空间索引,但不支持事务和行级锁,适合读多写少、不要求事务的场景。
147 9
|
10月前
|
存储 Oracle 关系型数据库
【赵渝强老师】MySQL InnoDB的表空间
InnoDB是MySQL默认的存储引擎,主要由存储结构、内存结构和线程结构组成。其存储结构分为逻辑和物理两部分,逻辑存储结构包括表空间、段、区和页。表空间是InnoDB逻辑结构的最高层,所有数据都存放在其中。默认情况下,InnoDB有一个共享表空间ibdata1,用于存放撤销信息、系统事务信息等。启用参数`innodb_file_per_table`后,每张表的数据可以单独存放在一个表空间内,但撤销信息等仍存放在共享表空间中。
158 6

推荐镜像

更多