MySQL8.0的原子性DDL
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)
方法: 把源表数据导出并写入目标表,然后将此期间对源表的更新导入目标表 ,详细步骤:
- 导出表全量数据:node_mgr 调用 mydumper 将源表数据 dump 出来并传输数据文件到计算节点所在服务器;
- 加载表全量数据:node_mgr调用kunlun_loader工具把源表dump全量数据灌入目标表中;
- binlog catch-up:node_mgr根据dump时各个shard上binlog起始位置记录调用binlog2sync工具,binlog2sync 工具从该位置点开始dump binlog事件;
- 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服务,大家感兴趣也可以试用。