写点什么

MySQL 8.0.29 instant DDL 数据腐化问题分析

作者:GreatSQL
  • 2023-06-12
    福建
  • 本文字数:4474 字

    阅读完需:约 15 分钟

  • 前言

  • Instant add or drop column 的主线逻辑

  • 表定义的列顺序与 row 存储列顺序阐述

  • 引入 row 版本的必要性

  • 数据腐化问题

  • 原因分析

  • Bug 重现与解析

  • MySQL8.0.30 修复方案



前言

DDL 相对于数据库的 DML 之类的其他操作,相对来说是比较耗时、相对重型的操作; 因此对业务的影比较严重。MySQL 从 5.6 版本开始一直在持续改进其 DDL 性能:引入了 online DDL,inplace DDL,instant DDL 等实用性极强的功能, DDL 目前对业务的影响持续降低。


MySQL 8.0.29 引入了 instant add/drop column 功能,支持在任意位置添加 column, drop column 也不需要表数据的任何形式的移动, 只需要修改表的元数据就可以完成 add/drop column,所以 instant add/drop column 的操作是轻型操作,速度快,资源需求量少。


ALTER table drop column a, ALGORITHM=INSTANT;


8.0.29 引入了新的 alter 算法 INSTANT。


但是这个新功能目前很不稳定,导致的问题比较多; 而且通常都比较严重: 数据损坏,或者数据库无法启动等。


本文是分析其中的一个问题: 对表进行 instant drop 后,进行 update ,之后数据库停机,而后数据库无法启动。


为分析这个问题, 我们会从 instant add/drop column 在 Innodb 的实现原理与细节方面来阐述这个数据腐化 bug 的具体原因。

Instant add or drop column 的主线逻辑

因为这个功能的 WorkLog 无法从官方获取,所以无法得到准确的设计出发点,通过阅读相关代码,得出要实现这个功能,必须要处理以下关键点:


  • 因为要支持在任意位置添加/删除列,同时不会更改表数据文件,所以表的逻辑定义与 row 的实际存储形式需要映射关系,不再是所见即所得的一一对应的关系。即为了实现这样功能:

  • 表中列的定义顺序与表中行数据(row)的存储顺序是不同的。

  • 同时对同一个 table 可以做多次 instant DDL, 所以需要引入版本机制,在表的数据文件中,不同 row 对应的表定义可能是不同的,需要在 row 中记住表定义的 version。


以上可以认为是该功能的设计原则与实现的主线逻辑。

表定义的列顺序与 row 存储列顺序阐述

在引入这个功能之前, create table 时列定义的顺序与列在 InnoDB 中存储的顺序是一致的。(这里我们不用考虑 InnoDB 添加系统隐藏列)


Instant add/drop column 要实现的亮点功能是在表定义的任意位置添加或者减少 column,同时做这样的操作的时候,能够做到不需要重构表数据。


我们称 column 在表定义中出现的顺序为逻辑顺序;


而 column 在行数据的存储顺序为物理顺序


要做到修改表定义,而不重构表数据,就必须将逻辑顺序与物理顺序解耦: 不能再像 MySQL 8.0.29 之前的版本那样,逻辑顺序与物理顺序是完全一致的;而从 8.0.29 开始通过表的元数据保存了逻辑顺序与物理顺序的映射关系。这种映射关系的构建与维护构成了 instant add/drop column 的基础.


如下图简单阐述了逻辑/物理顺序的关系。


引入 row 版本的必要性

对于同一张表,Instant add/drop DDL 可以执行多次;每一次执行后,逻辑/物理顺序的映射关系就发生变化;同时 instant add/drop DDL 并不需要做表数据的重构操作;因此可以得出经过多次 instant add/drop DDL,InnoDB 存储的行数据与表定义存在多种逻辑/物理顺序映射关系:比如说,在 ibd 文件中,前十行数据对应原始的表定义,接下来的十行可能对应着 instant add column 后的数据,再接下来的十行,可能对应着 instant drop column 后的数据。


为了管理这种形式的逻辑/物理,在 InnoDB 中,为每一行实际存储的数据引入了版本号的概念:每个版本号对应着一个逻辑/物理映射关系。


为存储这个版本信息,InnoDB 中,row 的信息头记录的格式有稍微的变化:



如上图所示,在 row 的 extra 中存储了其对应的版本号, 同时在 row header 中有标志位指示出了是否存在版本号信息。


根据版本号获取相应的映射关系,就可以正确的解析行数据。


目前版本号最大支持到 64, instant add/drop column 到达这个限制后报错;其后如果还需要 instant add/drop column DDL 操作,可能需要做一次能够触发 table rebuild 操作才可以。

数据腐化问题

由 instant add/drop column 引入了多个数据腐化问题,其中一个问题可以从:


[PS-8292] MySQL 8.0.29 fails to perform crash recovery - Percona JIRA(https://jira.percona.com/browse/PS-8292) 查看。


这个问题简单来说:在对表进行 instant drop 后,进行 update 操作,之后 MySQL server 重启,在启动阶段恢复之前的 update 操作会引发 assert 崩溃(debug 版本的情况下)。


从代码上看,这个 bug 可能会造成数据的静默错误(数据完全错乱而且不报任何错误),而不仅仅是崩溃这一种现象。


通过对 core 文件的简单分析,造成该问题的大概原因如下:


在通过 redo 做恢复的时候,字段的逻辑顺序与物理存储顺序之间的映射关系不对(错位)导致的。在恢复期间可能会找不到对应的字段,或者更新了错误的字段

原因分析

从原始的问题看,这个是发生在 InnoDB 启动恢复阶段。这一阶段离不开 redo log 的参与。前面介绍 instant add/drop 设计要点的时候,那些列出的要点,可以认为是在在 DDL 期间的工作以及编码的基本逻辑;那么在完成 instant DDL 时候, 在 DML 的时候也需要将必要的信息写入 redo log 才能做到 recovery。


  • 为支持 instant add/drop column,redo log 记录的格式发生了变化,因为代码 bug,导致在解析 redo log 做恢复的时候,得到的字段信息错误,导致数据腐化。

  • 问题表现出来可能是: 恢复始终无法执行,数据库无法启动;还可能是恢复到错误的数据,数据库能够启动。


因为 redo log 的种类较多,信息也比较繁杂,这里我们只关注问题本身中出现的 update 相关的 redo log ,进而较多的关注 update redo log 与该问题相关的字段信息。


下图简要的阐述了 update redo log 相关内容:



到这里,可以看到 在 MySQL 8.0.29 中,update redo log 引入了 instant column 的物理逻辑顺序。


下面从 InnoDB 的恢复流程跟踪问题发生的原因,其中主要需要关注的是恢复过程中的表(索引)定义。


  • 应用 redo log 是在数据库启动阶段最开始就执行,此时数据字典无法打开,获取不到待恢复表的定义信息

  • 但是此时需要表的定义信息去解析 redo log 中的相关数据

  • 此时就会根据 redo log 中记录的长度信息,以及记录长度的顺序构建临时的表定义,此时仅仅是为了恢复,并不需要精确的表定义,此时只需要知道 field 的长度和位置即可。

  • 同时如果 redo log 中如果有 instant DDL 的信息,那么也会用这些信息去修改临时构建的表定义:这是问题发生的初始错误的地方。

  • 恢复过程中,构建出的临时表实际上表中列的逻辑顺序,这是符合正常运行的需求的。

  • 但是实际上 8.0.29 中字段长度的记录顺序是按字段(列)的物理存储顺序写入的。

  • 如果带有 instant DDL 的信息,那么修改表定义时就会按物理顺序去修改逻辑顺序的表定义,这样会修改到非预期的字段,导致错误发生!

Bug 重现与解析

CREATE TABLE `tb1` (  `col1` VARCHAR(10) NOT NULL,  `col2` char(13),  `col3` varchar(11),  PRIMARY KEY (`col1`)) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_0900_ai_ci;INSERT INTO tb1  VALUES ('4000','50','100');--echo # the FIRST INSTANT ALTERALTER TABLE tb1 DROP COLUMN col2, LOCK=DEFAULT;INSERT INTO tb1  VALUES( '4545', '52' );UPDATE tb1 SET col3 = '46' WHERE col1 = '4545';--echo # crash and restart 1--source include/kill_and_restart_mysqld.incCHECK TABLE tb1;DROP TABLE tb1;
复制代码


以上 MySQL MTR 测例可以重现 InnoDB 启动恢复期间始终 core 的问题。我们从这个例子出发,结合上面解释的 instant drop DDL 代码行为看看问题是如何一步步发生的。


  1. 首先说明一下,在测例运行期间逻辑顺序与物理顺序的变化。 如下图所示稍微展示了 table 的逻辑定于与 InnoDB row 存储的以下细节。这里注意的是 被 dropped column 仍然会以隐藏列的形式存在于表定于中:因为 drop 之前存在的 row 还是需要这样信息解析字段。



  1. 结合 redo log 的恢复过程看看问题发生的第一现场。这里针对这个测例摘取相关 redo log 的部分信息:


  2. 2.1 按照字段长度列表(8.0.29 中是物理顺序写入的列表)创建的专门用于恢复的表,类似于: create table dummy_table (d1:10, d2:13, d3:11)

  3. 2.2 按照 instant 字段信息修改 dummy 表:按照 physical pos=1 去修改后,结果类似于:create table dummy_table (d1:10, d2:13[dropped], d3:11)

  4. 2.3 期望的正确的表应该类似于:create table dummy_table(d1:10, d3:11, d2:13[dropped]);

  5. 2.4 Redo log 中的 Field_no=1, 去恢复时期望用到的是 #2.3 的表,但是过程中创建的是 #2.2 中错误的表,这样当 Field_no=1 去恢复数据时,会错误的发现对应的 field(column)已经 dropped, 导致 core!

MySQL8.0.30 修复方案

知道了问题发生的原因,修复起来就比较简单了:


  • MySQL 8.0.30 的代码修复方案

  • Redo log 中字段的长度列表,按照字段的逻辑顺序写入,不再按存储顺序写入。

  • 在 redo log 的 instant column 信息中也包含了字段的逻辑位置。

  • Redo log 的记录本身的版本设置为 1 ,与 8.0.29 的版本为 0 ,做出差别。

  • 8.0.30 的修复代码本身也是不能正确解析 8.0.29 产生的 redo log ,只是根据版本号检测出 8.0.29 redo log,进而报错防止数据进一步恶化。实际上 8.0.29 的 redo log ,在 instant DDL 后,是不可能正确解析的,因为没有逻辑/物理的映射关系。

  • 修复的逻辑比较简单:

  • Redo log 中字段的长度列表,按照字段的逻辑顺序写入:

  • 保证在恢复阶段构建的临时表是按正确的逻辑定义顺序构建的。

  • 在 redo log 的 instant column 信息中也包含字段的逻辑位置:

  • 保证在更新临时表的字段时,按照逻辑顺序,不会出现错误更新的情况。


下面是 MySQL 8.0.30 update redo log 相关字段信息:



从上图可以看出,MySQL 8.0.30 redo log 中已经不存储物理位置相关的信息了,全部是逻辑位置相关的信息;这样就和 MySQL 8.0.29 redo log 这种有问题的记录方式是昙花一现了。


附带的这个测例可以重现数据的静默错误(恢复过程没问题, 但是数据实际上错了)


CREATE TABLE `tb2` ( `c1` char(4) NOT NULL, `c2` char(4), `c3` char(4), PRIMARY KEY (`c1`)) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_0900_ai_ci;begin;INSERT INTO tb2  VALUES ('1000','2000','3000');commit;--echo # the FIRST INSTANT ALTERALTER TABLE tb2 add COLUMN c4 char(4) after c1, LOCK=DEFAULT;INSERT INTO tb2 VALUES ('1001','4001', '2001', '3001');SELECT * FROM tb2;UPDATE tb2 set c4='4002' WHERE c1='1001';--echo # crash and restart 1--source include/kill_and_restart_mysqld.incselect * from tb2;CHECK TABLE tb2;
复制代码


需要把这个测例放到 innodb test case suite 中。




Enjoy GreatSQL :)

关于 GreatSQL

GreatSQL 是由万里数据库维护的 MySQL 分支,专注于提升 MGR 可靠性及性能,支持 InnoDB 并行查询特性,是适用于金融级应用的 MySQL 分支版本。


相关链接: GreatSQL社区 Gitee GitHub Bilibili

GreatSQL 社区:

社区博客有奖征稿详情:https://greatsql.cn/thread-100-1-1.html


技术交流群:

微信:扫码添加GreatSQL社区助手微信好友,发送验证信息加群



发布于: 刚刚阅读数: 4
用户头像

GreatSQL

关注

GreatSQL社区 2023-01-31 加入

GreatSQL是由万里数据库维护的MySQL分支,专注于提升MGR可靠性及性能,支持InnoDB并行查询特性,是适用于金融级应用的MySQL分支版本。 社区:https://greatsql.cn/ Gitee: https://gitee.com/GreatSQL/GreatSQL

评论

发布
暂无评论
MySQL 8.0.29 instant DDL 数据腐化问题分析_greatsql_GreatSQL_InfoQ写作社区