2467 Atomic Data Definition Statement Support replica. To avoid this failure scenario, use  IF EXISTS  syntax in  DROP TABLE statements to prevent errors from occurring for tables that do not exist. • DROP DATABASE  is atomic if all tables use an atomic DDL-supported storage engine. The statement either drops all objects successfully or is rolled back. However, removal of the database directory from the file system occurs last and is not part of the atomic operation. If removal of the database directory fails due to a file system error or server halt, the  DROP DATABASE  transaction is not rolled back. •For tables that do not use an atomic DDL-supported storage engine, table deletion occurs outside of the atomic  DROP TABLE  or  DROP DATABASE  transaction. Such table deletions are written to the binary log individually, which limits the discrepancy between the storage engine, data dictionary, and binary log to one table at most in the case of an interrupted  DROP TABLE  or  DROP DATABASE  operation. For operations that drop multiple tables, the tables that do not use an atomic DDL-supported storage engine are dropped before tables that do. • CREATE TABLE ,  ALTER TABLE ,  RENAME TABLE ,  TRUNCATE TABLE ,  CREATE TABLESPACE , and DROP TABLESPACE  operations for tables that use an atomic DDL-supported storage engine are either fully committed or rolled back if the server halts during their operation. In earlier MySQL releases, interruption of these operations could cause discrepancies between the storage engine, data dictionary, and binary log, or leave behind orphan files.  RENAME TABLE  operations are only atomic if all named tables use an atomic DDL-supported storage engine. •As of MySQL 8.0.21, on storage engines that support atomic DDL, the  CREATE TABLE ... SELECT statement is logged as one transaction in the binary log when row-based replication is in use. Previously, it was logged as two transactions, one to create the table, and the other to insert data. A server failure between the two transactions or while inserting data could result in replication of an empty table. With the introduction of atomic DDL support,  CREATE TABLE ... SELECT  statements are now safe for row- based replication and permitted for use with GTID-based replication. • DROP VIEW  fails if a named view does not exist, and no changes are made. The change in behavior is demonstrated in this example, where the  DROP VIEW  statement fails because a named view does not exist: On storage engines that support both atomic DDL and foreign key constraints, creation of foreign keys is not permitted in  CREATE TABLE ... SELECT  statements when row-based replication is in use. Foreign key constraints can be added later using  ALTER TABLE . When  CREATE TABLE ... SELECT  is applied as an atomic operation, a metadata lock is held on the table while data is inserted, which prevents concurrent access to the table for the duration of the operation. Prior to the introduction of atomic DDL,  DROP VIEW  returns an error for the named view that does not exist but succeeds for the named view that does exist: 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 | +----------------+------------+ 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)