前言

在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)");

記錄類型

根據不同的操作類型，可以分為如下幾類：

1. FREE_TREE_LOG
2. 目的是釋放索引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 並提交, (目前只有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來恢復操作，

參考文檔