MySQL · 8.0.0新特性 · 持久化自增列值

本文涉及的产品
RDS MySQL Serverless 基础系列,0.5-2RCU 50GB
云数据库 RDS MySQL,集群版 2核4GB 100GB
推荐场景:
搭建个人博客
云原生数据库 PolarDB PostgreSQL 版,企业版 4核16GB
推荐场景:
HTAP混合负载
简介:

Worklog: WL#6204

这是MySQL8.0修复的上古bug之一,在2003年由Percona的CEO(当时应该还没Percona吧)提出的bug#199,光看这bug号就扑面而来一股上古时代的沧桑气息。

问题的本质在于InnoDB初始化AUTO_INCREMENT的方式,在每次重启时,总是算出表上最大的自增值作为最大值,下一次分配从该值开始。这意味着如果在btree右侧叶节点大量删除记录,重启后,自增值可能被重用。这在很多场景下可能导致问题,包括但不限于:主备切换、历史数据迁移等场景。在bug#199下面一大堆的回复里,可以看到大量的同行抱怨。

很早阿里的MySQL版本就解决了这个问题,主要思路是取btree根page的一个未用的长整数字段(page header的PAGE_MAX_TRX_ID),然后将当前表上的auto-increment的值持久化到其中 (还好目前innodb还不支持多个自增列),由于一般表的root页都是驻留在内存的,纯内存操作对性能带来的影响几乎可以忽略。

官方的修复就比较优雅了,不改变任何现有的存储,而是通过redo log来进行恢复。该补丁基于WL#7816的框架实现的,要想搞懂这个补丁,得先看看WL#7816做了哪些改动

根据Worklog的描述,当InnoDB发现某个索引损坏时,它会设置flag其标记成corruption状态, 并持久化到内部数据词典及持久化存储中。但是新的全局数据词典(data directory,简称DD)置于存储引擎上层,而从底层引擎去更新数据词典可能会导致死锁。而将corruption信息层层传递到上层,看起来也比较诡异.

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

  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()
// for example: alter table..auto_increment = ??
row_rename_table_for_mysql;
// rename from temporary table to normal table

回写的过程也比较简单(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的元数据

Recovery and Startup

在崩溃恢复时,当解析到日志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列,就总是选择更大的那个值。

最后

详细参阅代码 commit dcb8792b371601dc5fc4e9f42fb9c479532fc7c2

这个bug已经挂了相当长的时间,不排除把这个bug当作InnoDB的“特性”的同学,一定要注意到这个改动...

相关实践学习
基于CentOS快速搭建LAMP环境
本教程介绍如何搭建LAMP环境,其中LAMP分别代表Linux、Apache、MySQL和PHP。
全面了解阿里云能为你做什么
阿里云在全球各地部署高效节能的绿色数据中心,利用清洁计算为万物互联的新世界提供源源不断的能源动力,目前开服的区域包括中国(华北、华东、华南、香港)、新加坡、美国(美东、美西)、欧洲、中东、澳大利亚、日本。目前阿里云的产品涵盖弹性计算、数据库、存储与CDN、分析与搜索、云通信、网络、管理与监控、应用服务、互联网中间件、移动服务、视频服务等。通过本课程,来了解阿里云能够为你的业务带来哪些帮助     相关的阿里云产品:云服务器ECS 云服务器 ECS(Elastic Compute Service)是一种弹性可伸缩的计算服务,助您降低 IT 成本,提升运维效率,使您更专注于核心业务创新。产品详情: https://www.aliyun.com/product/ecs
相关文章
|
26天前
|
关系型数据库 MySQL 测试技术
深入探索MySQL 8:隐藏索引与降序索引的新特性
深入探索MySQL 8:隐藏索引与降序索引的新特性
|
1月前
|
关系型数据库 MySQL 数据库
MySQL 8.0 新特性之不可见主键
【6月更文挑战第9天】MySQL 8.0 引入了不可见主键特性,提供更灵活的数据库管理方式。不可见主键能减少业务逻辑干扰,提高数据安全性和隐私,同时在某些场景下更适用。示例展示了如何创建和使用不可见主键,但需要注意它可能带来的理解和调试难题。此特性增加了设计和管理数据库的选项,适用于对数据隐私有高要求的场景。随着技术发展,不断学习和探索新特性将提升数据库性能和功能。
42 9
|
1月前
|
SQL JSON 关系型数据库
MySQL 8.0新特性?
【6月更文挑战第14天】MySQL 8.0新特性?
21 1
|
1月前
|
SQL 关系型数据库 MySQL
字节面试:MySQL自增ID用完会怎样?
字节面试:MySQL自增ID用完会怎样?
33 0
字节面试:MySQL自增ID用完会怎样?
|
18天前
|
关系型数据库 MySQL 数据库
mysql,归零,无法自动排序,删除id,表单的数据没有从零开始出现怎样解决?删除数据仍然从删除的地方该怎样解决?表单的数据没有从2开始,而是从之前的删除的序号开始自增。
mysql,归零,无法自动排序,删除id,表单的数据没有从零开始出现怎样解决?删除数据仍然从删除的地方该怎样解决?表单的数据没有从2开始,而是从之前的删除的序号开始自增。
|
1月前
|
SQL 安全 关系型数据库
MySQL数据库——事务-简介、事务操作、四大特性、并发事务问题、事务隔离级别
MySQL数据库——事务-简介、事务操作、四大特性、并发事务问题、事务隔离级别
24 1
|
1月前
|
关系型数据库 MySQL 分布式数据库
数据库专家带你体验PolarDB MySQL版 Serverless的极致弹性特性
作为数据库专家,我有幸带大家深入体验阿里巴巴自主研发的下一代关系型分布式云原生数据库——PolarDB MySQL版的Serverless极致弹性特性。在这个云原生和分布式技术飞速发展的时代,Pola
|
26天前
|
SQL 关系型数据库 MySQL
|
26天前
|
存储 关系型数据库 MySQL
mysql的InnoDB引擎实现ACID特性的原理
mysql的InnoDB引擎实现ACID特性的原理
|
2月前
|
Oracle 关系型数据库 MySQL
【MySQL】事务四大特性ACID、并发事务问题、事务隔离级别
【MySQL】事务四大特性ACID、并发事务问题、事务隔离级别
50 4

相关产品

  • 云数据库 RDS MySQL 版