悲剧啊！Mysql的上古BUG！！！

共计 2263 个字符，预计需要花费 6 分钟才能阅读完成。

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

官方的修复就比较优雅了，不改变任何现有的存储，而是通过 redo log 来进行恢复。该补丁基于 WL#7816 的框架实现的，要想搞懂这个补丁，得先看看 WL#7816 做了哪些改动，为了解决这个问题，InnoDB 使用一个引擎私有的系统表 + 特殊 redo log 的方式，在引擎内部自己解决 corruption 标记持久化的问题。其大概思路为：

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

目前 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 及 BLOB 类型的 METADATA（ref DDTableBuffer::init），METADATA 列包含了所有需要持久化的元数据。

有几种情况会将内存修改回写到 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 的元数据

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

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

阿里云 2 核 2G 服务器 3M 带宽 61 元 1 年，有高配

腾讯云新客低至 82 元 / 年，老客户 99 元 / 年

代金券：在阿里云专用满减优惠券