MySQL 8.0的Instant DDL

本期金句：

MySQL 8.0 的Instant DDL是该版本中非常重要的特性之一，它通过只更新的数据字典，实现了部分DDL的即时完成，大幅度提升了DDL的执行性能。

MySQL 8.0的instant DDL特性是该版本的一个非常有特色的的功能，它通过只修改数据字典，大幅度优化了部分DDL的执行效率问题，实现了增减列等DDL的即时完成。本次分享将主要介绍instant DDL的原理及实现方法，以及Klustron后续在此基础上研发的新特性，期望能让大家在对于这一关键特性有认识的同时，也对Klustron有一个更为深入了解。

01 MySQL DDL简介

首先，我们简单回顾一下MySQL DDL的整个发展历史。

• 在MySQL 5.5之前只支持Copy方式的DDL操作，需要拷贝数据，而且不能并发写正在变更的表；
• MySQL 5.5 开始支持Inplace方式的DDL操作，对于支持inplace的DDL操作，无需拷贝数据，直接在原有的表数据上面进行变更，但仍然不可并发写；
• MySQL 5.6 开始支持Online DDL，实现大部分DDL操作时可并发读写，极大减少了DDL操作对于系统的整体影响；
• MySQL 8.0 开始支持instant DDL，通过只修改数据字典而不修改数据的方式实现DDL操作的瞬时完成。

02 MySQL Instant DDL特性详解

Why？

为什么需要实现Instant DDL，原因主要有以下几点：

• 大表的DDL执行过程太长，尤其是复制场景；
• 执行部分DDL需要成倍的磁盘空间；
• 部分DDL执行过程会消耗大量的IO，内存和CPU资源；
• 在复制场景下，DDL在从机执行需要长时间才能与主机同步；

以下是一个Online DDL的执行过程：（Online DDL流程图：图片来自腾讯云码猿技术专栏）

通过上图我们可以看出，在MySQL8.0之前，一个DDL的执行过程需要三个阶段，而其中还涉及到创建新表，将数据导入新表，最后做新旧表切换等比较复杂的过程。这其中不仅过程复杂，而且还需要用到大量的磁盘，内存和CPU资源，导致DDL的执行效率很低，还会影响整个系统的正常运行。

所以，我们需要一种新的方法来做DDL，使得其能既快速又高效。

Instant DDL的原理：

Instant DDL的基本原理主要有以下几点：

• 只修改数据字典信息，不拷贝和修改任何历史数据；
• 通过增加和设置标识位来判断新旧格式的数据行；
• MySQL 8.0.29后通过设置数据行的版本号来判断数据行对应的结构。
• 只修改数据字典信息，不拷贝和修改任何历史数据；
• 通过增加和设置标识位来判断新旧格式的数据行；
• MySQL 8.0.29后通过设置数据行的版本号来判断数据行对应的结构。

上图是Instant 方式和copy方式的DDL的执行对比，我们可以看出，Instant方式执行加列操作只用了0.09秒，而copy方式需要29.17秒。简直是一个天上，一个地下！！！

下图是8.0.29版本后实现了基于版本号的表结构信息：

通过这张图我们可以看到，MySQL 8.0.29的表结构已经有了版本号，并能通过版本号来区分不同的表结构。

Instant DDL的执行过程：

我们通过下面两张图来对比一下Instant DDL和Online DDL的执行过程的差异（图片来自阿里数据库内核月报）：

下面这张是Online DDL的加列执行过程：

而下面这张是Instant DDL的加列过程：

通过这两张图的对比我们可以看出，相较于Online DDL，Instant DDL由于只需要修改数据字典，在DDL执行阶段不需要做任何事情就可以直接返回，大幅度减少了执行需要的过程和时间，极大提升了表结构变更的执行效率。

Instant DDL的内部实现：

我们上面说到Instant DDL只修改数据字典，不修改数据，那在DDL执行完成后，MySQL又是如何区分不同表结构下的数据呢？

实际上，Instant DDL特性还包括InnoDB存储引擎内部的相关实现，主要有以下几点：

• 通过设置info bits的位来标识是否有新的数据格式；
• 通过增加字段数量信息来保存当前数据行的字段数量信息；
• MySQL 8.0.29后通过设置数据行的版本号来判断数据行对应的结构。

下图是一条没有做过Instant DDL的表记录行的数据结构（图片来自阿里数据库内核月报）：

而在通过Instant DDL增加了一列之后，新插入的记录行结构变为下图这样：

通过对比我们可以看到，新记录在记录头信息中的info-bits位设置了INSTANT_FLAG位，来表明这是一个表结构变更后插入的新记录，然后通过红色的“字段数量”信息来获取当前记录的字段个数。

我们再来看看具体的DML操作在有Instant DDL后是如何处理的：

• 插入：按照新的格式插入
• 查找：根据标识位判断是新或旧版本数据
• 更新：更新为新格式数据
• 删除：无变化

通过以上描述，我们可以看到，Instant DDL非常巧妙的通过不同的数据行结构来区分新旧数据，从而实现一张表中不同版本数据的识别与存取。

03 Klustron的DDL

首先，简单介绍一下我们泽拓科技的分布式数据产品Klustron的核心架构：

Klustron 的分布式存算分离架构

• 计算层(Klustron-server)：多个PostgreSQL实例构成的计算节点负责接受验证应用软件端的连接请求，以及从已经建立的连接中接受SQL查询请求，执行请求，然后返回查询结果；
• 存储层(Klustron-storage): 三个或者更多个MySQL8.0实例构成的存储节点组成一个存储集群(storage shard，简称shard)，每个shard 存储着一部分用户表或者表分区；
• 元数据集群存储着Klustron 集群的元数据包括拓扑结构、节点连接信息、DDL日志，commit log，和其他集群管理日志等；
• cluster_mgr 集群负责维护正确的集群和节点状态，实现集群管理、集群逻辑备份和恢复, 集群物理备份和恢复、水平弹性伸缩等功能。

接下来介绍一下Klustron的Online DDL特性。

Klustron 的Online DDL（Repartition）

方法: 把源表数据导出并写入目标表，然后将此期间对源表的更新导入目标表 ，详细步骤：

1. 导出表全量数据：node_mgr 调用 mydumper 将源表数据 dump 出来并传输数据文件到计算节点所在服务器；
2. 加载表全量数据：node_mgr调用kunlun_loader工具把源表dump全量数据灌入目标表中；
3. binlog catch-up：node_mgr根据dump时各个shard上binlog起始位置记录调用binlog2sync工具，binlog2sync 工具从该位置点开始dump binlog事件；
4. rename 源表和目标表：binlog2sync工具快速将剩余的binlog同步完，然后再将目标表rename成源表名，业务恢复正常使用。

Klustron DDL 的未来：

Klustron不仅实现了Online DDL这一重要的DDL特性，也正在完成并规划其他DDL相关的特性，比如：

• Online DDL的增强和优化（并行化实现性能优化等）
• Transactional DDL（实现DDL的事务性，而不仅仅是原子性）
• Instant DDL的增强与优化（实现更多DDL的Instant方式执行）
• DDL的并行化改造

等等

04 ：Q&A

Q1 ：Instant DDL的执行过程需要上锁吗？

A1： Instant DDL在最后commit阶段，也就是新旧表结构切换的阶段需要极为短暂的上MDL锁，以保证在这个阶段用户读取到错误的表结构。这个上锁极为短暂，内部也没有任何复杂操作，可以说是瞬间完成，对系统运行不会有任何影响。

Q2 ： 什么地方可以试用Klustron？

A2： 对Klustron感兴趣的小伙伴可以从我们的官网下载试用，根据安装文档部署即可。另外，我们在亚马逊的marketplace和阿里云也提供了Klustron的severless服务，大家感兴趣也可以试用。

END