深入解读MySQL8.0 新特性 ：Crash Safe DDL

前言

在MySQL8.0之前的版本中，由于架构的原因，mysql在server层使用统一的frm文件来存储表元数据信息，这个信息能够被不同的存储引擎识别。而实际上innodb本身也存储有元数据信息。这给ddl带来了一定的挑战，因为这种架构无法做到ddl的原子化，我们在线上经常能够看到数据目录下遗留的临时文件，或者类似server层和innodb层列个数不一致之类的错误。甚至某些ddl可能还遗留元数据在innodb内，而丢失了frm，导致无法重建表…..（我们为了解决这个问题，实现了一个叫drop table force的功能，去强制做清理….）

(以下所有的讨论都假定使用InnoDB存储引擎)

到了8.0版本，我们知道所有的元数据已经统一用InnoDB来进行管理，这就给实现原子ddl带来了可能，几乎所有的对innodb表，存储过程，触发器，视图或者UDF的操作，都能做到原子化：

由于引入了atomic ddl， 有些ddl操作的行为也发生了变化:

测试:

MySQL很贴心的加了一个选项innodb_print_ddl_logs，打开后我们可以从错误日志看到对应的ddl log，下面我们通过这个来看下一些典型ddl的过程

CREATE DATABASE

创建数据库语句没有写log_ddl，可能觉得这不是高频操作，如果创建database的过程中失败了，重启后可能需要手动删除目录。

CREATE TABLE

从日志来看有三类操作，实际上描述了如果操作失败需要进行的三项逆向操作：删除数据文件，释放内存中的数据词典信息，删除索引btree。在创建表之前，这些数据被写入到ddl_log中，在创建完表并commit后，再从ddl log中删除这些记录。

另外上述日志中还有DDL log delete日志，其实在每次写入ddl log时是单独事务提交的，但在提交之后，会使用当前事务执行一条delete操作，直到操作结束了才会提交。

加列(instant)

注意这里执行的是Instant ddl, 这是8.0.13新支持的特性，加列操作可以只修改元数据，因此从ddl log中无需记录数据

删列

这是个典型的三阶段ddl的过程：分为prepare, perform 以及commit三个阶段:

• Prepare: 这个阶段会修改元数据，创建临时ibd文件#sql-ib1108-1917598001.ibd, 如果发生异常崩溃，我们需要能把这个临时文件删除掉， 因此和create table类似，也为这个idb写了三条日志：delete space, remove cache,以及free btree

• Perform: 执行操作，将数据拷贝到上述ibd文件中，（同时处理online dmllog）, 这部分不涉及log ddl操作

• Commit: 更新数据词典信息并提交事务, 这里会写几条日志：

DROP : table_id=1108

RENAME SPACE: #sql-ib1109-1917598002.ibd文件被rename成t1.ibd

RENAME TABLE: #sql-ib1109-1917598002被rename成t1

RENAME SPACE: t1.ibd 被rename成#sql-ib1108-1917598001.ibd

RENAME TABLE: t1表被rename成#sql-ib1108-1917598001

DROP TABLE: table_id=1108

DELETE SPACE: 删除#sql-ib1109-1917598002.ibd

实际上这一步写的ddl log描述了commit阶段操作的逆向过程：将t1.ibd rename成#sql-ib1109-1917598002, 并将sql-ib1108-1917598001 rename成t1表，最后删除旧表。其中删除旧表的操作这里不执行，而是到post-ddl阶段执行

• Post-ddl: 在事务提交后，执行最后的操作：replay ddl log, 删除旧文件，清理mysql.innodb_dynamic_metadata中相关信息

DELETE SPACE: #sql-ib1109-1917598002.ibd

DROP: table_id=1108

DROP: table_id=1108

加索引

创建索引采用inplace创建的方式，没有临时文件，但如果异常发生的话，依然需要在发生异常时清理临时索引, 因此增加了一条FREE log，用于异常发生时能够删除临时索引.

TRUNCATE TABLE

Truncate table是个比较有意思的话题，在早期5.6及之前的版本中, 是通过删除旧表创建新表的方式来进行的，5.7之后为了保证原子性，改成了原地truncate文件，同时增加了一个truncate log文件，如果在truncate过程中崩溃，可以通过这个文件在崩溃恢复时重新truncate。到了8.0版本，又恢复成了删除旧表，创建新表的方式，与之前不同的是，8.0版本在崩溃时可以回滚到旧数据，而不是再次执行。以上述为例，主要包括几个步骤：

• 将表t1.ibd rename成#sql-ib1103-1917597994.ibd

• 创建新文件t1.ibd

• post-ddl: 将老文件#sql-ib1103-1917597994.ibd删除

RENAME TABLE

DDL LOG:

这个就比较简单了，只需要记录rename space 和rename table的逆操作即可. post-ddl不需要做实际的操作

DROP TABLE

先在ddl log中记录下需要删除的数据，再提交后，再最后post-ddl阶段执行真正的删除表对象和文件操作

代码实现:

主要实现代码集中在文件storage/innobase/log/log0ddl.cc中，包含了向log_ddl表中插入记录以及replay的逻辑。

隐藏的innodb_log_ddl表结构如下

记录类型

根据不同的操作类型，可以分为如下几类：

1.FREE_TREE_LOG

目的是释放索引btree，入口函数log_DDL::write_free_tree_log，在创建索引和删除表时会调用到

对于drop table中涉及的删索引操作，log ddl的插入操作放到父事务中，一起要么提交要么回滚
对于创建索引的case, log ddl就需要单独提交，父事务将记录标记删除，这样后面如果ddl回滚了，也能将残留的index删掉。

2.DELETE_SPACE_LOG

入口函数：

Log_DDL::write_delete_space_log

用于记录删除tablespace操作，同样分为两种情况：

1）drop table/tablespace, 写入的记录随父事务一起提交，并在post-ddl阶段replay

2）创建tablespace, 写入的记录单独提交，并被父事务标记删除，如果父事务回滚，就通过replay删除参与的tablespace

3.RENAME_SPACE_LOG

入口函数：

Log_DDL::write_rename_space_log

用于记录rename操作，例如如果我们把表t1 rename成t2,在其中就记录了逆向操作t2 rename to t1.
在函数Fil_shard::space_rename()中，总是先写ddl log, 再做真正的rename操作. 写日志的过程同样是独立事务提交，父事务做未提交的删除操作

4.DROP_LOG

入口函数： 

Log_DDL::write_drop_log

用于记录删除表对象操作，这里不涉及文件层操作，写ddl log在父事务中执行

5.RENAME_TABLE_LOG

入口函数： 

Log_DDL::write_rename_table_log

用于记录rename table对象的逆操作，和rename space类似，也是独立事务提交ddl log, 父事务标记删除

6.REMOVE_CACHE_LOG

入口函数： 

Log_DDL::write_remove_cache_log

用于处理内存表对象的清理，独立事务提交，父事务标记删除

7.ALTER_ENCRYPT_TABLESPACE_LOG

入口函数： 

Log_DDL::write_alter_encrypt_space_log

用于记录对tablespace加密属性的修改，独立事务提交. 在写完ddl log后修改tablespace page0 中的加密标记

综上，在ddl的过程中可能会提交多次事务，大概分为三类：

• 独立事务写ddl log并提交，父事务标记删除, 如果父事务提交了，ddl log也被顺便删除了，如果父事务回滚了，那就要根据ddl log做逆操作来回滚ddl

• 独立事务写ddl log 并提交, (目前只有ALTER_ENCRYPT_TABLESPACE_LOG)

• 使用父事务写ddl log，在ddl结束时提交。需要在post-ddl阶段处理

post_ddl

如上所述，有些ddl log是随着父事务一起提交的，有些则在post-ddl阶段再执行, post_ddl发生在父事提交或回滚之后: 若事务回滚，根据ddl log做逆操作，若事务提交，在post-ddl阶段做最后真正不可逆操作（例如删除文件）

入口函数： 

Log_DDL::post_ddl -->Log_DDL::replay_by_thread_id

根据执行ddl的线程thread id通过innodb_log_ddl表上的二级索引，找到log id,再到聚集索引上找到其对应的记录项，然后再replay这些操作，完成ddl后，清理对应记录

崩溃恢复

在崩溃恢复结束后，会调用ha_post_recover接口函数，进而调用innodb内的函数Log_DDL::recover(), 同样的replay其中的记录，并在结束后删除记录。但ALTER_ENCRYPT_TABLESPACE_LOG类型并不是在这一步删除，而是加入到一个数组ts_encrypt_ddl_records中,在之后调用resume_alter_encrypt_tablespace来恢复操作，

参考文档

1. 官方文档

   https://dev.mysql.com/doc/refman/8.0/en/atomic-ddl.html

2. wl#9536: support crash safe ddl

   https://dev.mysql.com/worklog/task/
   

更多精彩

如果觉得本文还不错，点击好看一下！