深入解读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的操作，都能做到原子化：

  • 元数据修改，binlog以及innodb的操作都放在一个事务中
  • 增加了一个内部隐藏的系统表mysql.innodb_ddl_log，ddl操作被记录到这个表中，注意对该表的操作产生的redo会fsync到磁盘上，而不会考虑innodb_flush_log_at_trx_commit的配置。当崩溃重启时，会根据事务是否提交来决定通过这张表的记录去回滚或者执行ddl操作
  • 增加了一个post-ddl的阶段，这也是ddl的最后一个阶段，会去：1. 真正的物理删除或重命名文件; 2. 删除innodb_ddl_log中的记录项; 3.对于一些ddl操作还会去更新其动态元数据信息(存储在mysql.innodb_dynamic_metadata，例如corrupt flag, auto_inc值等)
  • 一个正常运行的ddl结束后，其ddl log也应该被清理，如果这中间崩溃了，重启时会去尝试重放：1.如果已经走到最后一个ddl阶段的（commit之后)，就replay ddl log，把ddl完成掉；2. 如果处于某个中间态，则回滚ddl
    由于引入了atomic ddl， 有些ddl操作的行为也发生了变化:
  • DROP TABLE: 在之前的版本中，一个drop table语句中如果要删多个表，比如t1,t2, t2不存在时，t1会被删除。但在8.0中，t1和t2都不会被删除，而是抛出错误。因此要注意5.7->8.0的复制问题 (DROP VIEW， CREATE USER也有类似的问题)
  • DROP DATABASE: 修改元数据和ddl_log先提交事务，而真正的物理删除数据文件放在最后，因此如果在删除文件时崩溃，重启时会根据ddl_log继续执行drop database
    测试:
    MySQL很贴心的加了一个选项innodb_print_ddl_logs，打开后我们可以从错误日志看到对应的ddl log，下面我们通过这个来看下一些典型ddl的过程

root@(none) 11:12:19>SET GLOBAL innodb_print_ddl_logs = 1;
Query OK, 0 rows affected (0.00 sec)

root@(none) 11:12:22>SET GLOBAL log_error_verbosity = 3;
Query OK, 0 rows affected (0.00 sec)
CREATE DATABASE
mysql> CREATE DATABASE test;
Query OK, 1 row affected (0.02 sec)
创建数据库语句没有写log_ddl，可能觉得这不是高频操作，如果创建database的过程中失败了，重启后可能需要手动删除目录。

CREATE TABLE
mysql> USE test;
Database changed
mysql> CREATE TABLE t1 (a INT PRIMARY KEY, b INT);
Query OK, 0 rows affected (0.06 sec)

[InnoDB] DDL log insert : [DDL record: DELETE SPACE, id=428, thread_id=7, space_id=76, old_file_path=./test/t1.ibd]
[InnoDB] DDL log delete : by id 428
[InnoDB] DDL log insert : [DDL record: REMOVE CACHE, id=429, thread_id=7, table_id=1102, new_file_path=test/t1]
[InnoDB] DDL log delete : by id 429
[InnoDB] DDL log insert : [DDL record: FREE, id=430, thread_id=7, space_id=76, index_id=190, page_no=4]
[InnoDB] DDL log delete : by id 430
[InnoDB] DDL log post ddl : begin for thread id : 7
InnoDB] DDL log post ddl : end for thread id : 7
从日志来看有三类操作，实际上描述了如果操作失败需要进行的三项逆向操作：删除数据文件，释放内存中的数据词典信息，删除索引btree。在创建表之前，这些数据被写入到ddl_log中，在创建完表并commit后，再从ddl log中删除这些记录。
另外上述日志中还有DDL log delete日志，其实在每次写入ddl log时是单独事务提交的，但在提交之后，会使用当前事务执行一条delete操作，直到操作结束了才会提交。

加列(instant)
mysql> ALTER TABLE t1 ADD COLUMN c INT;
Query OK, 0 rows affected (0.08 sec)
Records: 0 Duplicates: 0 Warnings: 0

[InnoDB] DDL log post ddl : begin for thread id : 7
[InnoDB] DDL log post ddl : end for thread id : 7
注意这里执行的是Instant ddl, 这是8.0.13新支持的特性，加列操作可以只修改元数据，因此从ddl log中无需记录数据

删列
mysql> ALTER TABLE t1 DROP COLUMN c;
Query OK, 0 rows affected (2.77 sec)
Records: 0 Duplicates: 0 Warnings: 0

[InnoDB] DDL log insert : [DDL record: DELETE SPACE, id=487, thread_id=7, space_id=83, old_file_path=./test/#sql-ib1108-1917598001.ibd]
[InnoDB] DDL log delete : by id 487
[InnoDB] DDL log insert : [DDL record: REMOVE CACHE, id=488, thread_id=7, table_id=1109, new_file_path=test/#sql-ib1108-1917598001]
[InnoDB] DDL log delete : by id 488
[InnoDB] DDL log insert : [DDL record: FREE, id=489, thread_id=7, space_id=83, index_id=200, page_no=4]
[InnoDB] DDL log delete : by id 489

[InnoDB] DDL log insert : [DDL record: DROP, id=490, thread_id=7, table_id=1108]
[InnoDB] DDL log insert : [DDL record: RENAME SPACE, id=491, thread_id=7, space_id=82, old_file_path=./test/#sql-ib1109-1917598002.ibd, new_file_path=./test/t1.ibd]
[InnoDB] DDL log delete : by id 491
[InnoDB] DDL log insert : [DDL record: RENAME TABLE, id=492, thread_id=7, table_id=1108, old_file_path=test/#sql-ib1109-1917598002, new_file_path=test/t1]
[InnoDB] DDL log delete : by id 492
[InnoDB] DDL log insert : [DDL record: RENAME SPACE, id=493, thread_id=7, space_id=83, old_file_path=./test/t1.ibd, new_file_path=./test/#sql-ib1108-1917598001.ibd]
[InnoDB] DDL log delete : by id 493
[InnoDB] DDL log insert : [DDL record: RENAME TABLE, id=494, thread_id=7, table_id=1109, old_file_path=test/t1, new_file_path=test/#sql-ib1108-1917598001]
[InnoDB] DDL log delete : by id 494
[InnoDB] DDL log insert : [DDL record: DROP, id=495, thread_id=7, table_id=1108]
[InnoDB] DDL log insert : [DDL record: DELETE SPACE, id=496, thread_id=7, space_id=82, old_file_path=./test/#sql-ib1109-1917598002.ibd]

[InnoDB] DDL log post ddl : begin for thread id : 7
[InnoDB] DDL log replay : [DDL record: DELETE SPACE, id=496, thread_id=7, space_id=82, old_file_path=./test/#sql-ib1109-1917598002.ibd]
[InnoDB] DDL log replay : [DDL record: DROP, id=495, thread_id=7, table_id=1108]
[InnoDB] DDL log replay : [DDL record: DROP, id=490, thread_id=7, table_id=1108]
[InnoDB] DDL log post ddl : end for thread id : 7
这是个典型的三阶段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
加索引
mysql> ALTER TABLE t1 ADD KEY(b);
Query OK, 0 rows affected (0.14 sec)
Records: 0 Duplicates: 0 Warnings: 0

[InnoDB] DDL log insert : [DDL record: FREE, id=431, thread_id=7, space_id=76, index_id=191, page_no=5]
[InnoDB] DDL log delete : by id 431

[InnoDB] DDL log post ddl : begin for thread id : 7
[InnoDB] DDL log post ddl : end for thread id : 7
创建索引采用inplace创建的方式，没有临时文件，但如果异常发生的话，依然需要在发生异常时清理临时索引, 因此增加了一条FREE log，用于异常发生时能够删除临时索引.

TRUNCATE TABLE
mysql> TRUNCATE TABLE t1;
Query OK, 0 rows affected (0.13 sec)

[InnoDB] DDL log insert : [DDL record: RENAME SPACE, id=439, thread_id=7, space_id=77, old_file_path=./test/#sql-ib1103-1917597994.ibd, new_file_path=./test/t1.ibd]
[InnoDB] DDL log delete : by id 439
[InnoDB] DDL log insert : [DDL record: DROP, id=440, thread_id=7, table_id=1103]
[InnoDB] DDL log insert : [DDL record: DELETE SPACE, id=441, thread_id=7, space_id=77, old_file_path=./test/#sql-ib1103-1917597994.ibd]
[InnoDB] DDL log insert : [DDL record: DELETE SPACE, id=442, thread_id=7, space_id=78, old_file_path=./test/t1.ibd]
[InnoDB] DDL log delete : by id 442
[InnoDB] DDL log insert : [DDL record: REMOVE CACHE, id=443, thread_id=7, table_id=1104, new_file_path=test/t1]
[InnoDB] DDL log delete : by id 443
[InnoDB] DDL log insert : [DDL record: FREE, id=444, thread_id=7, space_id=78, index_id=194, page_no=4]
[InnoDB] DDL log delete : by id 444
[InnoDB] DDL log insert : [DDL record: FREE, id=445, thread_id=7, space_id=78, index_id=195, page_no=5]
[InnoDB] DDL log delete : by id 445

[InnoDB] DDL log post ddl : begin for thread id : 7
[InnoDB] DDL log replay : [DDL record: DELETE SPACE, id=441, thread_id=7, space_id=77, old_file_path=./test/#sql-ib1103-1917597994.ibd]
[InnoDB] DDL log replay : [DDL record: DROP, id=440, thread_id=7, table_id=1103]
[InnoDB] DDL log post ddl : end for thread id : 7
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
mysql> RENAME TABLE t1 TO t2;
Query OK, 0 rows affected (0.06 sec)
DDL LOG:

[InnoDB] DDL log insert : [DDL record: RENAME SPACE, id=450, thread_id=7, space_id=78, old_file_path=./test/t2.ibd, new_file_path=./test/t1.ibd]
[InnoDB] DDL log delete : by id 450
[InnoDB] DDL log insert : [DDL record: RENAME TABLE, id=451, thread_id=7, table_id=1104, old_file_path=test/t2, new_file_path=test/t1]
[InnoDB] DDL log delete : by id 451

[InnoDB] DDL log post ddl : begin for thread id : 7
[InnoDB] DDL log post ddl : end for thread id : 7
这个就比较简单了，只需要记录rename space 和rename table的逆操作即可. post-ddl不需要做实际的操作

DROP TABLE
DROP TABLE t2
[InnoDB] DDL log insert : [DDL record: DROP, id=595, thread_id=7, table_id=1119]
[InnoDB] DDL log insert : [DDL record: DELETE SPACE, id=596, thread_id=7, space_id=93, old_file_path=./test/t2.ibd]

[InnoDB] DDL log post ddl : begin for thread id : 7
[InnoDB] DDL log replay : [DDL record: DELETE SPACE, id=596, thread_id=7, space_id=93, old_file_path=./test/t2.ibd]
[InnoDB] DDL log replay : [DDL record: DROP, id=595, thread_id=7, table_id=1119]
[InnoDB] DDL log post ddl : end for thread id : 7
先在ddl log中记录下需要删除的数据，再提交后，再最后post-ddl阶段执行真正的删除表对象和文件操作

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

隐藏的innodb_log_ddl表结构如下

def->add_field(0, "id", "id BIGINT UNSIGNED NOT NULL AUTO_INCREMENT");
def->add_field(1, "thread_id", "thread_id BIGINT UNSIGNED NOT NULL");
def->add_field(2, "type", "type INT UNSIGNED NOT NULL");
def->add_field(3, "space_id", "space_id INT UNSIGNED");
def->add_field(4, "page_no", "page_no INT UNSIGNED");
def->add_field(5, "index_id", "index_id BIGINT UNSIGNED");
def->add_field(6, "table_id", "table_id BIGINT UNSIGNED");
def->add_field(7, "old_file_path",
"old_file_path VARCHAR(512) COLLATE UTF8_BIN");
def->add_field(8, "new_file_path",
"new_file_path VARCHAR(512) COLLATE UTF8_BIN");
def->add_index(0, "index_pk", "PRIMARY KEY(id)");
def->add_index(1, "index_k_thread_id", "KEY(thread_id)");
记录类型
根据不同的操作类型，可以分为如下几类：

FREE_TREE_LOG
目的是释放索引btree，入口函数log_DDL::write_free_tree_log，在创建索引和删除表时会调用到
对于drop table中涉及的删索引操作，log ddl的插入操作放到父事务中，一起要么提交要么回滚
对于创建索引的case, log ddl就需要单独提交，父事务将记录标记删除，这样后面如果ddl回滚了，也能将残留的index删掉。

DELETE_SPACE_LOG
入口函数：Log_DDL::write_delete_space_log

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

drop table/tablespace, 写入的记录随父事务一起提交，并在post-ddl阶段replay
创建tablespace, 写入的记录单独提交，并被父事务标记删除，如果父事务回滚，就通过replay删除参与的tablespace
RENAME_SPACE_LOG
入口函数：Log_DDL::write_rename_space_log

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

DROP_LOG
入口函数： Log_DDL::write_drop_log

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

RENAME_TABLE_LOG
入口函数： Log_DDL::write_rename_table_log

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

REMOVE_CACHE_LOG
入口函数： Log_DDL::write_remove_cache_log

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

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. 官方文档
  2. wl#9536: support crash safe ddl

原文地址：https://blog.51cto.com/14031893/2357858

时间： 2024-11-09 07:56:28

深入解读MySQL8.0 新特性 ：Crash Safe DDL的相关文章

MySQL8.0新特性——支持原子DDL语句

MySQL 8.0开始支持原子数据定义语言(DDL)语句.此功能称为原子DDL.原子DDL语句将与DDL操作关联的数据字典更新,存储引擎操作和二进制日志写入组合到单个原子事务中.即使服务器在操作期间暂停,也会提交事务,并将适用的更改保留到数据字典,存储引擎和二进制日志,或者回滚事务. 通过在MySQL 8.0中引入MySQL数据字典,可以实现Atomic DDL.在早期的MySQL版本中,元数据存储在元数据文件,非事务性表和存储引擎特定的字典中,这需要中间提交.MySQL数据字典提供的集中式事务

MySQL8.0新特性【转】

Server层,选项持久化 mysql> show variables like '%max_connections%'; +------------------------+-------+ | Variable_name | Value | +------------------------+-------+ | max_connections | 512 | | mysqlx_max_connections | 100 | +------------------------+-------

MySQL8.0 新特性：Partial Update of LOB Column

摘要: MySQL8.0对json进行了比较完善的支持, 我们知道json具有比较特殊的存储格式,通常存在多个key value键值对,对于类似更新操作通常不会更新整个json列,而是某些键值. 对于某些复杂的应用,json列的数据可能会变的非常庞大,这时候一个突出的问题是:innodb并不识别json类型,对它而言这些存储统一都是LOB类型,而在之前的版本中Innodb处理LOB更新的方式是标记删除旧记录,并插入新记录,显然这会带来一些存储上的开销(尽管Purge线程会去后台清理),而写入的r

MySQL8.0新特性——不可见索引（Invisible Indexes）

MySQL8.0开始支持看不见的索引.一个看不见的索引根本不被优化器使用,但是通常是保持正常的.默认情况下索引是可见的.不可见的索引使测试在查询性能上删除索引的效果成为可能,而不需要在需要索引的情况下进行破坏性的更改. 注意: 该特性适用于除主键以外的索引(显式或隐式)默认情况下索引是可见的!. 将index设置为invisible,会导致优化器在选择执行计划时,自动忽略该索引,即便使用了FORCE INDEX 官方文档: https://dev.mysql.com/doc/refman/8.0

MySQL8.0新特性

MySQL从5.7一跃直接到8.0,这其中的缘由,咱就不关心那么多了,有兴趣的朋友自行百度,本次的版本更新,在功能上主要有以下6点: 账户与安全 优化器索引 通用表表达式 窗口函数 InnoDB 增强 JSON 增强 一.账户与安全 1.用户的创建与授权 在MySQL5.7的版本: > grant all privileges on *.* to '用户名'@'主机' identified by '密码': 在MySQL8.0需要分开执行: >create user '用户名'@'主机' id

MySQL8.0 新特性 Hash Join

概述&背景 MySQL一直被人诟病没有实现HashJoin,最新发布的8.0.18已经带上了这个功能,令人欣喜.有时候在想,MySQL为什么一直不支持HashJoin呢?我想可能是因为MySQL多用于简单的OLTP场景,并且在互联网应用居多,需求没那么紧急.另一方面可能是因为以前完全靠社区,这种演进速度毕竟有限,Oracle收购MySQL后,MySQL的发版演进速度明显加快了很多. HashJoin本身算法实现并不复杂,要说复杂,可能是优化器配套选择执行计划时,是否选择HashJoin,选择外表

MySQL 8.0新特性之原子DDL

文章来源:爱可生云数据库 简介 MySQL8.0 开始支持原? DDL(atomic DDL),数据字典的更新,存储引擎操作,写?进制日志结合成了一个事务.在没有原?DDL之前,DROP TABLE test1,test2:如遇到server crash,可能会有test1被drop了,test2没有被drop掉.下面来看下在MySQL8.0之前和MySQL8.0 数据字典的区别. 在MySQL8.0 之前,Data Dictionary除了存在与.FRM, .TRG, .OPT ?件外,还存在

Mysql 8.0 新特性测试

Mysql 8.0 新特性测试 Role MySQL8.0版本添加了role特性,role是一种逻辑概念是权限的集合,可以将一个或以上的权限赋予给role,再将role赋给user.Oracle,Postgresql和Mariadb中早已存在role这个特性. create role role_test; grant select,insert,delete,update on zhongwc.tab01 to role_test; create user 'user1'@'%' identif

Day07 jdk5.0新特性&Junit&反射

day07总结 今日内容 MyEclipse安装与使用 JUnit使用 泛型 1.5新特性 自动装箱拆箱 增强for 静态导入 可变参数方法 枚举 反射 MyEclipse安装与使用(yes) 安装MyEclipse 先安装了JDK ? MyEclipse介绍 ? MyEclipse是Eclipse的一个插件: MyEclipse是需要花钱的: MyEclipse官网不在欢迎中国人登录: ? MyEclipse使用 ? 1 创建项目 选择工作空间: 工作空间路径不能有空格和中文: 工作空间以班名