search 2013 adfgs
作者:Sky.Jian | 可以任意转载, 但转载时务必以超链接形式标明文章原始出处 和 作者信息 及 版权声明
链接:http://isky000.com/database/mysql-8-inc-persist | del.icio.us | Twitter it

自增变量一直以来都是MySQL上引以为傲的一个特性。虽然和Oracle的 Sequence相比没有后者灵活,但是使用比Sequence更为简单方便。

但是,很多时候的但是总是让人不爽,这里的这个但是也同样会给人带来不爽。当使用InnoDB存储引擎的时候,每次重启都会重新计算出当前表上自增字段实际最大值,并作为下一次分配的起点。这就代表如果大量删除过数据之后,自增值可能被重用。这在很多场景下可能导致问题,包括但不限于:主备切换、历史数据迁移等场景。

MySQL 8 将自增值记录进入了redo log,每次重启的时候,通过redo log来恢复上一次的最大值。

InnoDB使用一个引擎私有的系统表+特殊redo log的方式,在引擎内部自己解决问题。其大概思路为:

  1. 当发现索引损坏时,写入一条redo log,但不更新数据词典
  2. 引入一个innodb引擎私有的系统表,称为DD Buffer Table,每次checkpoint之前会将索引corruption bit存入其中。
  3. 在崩溃恢复时,同时从redo log和DD Buffer Table中读取索引 corruption bit, 合并结果,并标记内存中的表和索引对象。

在该worklog中解决的是corruption bit的持久化问题,但实现的框架也适用于其他目的,例如update_time, auto_inc, count(*)等,因此对代码做了通用性的抽象。

初始化Persister

目前Persister的类型仅有两种,一个用于corruption bit的持久化,一个用于自增列的持久化,对应的类为:

Persister:
    |-- CorruptedIndexPersister
    |-- AutoIncPersister

Persister对应全局对象dict_persist_t::persisters,可以通过类型persistent_type_t来找到对应的Persister,目前仅有PM_INDEX_CORRUPTED及PM_TABLE_AUTO_INC,但从注释来看,未来肯定会做更多的扩展

Persister在启动时调用函数dict_persist_init进行初始化。

新的系统表

新的系统表名为SYS_TABLE_INFO_BUFFER,对应管理类为DDTableBuffer,指针存储在dict_persist->table_buffer中。

Table id为DICT_TBL_BUFFER_ID,值为0xFFFFFFFFFF000000ULL, ROOT PAGE是ibdata的第8个page(FSP_TBL_BUFFER_TREE_ROOT_PAGE_NO)

系统表包含两个列:TABLE_ID及BLOB类型的METADATA(ref DDTableBuffer::init),METADATA列包含了所有需要持久化的元数据。

更新Metata

当发现索引损坏时,调用dict_set_corrupted标记索引损坏,并进行日志写入(Persister::write_log):

  • 写入的内容包含space id 和index id
  • 日志格式为:
| 1byte: type = MLOG_TABLE_DYNAMIC_META
| Table ID
| 1byte: SUB-TYPE: PM_INDEX_CORRUPTED
| 1byte: Num: Number of corrupted indexs
| 4bytes: space id
| 8bytes: index id

## 这个结构有点奇怪,理论上同一个表的索引应该存在于同一个space中,这里只需要记录一个space id就可以了

写完这条日志后,会进行一次log flush,将日志持久化到磁盘。由于index corruption属于低概率事件,不会引起性能问题。

然后再设置表的状态为脏 (dict_table_mark_dirty),这里为表定义了三种状态:

dict_table_t::dirty_status

METADATA_CLEAN: 在DDTableBuffer表中没有任何缓存数据
METADATA_BUFFERED: 在DDTableBuffer系统表中存在至少一行数据,未来需要回写到DD中
METADATA_DIRTY: 一些持久化元数据在内存中被修改,需要回写到DDTableBuffer中

如果当前表状态为METADATA_CLEAN,则需要将对象加到全局链表dict_persist_t::dirty_dict_tables中,这个链表用于维护状态为METADATA_DIRTY或者METADATA_BUFFERED的表对象

dirty_status在调用dict_table_mark_dirty后被设置成METADATA_DIRTY,并确保在dict_persist_t::dirty_dict_tables链表上

而对于AUTOINC列的持久化发生在插入或者更新时,注意对于临时表无需做持久化。

在插入聚集索引记录前(row_ins_clust_index_entry_low), 会先从entry中把counter拿出来,并记入日志

在更新记录时(row_upd_clust_rec),如果表上有autoinc列并且被更新成更大的值(row_upd_check_autoinc_counter),也会去尝试记录写日志。

持久化AUTOINC的日志写入函数为AutoIncLogMtr::log,当新的counter大于已经持久化的dict_table_t::autoinc_persisted时,将autoinc_persisted更新为新的counter,并将表的diry_status置为dirty(如果需要的话)

记录的日志格式为

| 1byte: type = MLOG_TABLE_DYNAMIC_META
| Table ID
| 1byte: Sub-type: PM_TABLE_AUTO_INC
| Autoinc Counter

注意这里在写入日志后,出于性能考虑并没有做flush log操作,因此如果crash了,已分配的autoinc不能保证不被重用,但从用户的角度来看(事务级别),autoinc是不会重用的。

回写DDTableBuffer

有几种情况会将内存修改回写到DDTableBuffer中:

  1. 在做checkpoint(log_checkpoint)之前,所有在dirty_dict_tables链表上的表对象,对应persist metadata都需要回写到DDTableBuffer中(dict_persist_to_dd_table_buffer)
  2. 从内存中驱逐一个表对象时(dict_table_remove_from_cache_low),如果需要的话也会去尝试回写。
  3. 在对包含自增列的表做DDL后,需要持久化counter,在如下函数中,会调用dict_table_set_and_persist_autoinc:
ha_innobase::commit_inplace_alter_table
create_table_info_t::initialize_autoinc()
row_rename_table_for_mysql;

回写的过程也比较简单(dict_table_persist_to_dd_table_buffer_low):

  1. 通过表对象初始化需要回写的Metadata数据: corrupt index及autoinc值(dict_init_dynamic_metadata)
  2. 构建记录值,插入DDTableBuffer系统表(DDTableBuffer::replace(), 如果记录存在的话,则进行悲观更新操作
  3. 表对象的diry_status修改成 METADATA_BUFFERED,表示有buffer的元数据

恢复与启动

在崩溃恢复时,当解析到日志MLOG_TABLE_DYNAMIC_META时(MetadataRecover::parseMetadataLog),会进行解析并将解析得到的数据存储到集合中(MetadataRecover::m_tables),如果存在相同table-id的项,就进行替换,确保总是最新的。

在完成recovery后,搜集到的meta信息暂时存储到srv_dict_metadata中, 随后进行apply(srv_dict_recover_on_restart), apply的过程也比较简单,载入表对象,然后对表对象进行更新(MetadataRecover::apply),例如对于autoinc列,就总是选择更大的那个值。

注:本文参考了云栖社区上关于MySQL8中对于该特性在源码级别内容介绍相关文章

看完了要说点啥么?