建站
咨詢
售后
建站咨詢
新聞中心
背景
MySQL 5.7 的字典信息保存在非事務(wù)表中，并且存放在不同的文件中（.FRM，.PAR，.OPT，.TRN，.TRG 等)。所有 DDL 操作都不是 Crash Safe，而且對于組合 DDL（ALTER 多個表）會出現(xiàn)有的成功有的失敗的情況，而不是總體失敗。這樣主從復(fù)制就出現(xiàn)了問題，也導(dǎo)致基于復(fù)制的高可用系統(tǒng)不再安全。
博湖ssl適用于網(wǎng)站、小程序/APP、API接口等需要進行數(shù)據(jù)傳輸應(yīng)用場景，ssl證書未來市場廣闊！成為創(chuàng)新互聯(lián)的ssl證書銷售渠道，可以享受市場價格4-6折優(yōu)惠！如果有意向歡迎電話聯(lián)系或者加微信：18980820575（備注：SSL證書合作）期待與您的合作！
MySQL 8.0 推出新特性 - 原子 DDL，解決了以上的問題。
什么是原子 DDL？
DDL 是指數(shù)據(jù)定義語言（Data Definition Language），負責(zé)數(shù)據(jù)結(jié)構(gòu)的定義與數(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 將字典信息存放到事務(wù)引擎的系統(tǒng)表（InnoDB 存儲引擎）中。這樣 DDL 操作轉(zhuǎn)變成一組對系統(tǒng)表的 DML 操作，從而失敗后可以依據(jù)事務(wù)引擎自身的事務(wù)回滾保證系統(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é)構(gòu)：
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 中，這個表需要滿足兩個場景以及兩個任務(wù)：
- 場景 1: 符合 DDL 失敗的場景，需要回滾部分完成的 DDL。
- 場景 2：DDL 進行中，發(fā)生故障（掉電、軟硬件故障等），重啟機器需要完成部分 DDL。
兩個任務(wù)：
- 任務(wù) 1：失敗后回滾，執(zhí)行反向操作。
- 任務(wù) 2：如果成功，則執(zhí)行清理工作。
也許有人會問，為什么執(zhí)行成功需要執(zhí)行清理工作呢？
之所以要執(zhí)行清理工作，因為 ibd 文件和索引一旦刪除就不能恢復(fù)。為了實現(xiàn)回滾，DDL 刪除這些對象時候，并不是真正刪除，而是先將它們備份一下，以備回滾時使用。所以只有確認 DDL 已經(jīng)執(zhí)行成功，這些備份對象不需要了，才執(zhí)行清理工作。
舉個例子
為了將這個原理將清楚，我們流程相對簡單的 CREATE TABLE 講起，管中窺豹，可見一斑。假設(shè)已經(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)建一個后臺事務(wù)（調(diào)用 trx_allocate_for_background?）插入 DELETE_SPACE? 記錄到 innodb_ddl_log? 表中，然后提交該事務(wù)。注意到 (3)? 處 delete_by_id? 第一個參數(shù)為 trx? , 這里的 trx? 即本次 DDL 的事務(wù)，(3)? 所做的動作是在本次事務(wù)中刪除 (2) 插入的記錄。
為什么是這樣的邏輯呢？
以下分兩種情況來討論，如上圖所示：
- 如果插入 DDL log 之后，DDL 的各個步驟都成功執(zhí)行，最后事務(wù)trx? 成功提交，那么innodb_ddl_log? 并沒有該 DDL 的記錄，因此在后續(xù)的post_ddl 中什么也不做（post_ddl 在后面會描述）。
- 如果插入 DDL log 之后，DDL 的某個步驟失敗，則 DDL 所在的事務(wù)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? 日志記錄的寫入也是類似的邏輯。復(fù)雜的 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，這兩者不在同一個抽象層次上。而且反向操作在另一個事務(wù)中執(zhí)行，而回滾時，Undo log 則是在原有同一個事務(wù)上執(zhí)行。
需要探討的幾個問題
DDL 是否有必要日志刷盤？
我們知道 MySQL 有一個 innodb_flush_log_at_trx_commit 參數(shù)，當設(shè)置為 0 時，提交時并不會立刻將 Redo log 刷入持久存儲中。雖然能提高性能，但在掉電或者停機時會有一定概率丟失已經(jīng)提交的事務(wù)。對于 DML 操作來說，這樣僅僅是丟失事務(wù)，但對于 DDL 來說，丟失 DDL 的事務(wù)，就會導(dǎo)致數(shù)據(jù)庫元數(shù)據(jù)與其他數(shù)據(jù)不一致，以至數(shù)據(jù)庫系統(tǒng)無法正常工作。
所以，在 trx_commit 會根據(jù)該事務(wù)是否為 DDL 操作，進行特殊處理：
無論 innodb_flush_log_at_trx_commit 參數(shù)如何設(shè)置，與 DDL 有關(guān)的事務(wù)，提交時必須日志刷盤！
DDL log 的寫入時機
在理解了 DDL log 的機制之后，筆者問大家一個問題，對于 create table? 來說，是先執(zhí)行 write_delete_space_log 還是先創(chuàng)建表空間呢？
我們先假設(shè)是先創(chuàng)建表空間（A 動作），再寫反向操作日志（B 動作）。如果 A 執(zhí)行結(jié)束后出現(xiàn)掉的情況，此時 B 還未執(zhí)行，此時 create table? 動作并沒有完成，而 innodb_ddl_log? 不存在 DELETE SPACE? 這樣的 DDL 反向日志記錄，數(shù)據(jù)庫崩潰恢復(fù)后，數(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 的事務(wù)提交還是回滾，都會調(diào)用 post_ddl? 函數(shù)，post_ddl? 則會調(diào)用 replay? 函數(shù)進行 Replay。此外，MySQL 8.0 數(shù)據(jù)庫崩潰恢復(fù)過程中，與 MySQL 5.7 相比，也多了 ha_post_recover? 的過程，它會調(diào)用 log_ddl->recover? 將 innodb_ddl_log 所有的日志記錄進行 Replay。
在 post_ddl? 調(diào)用的是 replay_by_thread_id?，崩潰恢復(fù)中 ha_post_recover? 調(diào)用的是 replay_all，其邏輯如下描述：
- 依據(jù)傳入的thread_id? 為索引（thread_id? 與trx 是可以一一對應(yīng)的)，以逆序方式將所有記錄獲取出來，然后根據(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)。假設(shè)第 i 個步驟函數(shù)為 oi，那么 n 個步驟就是 n 個函數(shù)的復(fù)合函數(shù)：
也即，復(fù)合函數(shù)的逆時所有步驟逆函數(shù)的反向復(fù)合。所以反向操作需要將 DDL log 逆序進行處理。
(2) 清理操作
DDL 的清理動作往往沒有順序要求，逆向操作與正向操作效果往往是一樣的，所以統(tǒng)一進行逆序處理也沒有問題。
冪等性
與 Redo、Undo 類似，每個類型的日志重演均要考慮其冪等性。
所謂冪等性，就是執(zhí)行多次和執(zhí)行一次的效果是一樣的。特別是在崩潰恢復(fù)的時候，在重演反向操作的時候，尚未完成時發(fā)生掉電故障，重新進行崩潰恢復(fù)。此時某項重演操作可能發(fā)生多次。
因此，MySQL 8.0 實現(xiàn)這些重演操作，必須要考慮冪等性。最典型是重演一些刪除操作，必須先判斷數(shù)據(jù)庫對象是否存在。如果存在，才進行刪除，否則什么都不做。
Tips：說到這里，筆者推薦一本書《具體數(shù)學(xué)：計算機科學(xué)中的一塊基石》此書講解了許多計算機科學(xué)中用到的數(shù)學(xué)知識及技巧，并特別著墨于算法分析方面。
Server 層的動作
- DDL 開始更新，無論失敗與否，table share 都要進行緩存更新，tdc_remove_table；
- DDL 成功之后，執(zhí)行事務(wù)提交，否則執(zhí)行事務(wù)回滾；
- 無論事務(wù)提交還是回滾，都要調(diào)用post_ddl? ，post_ddl? 作用在前面已經(jīng)描述，用以 r Replay 系統(tǒng)表innodb_ddl_log 記錄的日志；
- 崩潰恢復(fù)時候，除了執(zhí)行 Redo 日志，回滾未提交的事務(wù)之后，還需要執(zhí)執(zhí)行ha_post_recover?，而 InnoDB 的ha_post_recover? 就是調(diào)用post_ddl 執(zhí)行 DDL 的反向操作；
- binglog 處理只有一個原則，就是 DDL 事務(wù)成功。并且提交之后，才調(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ū)⒈?、索引、約束重新以 RENAME DDL 組合執(zhí)行來實現(xiàn) flashback，這個是及其危險的，不保證其原子性。筆者也完成過此功能，并沒有如此取巧，而是老老實實的從 Server 層、InnoDB 存儲引擎、binlog 各方面進行改造，完整保證其原子性。
MySQL 8.0 用這種方法實現(xiàn)原子 DDL，并不意味著其它數(shù)據(jù)庫也是這種方式實現(xiàn)原子 DDL。
本文名稱：詳談MySQL8.0原子DDL原理
文章URL：http://www.dlmjj.cn/article/dhecoej.html
