柯煜昌 青云科技研發(fā)顧問級工程師 目前從事 RadonDB 容器化研發(fā)枫虏，華中科技大學研究生畢業(yè)，有多年的數(shù)據(jù)庫內(nèi)核開發(fā)經(jīng)驗耀盗。
文章字數(shù) 3800+认然，閱讀時間 15 分鐘
背景
MySQL 5.7 的字典信息保存在非事務表中，并且存放在不同的文件中（.FRM酌伊，.PAR腾窝，.OPT，.TRN居砖，.TRG 等)虹脯。所有 DDL 操作都不是 Crash Safe，而且對于組合 DDL（ALTER 多個表）會出現(xiàn)有的成功有的失敗的情況奏候，而不是總體失敗循集。這樣主從復制就出現(xiàn)了問題，也導致基于復制的高可用系統(tǒng)不再安全鼻由。
MySQL 8.0 推出新特性 - 原子 DDL暇榴，解決了以上的問題厚棵。
什么是原子 DDL蕉世？
DDL 是指數(shù)據(jù)定義語言（Data Definition Language）蔼紧，負責數(shù)據(jù)結(jié)構的定義與數(shù)據(jù)對象的定義。原子 DDL 是指一個 DDL 操作是不可分割的狠轻，要么全成功要么全失敗奸例。
有哪些限制？
MySQL 8.0 只有 InnoDB 存儲引擎支持原子 DDL向楼。
支持語句：數(shù)據(jù)庫查吊、表空間、表湖蜕、索引的 CREATE逻卖、ALTER 以及 DROP 語句，以及 TRUNCATE TABLE 語句昭抒。
MySQL 8.0 系統(tǒng)表均以 InnoDB 存儲引擎存儲评也，涉及到字典對象的均支持原子 DDL。
支持的語句：存儲過程灭返、觸發(fā)器盗迟、視圖以及用戶定義函數(shù)（UDF）的 CREATE 和 DROP 、ALTER 操作熙含，用戶和角色的 CREATE罚缕、ALTER、DROP 語句怎静，以及適用的 RENAME 語句邮弹，以及 GRANT 和 REVOKE 語句。
不支持的語句：
- INSTALL PLUGIN蚓聘、UNINSTALL PLUGIN
- INSTALL COMPONENT肠鲫、UNINSTALL COMPONENT
- REATE SERVER、ALTER SERVER或粮、DROP SERVER
實現(xiàn)原理是什么导饲？
首先，8.0 將字典信息存放到事務引擎的系統(tǒng)表（InnoDB 存儲引擎）中氯材。這樣 DDL 操作轉(zhuǎn)變成一組對系統(tǒng)表的 DML 操作渣锦，從而失敗后可以依據(jù)事務引擎自身的事務回滾保證系統(tǒng)表的原子性。
似乎 DDL 原子性就此就可以完成氢哮，但實際上并沒有這么簡單袋毙。首先字典信息不光是系統(tǒng)表，還有一組字典緩存冗尤，如：
- Table Share 緩存
- DD 緩存
- InnoDB 中的 dict
此外听盖，字典信息只是數(shù)據(jù)庫對象的元數(shù)據(jù)胀溺，DDL 操作不光要修改字典信息，還要實實在在的操作對象皆看，以及對象本身在內(nèi)存中緩存仓坞。
- 表空間
- Dynamic meta
- Btree
- ibd 文件
- buffer pool 中表空間的 page 頁
此外，binlog 也要考慮 DDL 失敗的情況腰吟。
因此无埃，原子 DDL 在處理 DDL 失敗的時候，不光是直接回滾系統(tǒng)表的數(shù)據(jù)毛雇，而且也要保證內(nèi)存緩存嫉称，數(shù)據(jù)庫對象也能回滾到一致狀態(tài)。
實現(xiàn)細節(jié)
為了解決 DDL 失敗情況中數(shù)據(jù)庫對象的回滾灵疮，8.0 引入了系統(tǒng)表 DDL_LOG织阅。該表在 mysql 庫中。不可見震捣，也不能人為操作荔棉。如果想了解該表的結(jié)果，先編譯一個 debug 版的 MySQL：
SET SESSION debug='+d,skip_dd_table_access_check';
show create table mysql.innodb_ddl_log;
可以看到如下表結(jié)構：
CREATE TABLE `innodb_ddl_log` (
`id` bigint unsigned NOT NULL AUTO_INCREMENT,
`thread_id` bigint unsigned NOT NULL,
`type` int unsigned NOT NULL,
`space_id` int unsigned DEFAULT NULL,
`page_no` int unsigned DEFAULT NULL,
`index_id` bigint unsigned DEFAULT NULL,
`table_id` bigint unsigned DEFAULT NULL,
`old_file_path` varchar(512) CHARACTER SET utf8 COLLATE utf8_bin DEFAULT NULL,
`new_file_path` varchar(512) CHARACTER SET utf8 COLLATE utf8_bin DEFAULT NULL,
PRIMARY KEY (`id`),
KEY `thread_id` (`thread_id`)
) /*!50100 TABLESPACE `mysql` */ ENGINE=InnoDB AUTO_INCREMENT=48 DEFAULT CHARSET=utf8 COLLATE=utf8_bin STATS_PERSISTENT=0 ROW_FORMAT=DYNAMIC
在 8.0 中伍派，這個表需要滿足兩個場景以及兩個任務：
場景 1: 符合 DDL 失敗的場景江耀，需要回滾部分完成的 DDL。
場景 2：DDL 進行中诉植，發(fā)生故障（掉電祥国、軟硬件故障等），重啟機器需要完成部分 DDL晾腔。
兩個任務：
任務 1：失敗后回滾舌稀，執(zhí)行反向操作。
任務 2：如果成功灼擂，則執(zhí)行清理工作壁查。
也許有人會問，為什么執(zhí)行成功需要執(zhí)行清理工作呢剔应？
之所以要執(zhí)行清理工作睡腿，因為 ibd 文件和索引一旦刪除就不能恢復。為了實現(xiàn)回滾峻贮，DDL 刪除這些對象時候席怪，并不是真正刪除，而是先將它們備份一下纤控，以備回滾時使用挂捻。所以只有確認 DDL 已經(jīng)執(zhí)行成功，這些備份對象不需要了船万，才執(zhí)行清理工作刻撒。
舉個例子
為了將這個原理將清楚骨田，我們流程相對簡單的 CREATE TABLE 講起，管中窺豹声怔，可見一斑态贤。假設已經(jīng)有編譯好了 8.0 debug 版本，并且 innodb_file_per_table 為 on捧搞，先執(zhí)行以下命令：
mysql> set global log_error_verbosity=3;
Query OK, 0 rows affected (0.00 sec)
mysql> set global innodb_print_ddl_logs = on;
Query OK, 0 rows affected (0.00 sec)
從而開啟了ddl log的日志抵卫，然后創(chuàng)建表：
mysql> create table t2 (a int);
Query OK, 0 rows affected (25 min 26.42 sec)
可以看到如下日志：
XXXXX 8 [Note] [MY-012473] [InnoDB] DDL log insert : [DDL record: DELETE SPACE, id=20, thread_id=8, space_id=6, old_file_path=./test/t2.ibd]
XXXXX 8 [Note] [MY-012478] [InnoDB] DDL log delete : 20
XXXXX 8 [Note] [MY-012477] [InnoDB] DDL log insert : [DDL record: REMOVE CACHE, id=21, thread_id=8, table_id=1067, new_file_path=test/t2]
XXXXX 8 [Note] [MY-012478] [InnoDB] DDL log delete : 21
XXXXX 8 [Note] [MY-012472] [InnoDB] DDL log insert : [DDL record: FREE, id=22, thread_id=8, space_id=6, index_id=157, page_no=4]
XXXXX 8 [Note] [MY-012478] [InnoDB] DDL log delete : 22
XXXXX 8 [Note] [MY-012485] [InnoDB] DDL log post ddl : begin for thread id : 8
XXXXX 8 [Note] [MY-012486] [InnoDB] DDL log post ddl : end for thread id : 8
create table 的 DDL 只有反向操作日志記錄狮荔，而無清理操作日志記錄胎撇。細心的讀者可能看到日志中插入某條 DDL log，隨后又將其刪除殖氏，會心生疑惑晚树。但這正是 MySQL 原子 DDL 的秘密所在。我們選 DELETE SPACE 這個 DDL 日志寫入函數(shù)Log_DDL::write_delete_space_log 來揭秘這個過程雅采。
dberr_t Log_DDL::write_delete_space_log(trx_t *trx, const dict_table_t *table,
space_id_t space_id,
const char *file_path, bool is_drop,
bool dict_locked) {
ut_ad(trx == thd_to_trx(current_thd));
ut_ad(table == nullptr || dict_table_is_file_per_table(table));
if (skip(table, trx->mysql_thd)) {
return (DB_SUCCESS);
}
uint64_t id = next_id();
ulint thread_id = thd_get_thread_id(trx->mysql_thd);
dberr_t err;
trx->ddl_operation = true;
DBUG_INJECT_CRASH("ddl_log_crash_before_delete_space_log",
crash_before_delete_space_log_counter++);
if (is_drop) { //（1）
err = insert_delete_space_log(trx, id, thread_id, space_id, file_path,
dict_locked);
if (err != DB_SUCCESS) {
return err;
}
DBUG_INJECT_CRASH("ddl_log_crash_after_delete_space_log",
crash_after_delete_space_log_counter++);
} else { // （2）
err = insert_delete_space_log(nullptr, id, thread_id, space_id, file_path,
dict_locked);
if (err != DB_SUCCESS) {
return err;
}
DBUG_INJECT_CRASH("ddl_log_crash_after_delete_space_log",
crash_after_delete_space_log_counter++);
DBUG_EXECUTE_IF("DDL_Log_remove_inject_error_2",
srv_inject_too_many_concurrent_trxs = true;);
err = delete_by_id(trx, id, dict_locked); //（3）
ut_ad(err == DB_SUCCESS || err == DB_TOO_MANY_CONCURRENT_TRXS);
DBUG_EXECUTE_IF("DDL_Log_remove_inject_error_2",
srv_inject_too_many_concurrent_trxs = false;);
DBUG_INJECT_CRASH("ddl_log_crash_after_delete_space_delete",
crash_after_delete_space_delete_counter++);
}
return (err);
}
在create table 這個過程中調(diào)用write_delete_space_log爵憎，is_drop 為false，執(zhí)行以上代碼執(zhí)行分支 (2) 和 (3) 婚瓜。注意的是 insert_delete_space_log 第一個參數(shù)為空宝鼓，這意味著會在創(chuàng)建一個后臺事務（調(diào)用trx_allocate_for_background）插入DELETE_SPACE 記錄到innodb_ddl_log 表中，然后提交該事務巴刻。注意到(3) 處delete_by_id 第一個參數(shù)為trx , 這里的trx 即本次 DDL 的事務愚铡，(3) 所做的動作是在本次事務中刪除(2)插入的記錄。
為什么是這樣的邏輯呢胡陪？
以下分兩種情況來討論沥寥，如上圖所示：
- 如果插入 DDL log 之后，DDL 的各個步驟都成功執(zhí)行柠座，最后事務
trx成功提交邑雅，那么innodb_ddl_log并沒有該 DDL 的記錄，因此在后續(xù)的post_ddl中什么也不做（post_ddl 在后面會描述）妈经。 - 如果插入 DDL log 之后淮野，DDL 的某個步驟失敗，則 DDL 所在的事務
trx會回滾吹泡。此時骤星，上圖中delete [DELETE SPACE, id=20]這個動作也會回滾。最后荞胡，innodb_ddl_log中就會存在DELETE SPACE這條記錄妈踊，后續(xù)執(zhí)行post_ddl進行 Replay（重演）， 從而刪除這次失敗的create table的 DDL 已經(jīng)創(chuàng)建的表空間泪漂。你可以發(fā)現(xiàn)廊营，create table的 DDL 創(chuàng)建表空間歪泳，就一定會以這樣的機制往innodb_ddl_log中插入一條相反的動作DELETE SPACE的日志記錄，所以也被稱為反向操作日志露筒。
其它 DDL log 記錄的操作如REMOVE CACHE 呐伞、FREE 日志記錄的寫入也是類似的邏輯。復雜的 DDL慎式，不光是會插入反向操作日志記錄伶氢，也會插入清理操作日志。比如TRUNCATE 表操作會將原有的表空間重命名為一個零時表空間瘪吏，當 DDL 成功之后癣防，需要通過post_ddl Replay DDL log 記錄，將臨時表空間刪除掌眠。如果失敗蕾盯，又需要 post_ddl重演 DDL log，執(zhí)行反向操作蓝丙，將臨時表空間重命名為原來的表空間级遭。總之渺尘，如果是反向操作日志挫鸽，則使用background trx 插入并提交，然后使用trx 刪除鸥跟；如果是清理日志丢郊，則使用trx 插入即可。
注意：
innodb_ddl_log表與其他 InnoDB 表一樣锌雀，對該表所有操作 InnoDB 引擎都會產(chǎn)生 Redo 日志與 Undo 記錄蚂夕，所以不要將 DDL log 表中反向操作記錄看作 Undo log，這兩者不在同一個抽象層次上腋逆。而且反向操作在另一個事務中執(zhí)行婿牍，而回滾時，Undo log 則是在原有同一個事務上執(zhí)行惩歉。
需要探討的幾個問題
DDL 是否有必要日志刷盤等脂？
我們知道 MySQL 有一個 innodb_flush_log_at_trx_commit 參數(shù)，當設置為 0 時撑蚌，提交時并不會立刻將 Redo log 刷入持久存儲中上遥。雖然能提高性能，但在掉電或者停機時會有一定概率丟失已經(jīng)提交的事務争涌。對于 DML 操作來說粉楚，這樣僅僅是丟失事務，但對于 DDL 來說，丟失 DDL 的事務模软，就會導致數(shù)據(jù)庫元數(shù)據(jù)與其他數(shù)據(jù)不一致伟骨，以至數(shù)據(jù)庫系統(tǒng)無法正常工作。
所以燃异，在trx_commit 會根據(jù)該事務是否為 DDL 操作携狭，進行特殊處理：
無論innodb_flush_log_at_trx_commit參數(shù)如何設置，與 DDL 有關的事務回俐，提交時必須日志刷盤逛腿！
DDL log 的寫入時機
在理解了 DDL log 的機制之后，筆者問大家一個問題仅颇，對于create table 來說单默，是先執(zhí)行write_delete_space_log 還是先創(chuàng)建表空間呢？
我們先假設是先創(chuàng)建表空間（A 動作）灵莲，再寫反向操作日志（B 動作）雕凹。如果 A 執(zhí)行結(jié)束后出現(xiàn)掉的情況殴俱，此時 B 還未執(zhí)行政冻，此時create table 動作并沒有完成，而innodb_ddl_log 不存在DELETE SPACE 這樣的 DDL 反向日志記錄线欲，數(shù)據(jù)庫崩潰恢復后明场，數(shù)據(jù)庫系統(tǒng)會將系統(tǒng)表數(shù)據(jù)回滾，但是 A 創(chuàng)建的表空間卻沒有刪除李丰，由于存在中間狀態(tài)苦锨，此時create table 就不是原子DDL 了。
所以趴泌，在 DDL 中每個步驟中舟舒，先寫入該步驟的反向操作日志記錄到innodb_ddl_log ，再執(zhí)行該步驟嗜憔。也就是說 DDL Log 寫入時機在執(zhí)行步驟之前秃励。如果create table 已經(jīng)寫入了 DDL log， 但是沒有創(chuàng)建表空間就出現(xiàn)掉電情況呢吉捶？ 這并不要緊夺鲜，在 post_ddl 做 Replay 的時候，會進行處理呐舔。
Replay 的調(diào)用邏輯
在 DDL 操作完成之后，無論 DDL 的事務提交還是回滾，都會調(diào)用post_ddl 函數(shù)怯疤，post_ddl 則會調(diào)用replay函數(shù)進行 Replay友雳。此外，MySQL 8.0 數(shù)據(jù)庫崩潰恢復過程中，與 MySQL 5.7 相比仅胞，也多了ha_post_recover的過程浪感，它會調(diào)用log_ddl->recover 將 innodb_ddl_log 所有的日志記錄進行 Replay。
在post_ddl調(diào)用的是replay_by_thread_id饼问，崩潰恢復中ha_post_recover 調(diào)用的是replay_all影兽，其邏輯如下描述：
- 依據(jù)傳入的
thread_id為索引（thread_id與trx是可以一一對應的)，以逆序方式將所有記錄獲取出來莱革，然后根據(jù)記錄的內(nèi)容峻堰，依次執(zhí)行 Replay 動作，最后刪除已經(jīng)重演的記錄盅视。 -
replay_all將innodb_ddl_log所有記錄逆序方式獲取出來捐名，依次執(zhí)行 Replay 動作，最后刪除已經(jīng)重演的記錄闹击。
可以看到镶蹋，以上兩個函數(shù)都有將記錄逆序的獲取的過程，為什么要逆序呢赏半？
逆函數(shù)
1贺归、反向操作
我們?nèi)绻麑?DDL 中每個步驟看做一個函數(shù)，參數(shù)為數(shù)據(jù)庫系統(tǒng)断箫。假設第 i 個步驟函數(shù)為oi拂酣，那么n個步驟就是 n 個函數(shù)的復合函數(shù)：
也即，復合函數(shù)的逆時所有步驟逆函數(shù)的反向復合仲义。所以反向操作需要將 DDL log 逆序進行處理婶熬。
2、清理操作
DDL 的清理動作往往沒有順序要求埃撵，逆向操作與正向操作效果往往是一樣的赵颅，所以統(tǒng)一進行逆序處理也沒有問題。
冪等性
與 Redo暂刘、Undo 類似饺谬，每個類型的日志重演均要考慮其冪等性。
所謂冪等性鸳惯，就是執(zhí)行多次和執(zhí)行一次的效果是一樣的商蕴。特別是在崩潰恢復的時候，在重演反向操作的時候芝发，尚未完成時發(fā)生掉電故障绪商，重新進行崩潰恢復。此時某項重演操作可能發(fā)生多次辅鲸。
因此格郁，MySQL 8.0 實現(xiàn)這些重演操作，必須要考慮冪等性。最典型是重演一些刪除操作例书，必須先判斷數(shù)據(jù)庫對象是否存在锣尉。如果存在，才進行刪除决采，否則什么都不做自沧。
Tips：說到這里，筆者推薦一本書《具體數(shù)學：計算機科學中的一塊基石》此書講解了許多計算機科學中用到的數(shù)學知識及技巧树瞭，并特別著墨于算法分析方面拇厢。
Server 層的動作
- DDL 開始更新，無論失敗與否晒喷，table share 都要進行緩存更新孝偎，tdc_remove_table；
- DDL 成功之后凉敲，執(zhí)行事務提交衣盾，否則執(zhí)行事務回滾；
- 無論事務提交還是回滾爷抓，都要調(diào)用
post_ddl势决，post_ddl作用在前面已經(jīng)描述，用以r Replay 系統(tǒng)表innodb_ddl_log記錄的日志废赞； - 崩潰恢復時候徽龟，除了執(zhí)行 Redo 日志，回滾未提交的事務之后唉地，還需要執(zhí)執(zhí)行
ha_post_recover，而 InnoDB 的ha_post_recover就是調(diào)用post_ddl執(zhí)行 DDL 的反向操作传透； - binglog 處理只有一個原則耘沼，就是 DDL 事務成功。并且提交之后朱盐，才調(diào)用
write_bin_log寫 binlog群嗤。
注意事項
MySQL 8.0 支持原子 DDL，并不意味著 DDL 可以通過 SQL 語句命令進行回滾兵琳。實際上除了 SQLServer 外狂秘，幾乎所有的數(shù)據(jù)庫系統(tǒng)不支持 DDL 的 SQL 命令進行回滾，DDL 回滾引入的問題遠遠多于其帶來的好處躯肌。
MySQL 8.0 只承諾單個 DDL 語句的原子性者春，并不能保證多個 DDL 組合也能保持原子性。某大廠為了實現(xiàn)
Truncate table flashback清女，僅僅在 MySQL 的 Server 層將truncate table動作轉(zhuǎn)換為rename table動作钱烟，flashback 的時候?qū)⒈怼⑺饕⒓s束重新以 RENAME DDL 組合執(zhí)行來實現(xiàn) flashback拴袭，這個是及其危險的读第，不保證其原子性。筆者也完成過此功能拥刻，并沒有如此取巧怜瞒，而是老老實實的從 Server 層、InnoDB 存儲引擎般哼、binlog 各方面進行改造盼砍，完整保證其原子性。MySQL 8.0 用這種方法實現(xiàn)原子 DDL逝她，并不意味著其它數(shù)據(jù)庫也是這種方式實現(xiàn)原子DDL浇坐。
