MySQL8.0的原子性DDL

本期金句：

MySQL8.0 的原子性DDL是该版本中最重要的特性之一，它通过把MySQL的数据字典做了关键性重构，从而解决了长期困扰MySQL用户的DDL crash-safe等相关问题。

MySQL 8.0的原子性DDL特性是该版本的一个非常重要的功能，它解决了MySQL饱受诟病的执行DDL时crash导致系统异常的问题，实现了DDL的事务原子性。本次分享将主要介绍原子性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操作的瞬时完成。

我们再看看8.0之前的数据字典结构，它主要有以下特点：

• 双层数据字典结构：server层，引擎层都有数据字典，两份数据字典需要同步

• 信息存储在多处：存储在文本文件，MyISAM和InnoDB中

  • Server层：

    • 文本文件：.FRM, .OPT文件等

    • MyISAM系统表：user，events等

  • 存储引擎层：

    • InnoDB内部系统表：sys_tables, sys_indexes

Why Atomic DDL？

为什么需要原子性DDL呢？主要有以下原因：

• 数据字典信息不同步：server层和InnoDB层数据字典不一致的问题时常出现；
• 数据字典缺乏统一管理：通过文件，MyISAM引擎等存储，没有统一API
• DDL不具备原子性，导致crash safe和复制的问题
• 缺乏扩展性，不便于升级。

02 MySQL原子性DDL特性详解

MySQL8.0 的数据字典：

设计要点主要有以下几点：

• 统一数据字典信息：去除了.FRM等文件及MyISAM系统表，统一放到InnoDB存储引擎中的一套系统表中；
• 通过统一的接口API访问和操作数据字典；
• 新的数据字典缓存；
• 实现了一套新的存储引擎API用以支持原子性DDL和crash safe；
• information schema被重新实现为数据字典表的视图。

MySQL 8.0 的数据字典API框架：

• Data Dictionary Client：为SQL clients和存储引擎层提供数据字典的统一读写访问接口；
• DD Shared Cache：共享字典对象缓存；
• Storage Adaptor：InnoDB系统表的封装接口；
• 存储层接口：Handler接口。

MySQL 8.0 的DDL原子性实现方法：

• 由多个事务完成的一个DDL操作变成一个 DDL Trx 事务去完成，保证字典表操作原子性；
• 记录DDL日志（DDL log）保证数据文件操作原子性；
• Crash recovery的时候，根据DDL事务的提交状态选择提交或回滚。

MySQL 8.0 的DDL四个阶段：

• Prepare：创建所需对象并将DDL log写入系统表mysql.innodb_ddl_log；
• Perform：执行DDL操作，例如：执行创建表的所需操作；
• Commit：更新数据字典并提交DDL Trx；
• Post-DDL：Replay并删除DDL log。

原子性DDL举例（drop table）：

Drop table T1;

• Prepare：找到字典对象T1；
• Perform：删除在数据字典表中T1的相关信息；
• Commit:：提交DDL 事务，淘汰T1字典对象缓存；
• Post-DDL：删除数据文件t1.ibd等。

下图为drop table这个DDL操作的调用过程：

下图是Drop table记录的DDL log 内容：

从以上内容我们可以看出，当DDL操作顺利执行完成commit的时候，系统会在post-ddl阶段把数据文件删除，而一旦发生回滚，则因为ddl log内容会被回滚，所以不会执行ddl log里的内容，而直接回滚系统表的所有变更即可。

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的事务性，而不仅仅是原子性）

等等

04 ：Q&A

Q1 ：事务性DDL和原子性DDL有什么区别？

A1： 原子性只是实现了DDL操作的不可分割性，即：一个DDL要么commit（执行成功），要么rollback（执行失败），而不存在中间状态。但MySQL的DDL操作依然不能和其他事务共存，也就是说DDL不能放在一个普通的用户事务中，跟随用户事务提交或回滚。事务性DDL就是支持DDL操作放在普通用户事务中，由用户决定是提交还是回滚。PostgreSQL是支持事务性DDL的。

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

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