您的位置:新葡亰496net > 网络数据库 > 新葡亰496net:0新特性之支持原子DDL语句,table导

新葡亰496net:0新特性之支持原子DDL语句,table导

发布时间:2019-07-27 06:26编辑:网络数据库浏览(128)

       MySQL 8.0上马帮助原子数据定义语言(DDL)语句。此功能称为原子DDL。原子DDL语句将与DDL操作关联的数据字典更新,存款和储蓄引擎操作和二进制日志写入组合到单个原子事务中。固然服务器在操作时期暂停,也会付出业务,并将适用的改动保留到数量字典,存款和储蓄引擎和二进制日志,只怕回滚事务。

    MySQL 8.0始发接济原子数据定义语言(DDL)语句。此意义称为原子DDL。原子DDL语句将与DDL操作关联的数据字典更新,存款和储蓄引擎操作和二进制日志写入组合到单个原子事务中。固然服务器在操作时期暂停,也会付给业务,并将适用的改动保留到多少字典,存款和储蓄引擎和二进制日志,也许回滚事务。

    在MySQL8.0事先的本子中,由于架构的原由,mysql在server层使用统一的frm文件来积攒表元数据音信,这些新闻可见被分裂的存放引擎识别。而实际innodb本人也蕴藏有元数据信息。那给ddl带来了必然的挑衅,因为这种架构不可能成功ddl的原子化,大家在线上时常能够见到数据目录下遗留的有时文件,恐怕类似server层和innodb层列个数不雷同之类的错误。乃至一些ddl大概还遗留元数据在innodb内,而错失了frm,导致无能为力重新建立表…..(大家为了化解这几个标题,实现了一个叫drop table force的功能,去强制做清理….)

    今日做多少迁移, 发掘专门的学业一时候能够回滚, 不时候不可能回滚, 最终一丢丢调解开采中间有段修改表结构的语句, 最终促成回滚退步。

      希望那本书能像内行专家这样与您举办对话,用简短的标题、例子让您学到须求的文化。为了达到那样的指标,笔者会从每二个细节开端稳步的为我们建设构造概念,最后会给我们体现极大的实用例,在求学从前大概大家会认为这一个用例很难,不过如若跟着课程去学,相信非常的慢就会精通。
    Conventions and Styles 约定和编制程序风格
      每一遍自己想要演示实际代码时,作者会对mysql客户端的显示器就应时而生的代码举办调治,将字体制改进成Courier,使她们看起来与一般文书不同。
      在这里举个例证:mysql> DROP FUNCTION f;Query OK, 0 rows affected (0.00 sec)
      要是实例一点都不小,则要求在某个行和段落间加注释,同一时间自身会用将“
    mysql> CREATE PROCEDURE p ()
    -> BEGIN
    -> /* This procedure does nothing */  END;//Query OK, 0 rows affected (0.00 sec)
      临时候作者会将例子中的"mysql>"和"->"这个系统来得去掉,你能够一贯将代码复制到mysql客户端程序中(要是你以后所读的不是电子版的,能够在mysql.com网站下载相关脚本)所以的例子都早就在Suse 9.2 Linux、Mysql 5.0.3集体版上测量试验通过。
      在你读书本书的时候,Mysql已经有更加高的本子,同一时间能帮助愈来愈多OS了,包涵Windows,Sparc,HP-UX。由此这里的例子将能健康的运行在你的Computer上。但若是运营依然出现故障,能够咨询你认知的有名Mysql用户,以获取长时间的支撑和增加援救。
    Why MySQL Statements are Legal in a Procedure Body
      什么MySQL语句在蕴藏进度体中是法定的?
      什么样的SQL语句在Mysql存款和储蓄过程中才是合法的吧?你能够成立二个带有INSERT, UPDATE,DELETE, SELECT, DROP, CREATE, REPLACE等的语句。你独一须要记住的是纵然代码中隐含MySQL扩充成效,那么代码将不能够移植。在正规SQL语句中:任何数据库定义语言都是合法的,如:

     

       通过在MySQL 8.0中引进MySQL数据字典,能够实现Atomic DDL。在前期的MySQL版本中,元数据存款和储蓄在元数据文件,非事务性表和积累引擎特定的字典中,那须要中间提交。MySQL数据字典提供的集英式事务元数据存款和储蓄化解了这一障碍,使得将DDL语句操作结合为原子事务成为恐怕。

    (以下有所的斟酌都假定使用InnoDB存款和储蓄引擎)

     

    CREATE PROCEDURE p () DELETE FROM t; //
      SET、COMMIT以及ROLLBACK也是法定的,如:
    CREATE PROCEDURE p () SET @x = 5; //
      MySQL的附加功用:任何数据操作语言的说话都将法定。
    CREATE PROCEDURE p () DROP TABLE t; //
      MySQL扩张成效:直接的SELECT也是官方的:
    CREATE PROCEDURE p () SELECT 'a'; //
      顺便提一下,作者将积累进程中归纳DDL语句的成效称为MySQL附加成效的来由是在SQL规范中把那么些概念为非大旨的,就能够选组件。
    The New SQL Statements 新SQL语句
    Variables 变量
      在复合语句中声明变量的命令是DECLARE。
      (1) Example with two DECLARE statements
      多个DECLARE语句的例证 

       通过在MySQL 8.0中引进MySQL数据字典,可以完结Atomic DDL。在开始时代的MySQL版本中,元数据存款和储蓄在元数据文件,非事务性表和积攒引擎特定的字典中,那须要中间提交。MySQL数据字典提供的集英式事务元数据存款和储蓄消除了这一障碍,使得将DDL语句操作结合为原子事务成为恐怕。

    合克罗地亚共和国语档:

    到了8.0版本,大家了然全体的元数据现已联合用InnoDB来举办田间管理,那就给落到实处原子ddl带来了大概,差十分的少全部的对innodb表,存款和储蓄进度,触发器,视图也许UDF的操作,都能成就原子化:

    1.MySQL最常用的七个表类型: InnoDB和MyISAM。MyISAM类型的表强调的是性质,其施行数度比InnoDB类型更加快,不过不提供业务帮助,而InnoDB提供工作支持、存款和储蓄进度、视图、行级锁定等等高等数据库效率,若回滚退步,先反省表类型。 

    CREATE PROCEDURE p8 ()
    BEGIN
    DECLARE a INT;
    DECLARE b INT;
    SET a = 5;
    SET b = 5;
    INSERT INTO t VALUES (a);
    SELECT s1 * a FROM t WHERE s1 >= b;
    END; // /* I won't CALL this */
      在经过中定义的变量并非真正的定义,你只是在BEGIN/END块钦命义了而已(译注:也正是形参)。
    Error Handling 极度管理
      好了,大家今后要讲的是可怜管理
    1. Sample Problem: Log Of Failures 难题样例:故障记录
      当INSERT战败时,小编梦想能将其记录在日记文件中我们用来体现出错处理的主题材料样例是很
    一般性的。我期待收获错误的记录。当INSERT退步时,作者想在另一个文本中著录这个不当的
    新闻,比如出错开上下班时间间,出错原因等。笔者对插入特别感兴趣的来由是它将违反外键关联的自律
    2. Sample Problem: Log Of Failures (2)
    mysql> CREATE TABLE t2
    s1 INT, PRIMARY KEY (s1))
    engine=innodb;//
    mysql> CREATE TABLE t3 (s1 INT, KEY (s1),
    FOREIGN KEY (s1) REFERENCES t2 (s1))
    engine=innodb;//
    mysql> INSERT INTO t3 VALUES (5);//
    ...
    ERROR 1216 (23000): Cannot add or update a child row: a foreign key
    constraint fails(这里显得的是系统的失误音讯)
      作者起来要创立一个主键表,以及叁个外键表。我们使用的是InnoDB,因而外键关联合检查查是打
    开的。然后当本人向外键表中插入非主键表中的值时,动作将会停业。当然这种条件下得以很
    快找到错误号1216。
    3. Sample Problem: Log Of Failures

     

    - 元数据修改,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阶段的,就replay ddl log,把ddl完成掉;2. 如果处于某个中间态,则回滚ddl
    

    SHOW ENGINES 语句能够查阅当前的数据库协理的仓库储存类

    CREATE TABLE error_log (error_message
    CHAR(80))//
      下一步就是创建四个在做插入动作出错开上下班时间存款和储蓄错误的表。

    法定文书档案:

    1、支持的DDL语句

    出于引进了atomic ddl, 有个别ddl操作的作为也时有发生了变化:

    新葡亰496net 1

    你大概感兴趣的篇章:

    • MySQL存款和储蓄进度例子(包罗事务,输出参数,嵌套调用)
    • mysql 存款和储蓄进度中变量的定义与赋值操作
    • MySQL 有输入输出参数的囤积进程实例
    • mysql 动态试行存储进程语句
    • mysql 教程 存款和储蓄进度
    • mysql 存款和储蓄进度的标题
    • MySQL 存款和储蓄进度和"Cursor"的接纳方法
    • MySQL5创制存款和储蓄进程的亲自过问
    • MySQL与存款和储蓄进程的连带材质
    • php调用mysql存款和储蓄进程
    • MySQL 存款和储蓄进程的着力用法介绍

     原子DDL功效帮助表和非表DDL语句。与表相关的DDL操作供给仓库储存引擎辅助,而非表DDL操作则无需。近日,唯有InnoDB存储引擎协理原子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
    

     

     

    ①:受帮忙的表DDL语句包罗 CREATE,ALTEENCORE和 DROP对数据库,表,表和目录,以及讲话 TRUNCATE TABLE注脚。
    ②:帮忙的非表DDL语句满含:
       CREATE和DROP 语句,以及(即使适用)ALTE瑞鹰存款和储蓄程序,触发器,视图和用户定义函数(UDF)的语句。
       账户管理语句: CREATE,ALTE凯雷德, DROP,,假设适用, RENAME报表用户和剧中人物,以及GRANT 和REVOKE报表。

    MySQL很亲呢的加了四个抉择innodb_print_ddl_logs,张开后大家可以从错误日志看到相应的ddl log,上边大家因此那些来看下一些独立ddl的长河

    SHOW CREATE TABLE 表名;能够查看表的创立语句,最终有表的积累结构

     

    1.1、原子DDL功能不协助以下语句:

    root@ 11:12:19>SET GLOBAL innodb_print_ddl_logs = 1; Query OK, 0 rows affected root@ 11:12:22>SET GLOBAL log_error_verbosity = 3; Query OK, 0 rows affected 
    

    新葡亰496net 2

    1、支持的DDL语句

    ①:涉及除存储引擎之外的蕴藏引擎的与表相关的DDL语句InnoDB。
    ②:INSTALL PLUGIN和 UNINSTALL PLUGIN 陈述。
    ③:INSTALL COMPONENT和 UNINSTALL COMPONENT 陈述。
    ④:CREATE SERVER, ALTER SERVER和 DROP SERVER语句。

    CREATE DATABASE

    mysql> CREATE DATABASE test;Query OK, 1 row affected 
    

    成立数据库语句未有写log_ddl,恐怕感到那不是几度操作,即便成立database的进程中停业了,重启后也许必要手动删除目录。

    ALTE中华V TABLE 表名 ENGINE = InnoDB;修改表的囤积类型

     原子DDL成效支撑表和非表DDL语句。与表相关的DDL操作需求仓库储存引擎辅助,而非表DDL操作则无需。近些日子,独有InnoDB存款和储蓄引擎协助原子DDL。

    2、原子DDL特性:

    CREATE TABLE

    mysql> USE test;Database changedmysql> CREATE TABLE t1 (a INT PRIMARY KEY, b INT);Query OK, 0 rows affected [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 : 7InnoDB] DDL log post ddl : end for thread id : 7
    

    从日记来看有三类操作,实际上描述了一旦操作失利须要实行的三项逆向操作:删除数据文件,释放内部存款和储蓄器中的数目词典消息,删除索引btree。在创造表从前,那个数量被写入到ddl_log中,在开创完表并commit后,再从ddl log中去除那几个记录。别的上述日志中还应该有DDL log delete日志,其实在历次写入ddl log时是单身事务提交的,但在提交未来,会动用当前事情实践一条delete操作,直到操作结束了才会交到。

     

     

    ①:元数据更新,二进制日志写入和累积引擎操作(若是适用)将统一为单个事务。
    ②:在DDL操作时期,SQL层未有中间提交。
    ③:在适用的事态下:
        数据字典,程序,事件和UDF高速缓存的情景与DDL操作的情景同样,那意味更新的高峰速缓存以反映DDL操作是打响达成只怕回滚。
        DDL操作中关系的蕴藏引擎方法不施行中间提交,而且存款和储蓄引擎将自家注册为DDL事务的一有些。
        存储引擎支持DDL操作的重做和回滚,那在DDL操作的 Post-DDL阶段实行。
    ④:DDL操作的可知行为是原子的,那会转移某个DDL语句的行为

    加列

    mysql> ALTER TABLE t1 ADD COLUMN c INT;Query OK, 0 rows affected 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中无需记下数据

     

    ①:受帮助的表DDL语句蕴涵 CREATE,ALTE奥迪Q7和 DROP对数据库,表,表和目录,以及讲话 TRUNCATE TABLE申明。

    注意:

    删列

    mysql> ALTER TABLE t1 DROP COLUMN c;Query OK, 0 rows affected 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-1920598001.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-一九一六598002, 并将sql-ib1108-一九一九598001 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

    2.局地时候有些SQL语句会生出三个隐式的交由操作,即进行到位那几个言辞后,会有三个隐式的COMMIT操作。有以下SQL语句,不用你去“管”:

    ②:补助的非表DDL语句包罗:

      原子或别的DDL语句隐式结束方今对话中处于活动状态的任何事情,就象是你COMMIT在实行语句此前完成了平等。那表示DDL语句不可能在另三个作业中,在事情调整语句中推行START TRANSACTION ... COMMIT,只怕与一样业务中的别的语句结合使用。

    加索引

    mysql> ALTER TABLE t1 ADD KEY;Query OK, 0 rows affected 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,用于极度爆发时能够删除有时索引.

    • DDL语句,ALTER DATABASE、ALTER EVENT、ALTER PROCEDURE、ALTER TABLE、ALTER VIEW、CREATE TABLE、DROP TABLE、RENAME TABLE、TRUNCATE TABLE等;
    • 修改MYSQL架构的言语,CREATE USE奥德赛、DROP USECR-V、GRANT、RENAME USE昂Cora、REVOKE、SET PASSWO凯雷德D;
    • 管制语句,ANALYZE TABLE、CACHE INDEX、CHECK TABLE、LOAD INDEX INTO CACHE、OPTIMIZE TABLE、REPAI陆风X8 TABLE等

       CREATE和DROP 语句,以及(纵然适用)ALTE传祺存款和储蓄程序,触发器,视图和用户定义函数(UDF)的讲话。

    3、DDL语句行为的扭转

    TRUNCATE TABLE

    mysql> TRUNCATE TABLE t1;Query OK, 0 rows affected [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删除

    设计事务时,不应满含那类语句。如若在职业的前部中公告了多个不能够被回滚的语句,则后部的别的语句会发生错误,在这几个景况下,通过揭橥ROLLBACK语句不可能回滚事务的全部效应。

       账户管理语句: CREATE,ALTE陆风X8, DROP,,如若适用, RENAME报表用户和角色,以及GRANT 和REVOKE报表。

    3.1、DROP TABLE:

    RENAME TABLE

    mysql> RENAME TABLE t1 TO t2;Query OK, 0 rows affected 
    

    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不供给坚实在的操作

     

     

     如若具备命名表都施用原子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 COLLATE UTF8_BIN"); def->add_field(8, "new_file_path", "new_file_path VARCHAR COLLATE UTF8_BIN"); def->add_index(0, "index_pk", "PRIMARY KEY; def->add_index(1, "index_k_thread_id", "KEY(thread_id)");
    

     

    1.1、原子DDL效用不帮衬以下语句:

    DROP TABLE假设命名表不设有,况兼未实行任何变动(无论存款和储蓄引擎怎样),则会停业并呈现错误。如下所示:

    记录类型

    依据分裂的操作类型,能够分成如下几类:

    1. FREE_TREE_LOG目标是释放索引btree,入口函数log_DDL::write_free_tree_log,在开立索引和删除表时会调用到

    对此drop table中关系的删索引操作,log ddl的插入操作放到父事务中,一齐或然提交要么回滚对于开创索引的case, log ddl就须求独自提交,父事务将记录标志删除,这样后边借使ddl回滚了,也能将残留的index删掉。

    1. 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操作. 写日记的进度同样是单独工作提交,父事务做未提交的去除操作

    1. DROP_LOG

    入口函数: Log_DDL::write_drop_log

    用以记录删除表对象操作,这里不关乎文件层操作,写ddl log在父事务中施行

    1. RENAME_TABLE_LOG

    入口函数: Log_DDL::write_rename_table_log

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

    1. REMOVE_CACHE_LOG

    入口函数: Log_DDL::write_remove_cache_log

    用来拍卖内部存款和储蓄器表对象的清理,独立职业提交,父事务标识删除

    1. 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 并付出, (近日只有ALTEKuga_ENCRYPT_TABLESPACE_LOG)
    • 运用父事务写ddl log,在ddl甘休时交由。供给在post-ddl阶段管理

    MySQL 数据表首要支持多样档案的次序,分别是:BDB、HEAP、ISAM、ME汉兰达GE、MYISAM、InnoBDB。

    ①:涉及除存款和储蓄引擎之外的积存引擎的与表相关的DDL语句InnoDB。

    mysql> CREATE TABLE t1 (c1 INT);
    mysql> DROP TABLE t1, t2;
    ERROR 1051 (42S02): Unknown table 'test.t2'
    mysql> SHOW TABLES;
     ---------------- 
    | Tables_in_test |
     ---------------- 
    | t1    |
     ---------------- 
    

    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后,清理对应记录

    这种种又分为两类,一类是“事务安全型”(transaction-safe),包含BDB和InnoDB;别的都属于第二类,称为”非事务安全型”(non-transaction-safe)。

    ②:INSTALL PLUGIN和 UNINSTALL PLUGIN 陈述。

    在引进原子DDL以前, DROP TABLE尽管会报错误表不设有,可是存在的表会被施行成功,如下:

    崩溃复苏

    在崩溃苏醒甘休后,会调用ha_post_recover接口函数,进而调用innodb内的函数Log_DDL::recover(), 同样的replay在那之中的笔录,并在结束后去除记录。但ALTEKoleos_ENCRYPT_TABLESPACE_LOG类型并非在这一步删除,而是参预到一个数组ts_encrypt_ddl_records中,在后头调用resume_alter_encrypt_tablespace来过来操作,

    主题材料一蹴而就:

    ③:INSTALL COMPONENT和 UNINSTALL COMPONENT 陈述。

    mysql> CREATE TABLE t1 (c1 INT);
    mysql> DROP TABLE t1, t2;
    ERROR 1051 (42S02): Unknown table 'test.t2'
    mysql> SHOW TABLES;
    Empty set (0.00 sec)
    

    参照文书档案

    1. 合匈牙利(Hungary)语档2. wl#9536: support crash safe ddl

    正文小编:zhaiwx_yinfeng

    翻阅原来的文章

    正文为云栖社区原创内容,未经允许不得转发。

      存储引擎说白了正是何许存款和储蓄数据、怎样为存储的数码建设构造目录和怎么样立异、查询数据等技能的完结格局。因为在事关数据库中多少的积攒是以表的样式积累的,所以存款和储蓄引擎也足以称为表类型(即存款和储蓄和操作此表的类型)。

    ④:CREATE SERVER, ALTER SERVER和 DROP SERVER语句。

    注意:

    InnoDB 是较新的政工业安全全型存款和储蓄引擎,用于事务处理应用程序,帮助BDB的大致具备天性,并具备众多新特色,包蕴ACID事务补助。

     

       由于作为的这种变动,DROP TABLE会在 MySQL 5.7主服务器上的有些产生语句在MySQL 8.0从服务器上复制时退步。要制止此故障意况,请在DROP TABLE语句中采取IF EXISTS语法以免备对空中楼阁的表发生错误

    特性:

    2、原子DDL特性:

    3.2、DROP DATABASE:

    事务管理机制 
    帮忙外链 
    崩溃后能立即恢复生机 
    协理外键功效,级联删除 
    扶助并发技艺 
    在硬盘上的存放方式:InnoBDB frm

    ①:元数据更新,二进制日志写入和仓库储存引擎操作(若是适用)将联合为单个事务。

       假使具备表都使用原子DDL援救的仓库储存引擎,则为atomic。该语句要么成功删除全体目的,要么回滚。可是,从文件系统中剔除数据库目录是最后叁遍,况兼不是原子事务的一有的。借使是因为文件系统错误或服务器暂停而产生数据库目录的删除失利, DROP DATABASE则不会回滚事务。

    新式版本的Mysql已经布署移除对BDB的支撑,转而使劲升高InnoDB。InnoDB对Mysql有更加好的个性援助,并且开荒社区活泼。

    ②:在DDL操作期间,SQL层未有中间提交。

    3.3、对于不采取原子DDL帮忙的蕴藏引擎的表,表删除产生在原子 DROP TABLE或 DROP DATABASE事务之外。那样的表删除被单独写入二进制日志,那在行车制动器踏板DROP TABLE或 DROP DATABASE操作的情况下将积攒引擎,数据字典和二进制日志之间的歧异限制为最多二个表 。对于删除多个表的操作,不选拔原子DDL辅助的蕴藏引擎的表将在实践以前删除。

      MyISAM 暗中同意的MySQL插件式存款和储蓄引擎,它是依附ISAM类型,但它增添了过多平价的恢宏,它是在Web、数据存款和储蓄和别的应用境况下最常使用的储存引擎之一。注意,通过改动STORAGE_ENGINE配置变量,能够方便地转移MySQL服务器的暗中同意存储引擎。 
    优点:

    ③:在适用的情景下:

    3.4、CREATE TABLE, ALTE奇骏 TABLE, RENAME TABLE, TRUNCATE TABLE, CREATE TABLESPACE,和 DROP TABLESPACE对运用原子DDL协理的储存引擎表实施的操作依旧完全交由或只要服务器的操作时停下回滚。在开始时期的MySQL版本中,这一个操作的行车制动器踏板大概会招致存款和储蓄引擎,数据字典和二进制日志之间的差别,或留下孤立文件。RENAME TABLE如若全数命名表都应用原子DDL支持的存款和储蓄引擎,则操作只是原子操作。

    1.比ISAM表越来越小,所占能源越来越少 
    2.方可在分化平台间二进制移植表的花色在开立表时内定。

        数据字典,程序,事件和UDF高速缓存的景况与DDL操作的处境同样,那意味更新的高峰速缓存以展现DDL操作是大功告成做到只怕回滚。

    3.5、DROP VIEW:

        DDL操作中提到的仓库储存引擎方法不进行中间提交,并且存款和储蓄引擎将小编注册为DDL事务的一有的。

     要是命名视图官样文章且未进行别的改变,则会倒闭。在此示例中示范了行为改变,在那之中DROP VIEW语句退步,因为命名视图不设有,如下:

        存储引擎扶助DDL操作的重做和回滚,那在DDL操作的 Post-DDL阶段施行。

    mysql> CREATE VIEW test.viewA AS SELECT * FROM t;
    mysql> DROP VIEW test.viewA, test.viewB;
    ERROR 1051 (42S02): Unknown table 'test.viewB'
    mysql> SHOW FULL TABLES IN test WHERE TABLE_TYPE LIKE 'VIEW';
     ---------------- ------------ 
    | Tables_in_test | Table_type |
     ---------------- ------------ 
    | viewA   | VIEW  |
     ---------------- ------------ 
    

    ④:DDL操作的可见行为是原子的,那会退换有个别DDL语句的一言一动

    在引进原子DDL在此之前, 使用DROP VIEW删除视图会报错,不过存在的视图会被成功删除:

     

    mysql> CREATE VIEW test.viewA AS SELECT * FROM t;
    mysql> DROP VIEW test.viewA, test.viewB;
    ERROR 1051 (42S02): Unknown table 'test.viewB'
    mysql> SHOW FULL TABLES IN test WHERE TABLE_TYPE LIKE 'VIEW';
    Empty set (0.00 sec)
    

    注意:

    注意:

      原子或别的DDL语句隐式截至近期对话中居于活动状态的其余业务,就类似你COMMIT在实施语句以前完结了同等。那意味DDL语句不可能在另二个事情中,在业务调整语句中奉行START TRANSACTION ... COMMIT,或然与平等业务中的其余语句结合使用。

       由于表现的这种改造,DROP VIEW在MySQL 5.7主服务器上的一对成功 操作在MySQL 8.0从服务器上复制时会退步。要防止此故障意况,请在DROP VIEW语句中使用IF EXISTS语法以防守对不设有的视图爆发错误。

     

    3.6、不再允许一部分进行帐户管理评释。帐户管理语句对富有命名用户成功或回滚,假使产生错误则不行。在早先时代的MySQL版本中,为七个用户命名的帐户管理语句大概对一些用户成功,而对其余用户则战败。

    3、DDL语句行为的改动

    一般来讲:当中第三个CREATE USETiguan语句重临错误但为山止篑,因为它无法对全体命名用户成功。

    3.1、DROP TABLE:

    mysql> CREATE USER userA;
    mysql> CREATE USER userA, userB;
    ERROR 1396 (HY000): Operation CREATE USER failed for 'userA'@'%'
    mysql> SELECT User FROM mysql.user WHERE User LIKE 'user%';
     ------- 
    | User |
     ------- 
    | userA |
     ------- 
    

     假使持有命名表都应用原子DDL帮助的存款和储蓄引擎,则操作是完全原子的。该语句要么成功删除全部表,要么回滚。

    在引进原子DDL在此之前,首个 使用CREATE USE凯雷德语句创立用户会回去一个荒唐,可是不真实的用户会成功创设,:

    DROP TABLE假如命名表不真实,何况未开始展览另外改造(无论存款和储蓄引擎怎么着),则会失利并出示错误。如下所示:

    mysql> CREATE USER userA;
    mysql> CREATE USER userA, userB;
    ERROR 1396 (HY000): Operation CREATE USER failed for 'userA'@'%'
    mysql> SELECT User FROM mysql.user WHERE User LIKE 'user%';
     ------- 
    | User |
     ------- 
    | userA |
    | userB |
     ------- 
    

     

    注意:

    mysql> CREATE TABLE t1 (c1 INT);

       由于展现的这种变动,MySQL 5.7主服务器上部分会成功执行,会在MySQL 8.0从服务器上复制时失利。要制止此故障情形,请在创制用户的吩咐中运用IF EXISTS或 IF NOT EXISTS语法,以卫戍与命名用户相关的一无所长。

    mysql> DROP TABLE t1, t2;

    4、存款和储蓄引擎帮助:最近唯有innodb存储引擎辅助原子DDL

    ERROR 1051 (42S02): Unknown table 'test.t2'

       近些日子,唯有InnoDB存款和储蓄引擎协助原子DDL。不帮忙原子DDL的存放引擎免于DDL原子性。涉及豁免存款和储蓄引擎的DDL操作还是能够够引入操作停顿或唯有的成功时恐怕发生的不雷同。
       要扶助重做和回滚DDL操作, InnoDB请将DDL日志写入 mysql.innodb_ddl_log表,该表是驻留在mysql.ibd数据字典表空间中的掩盖数据字典表 。
    要mysql.innodb_ddl_log在DDL操作时期查看写入表的DDL日志 ,请启用 innodb_print_ddl_logs 配置选项。

    mysql> SHOW TABLES;

    注意:

    ----------------

    mysql.innodb_ddl_log无论innodb_flush_log_at_trx_commit 设置有个别,对表的 改造的重做日志 都会即时刷新到磁盘 。马上刷新重做日志能够免止DDL操作修改数据文件的情状,可是mysql.innodb_ddl_log由这个操作爆发的对表的改动的重做日志 不会持久保存到磁盘。这种情况恐怕会在回滚或复苏时期产生错误。

    | Tables_in_test |

    InnoDB存款和储蓄引擎分等第实践DDL操作。DDL操作 ALTER TABLE能够在Commit阶段在此之前每每实行 Prepare和Perform阶段:

    ----------------

    预备:创立所需对象并将DDL日志写入 mysql.innodb_ddl_log表中。DDL日志定义了怎样前滚和回滚DDL操作。
    举行:施行DDL操作。比如,为CREATE TABLE操作试行创立例程。
    交由:更新数据字典并交由数据字典事务。
    Post-DDL:重放并从mysql.innodb_ddl_log表中剔除DDL日志。为了保证可以安全地进行回滚而不引进差别性,在终极阶段试行文书操作,举个例子重命名或删除数据文件。这一等第还从删除的动态元数据 mysql.innodb_dynamic_metadata的数额字典表DROP TABLE,TRUNCATE TABLE和该重新创立表其余DDL操作。

    | t1             |

    注意:

    新葡亰496net:0新特性之支持原子DDL语句,table导致的mysql事务回滚失败。 ----------------

      无论专门的职业是付诸依旧回滚, DDL日志都会在Post-DDL阶段重放并从表中删除 。mysql.innodb_ddl_log若是服务器在DDL操作时期暂停,则DDL日志应仅保留在表中。在这种处境下,DDL日志将要回复后重放并剔除。

    在引进原子DDL在此以前, DROP TABLE固然会报错误表不设有,不过存在的表会被试行成功,如下:

      在恢复生机景况下,可以在再度开动服务器时提交或回滚DDL事务。借使在重做日志和二进制日志中设有在DDL操作的交付阶段之间实行的数据字典事务,则 该操作被视为成功还要前滚。不然,在InnoDB重播数据字典重做日志时回滚不完整的数目字典事务 ,并回滚DDL事务。

    mysql> CREATE TABLE t1 (c1 INT);

    5、查看DDL日志:

    mysql> DROP TABLE t1, t2;

       InnoDB将DDL日志写入 mysql.innodb_ddl_log表以扶助重做和回滚DDL操作。该 mysql.innodb_ddl_log表是隐匿在mysql.ibd数据字典表空间中的遮掩数据字典表 。与其他遮盖数据字典表一样,mysql.innodb_ddl_log在非调节和测量试验版本的MySQL中不大概直接采访该 表。

    ERROR 1051 (42S02): Unknown table 'test.t2'

    mysql> SHOW TABLES;

    Empty set (0.00 sec)

     

    注意:

       由于表现的这种改造,DROP TABLE会在 MySQL 5.7主服务器上的一对成功 语句在MySQL 8.0从服务器上复制时失利。要幸免此故障情况,请在DROP TABLE语句中使用IF EXISTS语法防止止对不设有的表发生错误

     

    3.2、DROP DATABASE:

       就算持有表都使用原子DDL援救的储存引擎,则为atomic。该语句要么成功删除全数目的,要么回滚。不过,从文件系统中删除数据库目录是最终一回,何况不是原子事务的一有的。借使是因为文件系统错误或服务器暂停而导致数据库目录的删除失利, DROP DATABASE则不会回滚事务。

     

    3.3、对于不应用原子DDL援救的存放引擎的表,表删除产生在原子 DROP TABLE或 DROP DATABASE事务之外。这样的表删除被单独写入二进制日志,那在脚刹踏板DROP TABLE或 DROP DATABASE操作的气象下将储存引擎,数据字典和二进制日志之间的差异限制为最多二个表 。对于删除五个表的操作,不应用原子DDL接济的积攒引擎的表将要实施以前剔除。

     

    3.4、CREATE TABLE, ALTEEvoque TABLE, RENAME TABLE, TRUNCATE TABLE, CREATE TABLESPACE,和 DROP TABLESPACE对使用原子DDL补助的积累引擎表推行的操作依然完全交由或只要服务器的操作时停下回滚。在前期的MySQL版本中,那个操作的间歇或然会促成存款和储蓄引擎,数据字典和二进制日志之间的差别,或留下孤立文件。RENAME TABLE若是全部命名表都施用原子DDL援助的累积引擎,则操作只是原子操作。

     

    3.5、DROP VIEW:

     借职分名视图空头支票且未实行任何改造,则会倒闭。在此示例中示范了行为改造,个中DROP VIEW语句失利,因为命名视图不设有,如下:

    mysql> CREATE VIEW test.viewA AS SELECT * FROM t;

    mysql> DROP VIEW test.viewA, test.viewB;

    ERROR 1051 (42S02): Unknown table 'test.viewB'

    mysql> SHOW FULL TABLES IN test WHERE TABLE_TYPE LIKE 'VIEW';

    ---------------- ------------

    | Tables_in_test | Table_type |

    ---------------- ------------

    | viewA          | VIEW       |

    ---------------- ------------

    在引进原子DDL在此以前, 使用DROP VIEW删除视图会报错,不过存在的视图会被成功删除:

    mysql> CREATE VIEW test.viewA AS SELECT * FROM t;

    mysql> DROP VIEW test.viewA, test.viewB;

    ERROR 1051 (42S02): Unknown table 'test.viewB'

    mysql> SHOW FULL TABLES IN test WHERE TABLE_TYPE LIKE 'VIEW';

    Empty set (0.00 sec)

     

    注意:

       由于作为的这种转移,DROP VIEW在MySQL 5.7主服务器上的局地形成操作在MySQL 8.0从服务器上复制时会失利。要防止此故障情形,请在DROP VIEW语句中央银行使IF EXISTS语法防止御对子虚乌有的视图发生错误。

     

    3.6、不再允许一些进行帐户管理证明。帐户管理语句对具备命名用户成功或回滚,假若产生错误则不算。在早先时代的MySQL版本中,为四个用户命名的帐户管理语句恐怕对某个用户成功,而对别的用户则失利。

    如下:个中第三个CREATE USE凯雷德语句再次来到错误但满盘皆输,因为它不能对具备命名用户成功。

    mysql> CREATE USER userA;

    mysql> CREATE USER userA, userB;

    ERROR 1396 (HY000): Operation CREATE USER failed for 'userA'@'%'

    mysql> SELECT User FROM mysql.user WHERE User LIKE 'user%';

    -------

    | User  |

    -------

    | userA |

    -------

    在引进原子DDL从前,第四个 使用CREATE USE卡宴语句创立用户会回来八个荒谬,不过不真实的用户会顺理成章成立,:

    mysql> CREATE USER userA;

    mysql> CREATE USER userA, userB;

    ERROR 1396 (HY000): Operation CREATE USER failed for 'userA'@'%'

    mysql> SELECT User FROM mysql.user WHERE User LIKE 'user%';

    -------

    | User  |

    -------

    | userA |

    | userB |

    -------

     

    注意:

       由于展现的这种更换,MySQL 5.7主服务器上部分会成功实践,会在MySQL 8.0从服务器上复制时退步。要幸免此故障情形,请在开创用户的命令中利用IF EXISTS或 IF NOT EXISTS语法,避防备与命名用户相关的荒唐。

     

    4、存款和储蓄引擎帮衬:近期唯有innodb存款和储蓄引擎帮忙原子DDL

       前段时间,唯有InnoDB存款和储蓄引擎扶助原子DDL。不援救原子DDL的存款和储蓄引擎免于DDL原子性。涉及豁免存款和储蓄引擎的DDL操作仍是可以够引进操作停顿或唯有的产生时恐怕产生的差别。

       要帮衬重做和回滚DDL操作, InnoDB请将DDL日志写入 mysql.innodb_ddl_log表,该表是驻留在mysql.ibd数据字典表空间中的遮蔽数据字典表 。

    要mysql.innodb_ddl_log在DDL操作时期查看写入表的DDL日志 ,请启用 innodb_print_ddl_logs 配置选项。

     

    注意:

    mysql.innodb_ddl_log无论innodb_flush_log_at_trx_commit 设置有个别,对表的 改换的重做日志 都会立即刷新到磁盘 。立时刷新重做日志可以制止DDL操作修改数据文件的景观,可是mysql.innodb_ddl_log由那一个操作发生的对表的改观的重做日志 不会长久保存到磁盘。这种景色也许会在回滚或苏醒时期变成错误。

     

    InnoDB存款和储蓄引擎分等级实践DDL操作。DDL操作 ALTER TABLE能够在Commit阶段从前反复进行 Prepare和Perform阶段:

     

    计划:创造所需对象并将DDL日志写入 mysql.innodb_ddl_log表中。DDL日志定义了怎么前滚和回滚DDL操作。

    奉行:推行DDL操作。比方,为CREATE TABLE操作执行创设例程。

    交付:更新数据字典并交付数据字典事务。

    Post-DDL:回看并从mysql.innodb_ddl_log表中去除DDL日志。为了确定保障能够安全地推行回滚而不引进不一样性,在晚期实践文书操作,比方重命名或删除数据文件。这一等级还从删除的动态元数据 mysql.innodb_dynamic_metadata的数据字典表DROP TABLE,TRUNCATE TABLE和该重新建立表别的DDL操作。

     

    注意:

      无论职业是付出照旧回滚, DDL日志都会在Post-DDL阶段重播并从表中删除 。mysql.innodb_ddl_log借使服务器在DDL操作时期暂停,则DDL日志应仅保留在表中。在这种景况下,DDL日志就要还原后重播并剔除。

     

      在回复景况下,能够在重新开动服务器时提交或回滚DDL事务。若是在重做日志和二进制日志中设有在DDL操作的交给阶段之间执行的多少字典事务,则 该操作被视为成功还要前滚。不然,在InnoDB回看数据字典重做日志时回滚不完全的数量字典事务 ,并回滚DDL事务。

     

    5、查看DDL日志:

       InnoDB将DDL日志写入 mysql.innodb_ddl_log表以支撑重做和回滚DDL操作。该 mysql.innodb_ddl_log表是遮蔽在mysql.ibd数据字典表空间中的掩盖数据字典表 。与其余隐敝数据字典表一样,mysql.innodb_ddl_log在非调试版本的MySQL中无法间接访问该 表。

    本文由新葡亰496net发布于网络数据库,转载请注明出处:新葡亰496net:0新特性之支持原子DDL语句,table导

    关键词:

上一篇:新葡亰496net存储过程,MySQL中的存储过程

下一篇:没有了