content_image/744196.jpg
## Atomic DDL Characteristics 

• CREATE SERVER , ALTER SERVER , and DROP SERVER  statements. 

The characteristics of atomic DDL statements include the following: 

•Metadata updates, binary log writes, and storage engine operations, where applicable, are combined into a single atomic operation. 

•There are no intermediate commits at the SQL layer during the DDL operation. 

•Where applicable: 

•The state of data dictionary, routine, event, and loadable function caches is consistent with the status of the DDL operation, meaning that caches are updated to reflect whether or not the DDL operation was completed successfully or rolled back. 

•The storage engine methods involved in a DDL operation do not perform intermediate commits, and the storage engine registers itself as part of the DDL operation. 

•The storage engine supports redo and rollback of DDL operations, which is performed in the Post-DDL phase of the DDL operation. 

•The visible behaviour of DDL operations is atomic, which changes the behavior of some DDL statements. See Changes in DDL Statement Behavior. 

## Changes in DDL Statement Behavior 

This section describes changes in DDL statement behavior due to the introduction of atomic DDL support. 

• DROP TABLE  operations are fully atomic if all named tables use an atomic DDL-supported storage engine. The statement either drops all tables successfully or is rolled back. 

DROP TABLE  fails with an error if a named table does not exist, and no changes are made, regardless of the storage engine. This change in behavior is demonstrated in the following example, where the DROP TABLE  statement fails because a named table does not exist: 

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 | +----------------+ 

Prior to the introduction of atomic DDL, DROP TABLE  reports an error for the named table that does not exist but succeeds for the named table that does exist: 

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) 

<img src='content_image/744196.jpg'>

## Note 

Due to this change in behavior, a partially completed DROP TABLE  statement on a MySQL 5.7 replication source server fails when replicated on a MySQL 8.0 

