詳談 MySQL 8.0 原子 DDL 原理

語言: CN / TW / HK

文章字數 3800+,閲讀時間 15 分鐘。

背景

MySQL 5.7 的字典信息保存在非事務表中,並且存放在不同的文件中(.FRM,.PAR,.OPT,.TRN,.TRG 等)。所有 DDL 操作都不是 Crash Safe,而且對於組合 DDL(ALTER 多個表)會出現有的成功有的失敗的情況,而不是總體失敗。這樣主從複製就出現了問題,也導致基於複製的高可用系統不再安全。

MySQL 8.0 推出新特性 - 原子 DDL,解決了以上的問題。

什麼是原子 DDL?

DDL 是指數據定義語言(Data Definition Language),負責數據結構的定義與數據對象的定義。原子 DDL 是指一個 DDL 操作是不可分割的,要麼全成功要麼全失敗。

有哪些限制?

MySQL 8.0 只有 InnoDB 存儲引擎支持原子 DDL。

支持語句:數據庫、表空間、表、索引的 CREATE、ALTER 以及 DROP 語句,以及 TRUNCATE TABLE 語句。

MySQL 8.0 系統表均以 InnoDB 存儲引擎存儲,涉及到字典對象的均支持原子 DDL。

支持的語句:存儲過程、觸發器、視圖以及用户定義函數(UDF)的 CREATE 和 DROP 、ALTER 操作,用户和角色的 CREATE、ALTER、DROP 語句,以及適用的 RENAME 語句,以及 GRANT 和 REVOKE 語句。

不支持的語句:

  • INSTALL PLUGIN、UNINSTALL PLUGIN

  • INSTALL COMPONENT、UNINSTALL COMPONENT

  • REATE SERVER、ALTER SERVER、DROP SERVER

實現原理是什麼?

首先,8.0 將字典信息存放到事務引擎的系統表(InnoDB 存儲引擎)中。這樣 DDL 操作轉變成一組對系統表的 DML 操作,從而失敗後可以依據事務引擎自身的事務回滾保證系統表的原子性。

似乎 DDL 原子性就此就可以完成,但實際上並沒有這麼簡單。首先字典信息不光是系統表,還有一組字典緩存,如:

  • Table Share 緩存

  • DD 緩存

  • InnoDB 中的 dict

此外,字典信息只是數據庫對象的元數據,DDL 操作不光要修改字典信息,還要實實在在的操作對象,以及對象本身在內存中緩存。

  • 表空間

  • Dynamic meta

  • Btree

  • ibd 文件

  • buffer pool 中表空間的 page 頁

此外,binlog 也要考慮 DDL 失敗的情況。

因此,原子 DDL 在處理 DDL 失敗的時候,不光是直接回滾系統表的數據,而且也要保證內存緩存,數據庫對象也能回滾到一致狀態。

實現細節

為了解決 DDL 失敗情況中數據庫對象的回滾,8.0 引入了系統表 DDL_LOG。該表在 mysql 庫中。不可見,也不能人為操作。如果想了解該表的結果,先編譯一個 debug 版的 MySQL:

SET SESSION debug='+d,skip_dd_table_access_check';
show create table mysql.innodb_ddl_log;

可以看到如下表結構:

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 進行中,發生故障(掉電、軟硬件故障等),重啟機器需要完成部分 DDL。

兩個任務:

  • 任務 1:失敗後回滾,執行反向操作。

  • 任務 2:如果成功,則執行清理工作。

也許有人會問,為什麼執行成功需要執行清理工作呢?

之所以要執行清理工作,因為 ibd 文件和索引一旦刪除就不能恢復。為了實現回滾,DDL 刪除這些對象時候,並不是真正刪除,而是先將它們備份一下,以備回滾時使用。所以只有確認 DDL 已經執行成功,這些備份對象不需要了,才執行清理工作。

舉個例子

為了將這個原理將清楚,我們流程相對簡單的 CREATE TABLE 講起,管中窺豹,可見一斑。假設已經有編譯好了 8.0 debug 版本,並且 innodb_file_per_table 為 on,先執行以下命令:

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 的日誌,然後創建表:

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 日誌寫入函數 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 這個過程中調用 write_delete_space_logis_dropfalse ,執行以上代碼執行分支 (2)(3) 。注意的是 insert_delete_space_log 第一個參數為空,這意味着會在創建一個後台事務(調用 trx_allocate_for_background )插入 DELETE_SPACE 記錄到 innodb_ddl_log 表中,然後提交該事務。注意到 (3)delete_by_id 第一個參數為 trx , 這裏的 trx 即本次 DDL 的事務, (3) 所做的動作是在本次事務中刪除 (2) 插入的記錄。

為什麼是這樣的邏輯呢?

以下分兩種情況來討論,如上圖所示:

  1. trx
    innodb_ddl_log
    post_ddl
    
  2. trx
    delete [DELETE SPACE, id=20]
    innodb_ddl_log
    DELETE SPACE
    post_ddl
    create table
    create table
    innodb_ddl_log
    DELETE SPACE
    

其它 DDL log 記錄的操作如 REMOVE CACHEFREE 日誌記錄的寫入也是類似的邏輯。複雜的 DDL,不光是會插入反向操作日誌記錄,也會插入清理操作日誌。比如 TRUNCATE 表操作會將原有的表空間重命名為一個零時表空間,當 DDL 成功之後,需要通過 post_ddl Replay DDL log 記錄,將臨時表空間刪除。如果失敗,又需要 post_ddl 重演 DDL log,執行反向操作,將臨時表空間重命名為原來的表空間。總之,如果是反向操作日誌,則使用 background trx 插入並提交,然後使用 trx 刪除;如果是清理日誌,則使用 trx 插入即可。

注意: innodb_ddl_log 表與其他 InnoDB 表一樣,對該表所有操作 InnoDB 引擎都會產生 Redo 日誌與 Undo 記錄,所以不要將 DDL log 表中反向操作記錄看作 Undo log,這兩者不在同一個抽象層次上。而且反向操作在另一個事務中執行,而回滾時,Undo log 則是在原有同一個事務上執行。

需要探討的幾個問題

DDL 是否有必要日誌刷盤?

我們知道 MySQL 有一個 innodb_flush_log_at_trx_commit 參數,當設置為 0 時,提交時並不會立刻將 Redo log 刷入持久存儲中。雖然能提高性能,但在掉電或者停機時會有一定概率丟失已經提交的事務。對於 DML 操作來説,這樣僅僅是丟失事務,但對於 DDL 來説,丟失 DDL 的事務,就會導致數據庫元數據與其他數據不一致,以至數據庫系統無法正常工作。

所以,在 trx_commit 會根據該事務是否為 DDL 操作,進行特殊處理:

無論 innodb_flush_log_at_trx_commit 參數如何設置,與 DDL 有關的事務,提交時必須日誌刷盤!

DDL log 的寫入時機

在理解了 DDL log 的機制之後,筆者問大家一個問題,對於 create table 來説,是先執行 write_delete_space_log 還是先創建表空間呢?

我們先假設是先創建表空間(A 動作),再寫反向操作日誌(B 動作)。如果 A 執行結束後出現掉的情況,此時 B 還未執行,此時 create table 動作並沒有完成,而 innodb_ddl_log 不存在 DELETE SPACE 這樣的 DDL 反向日誌記錄,數據庫崩潰恢復後,數據庫系統會將系統表數據回滾,但是 A 創建的表空間卻沒有刪除,由於存在中間狀態,此時 create table 就不是原子 DDL 了。

所以,在 DDL 中每個步驟中,先寫入該步驟的反向操作日誌記錄到 innodb_ddl_log ,再執行該步驟。 也就是説 DDL Log 寫入時機在執行步驟之前 。如果 create table 已經寫入了 DDL log, 但是沒有創建表空間就出現掉電情況呢?這並不要緊,在   post_ddl 做 Replay 的時候,會進行處理。

Replay 的調用邏輯

在 DDL 操作完成之後,無論 DDL 的事務提交還是回滾,都會調用 post_ddl 函數, post_ddl 則會調用 replay 函數進行 Replay。此外,MySQL 8.0 數據庫崩潰恢復過程中,與 MySQL 5.7 相比,也多了 ha_post_recover 的過程,它會調用 log_ddl->recoverinnodb_ddl_log 所有的日誌記錄進行 Replay。

post_ddl 調用的是 replay_by_thread_id ,崩潰恢復中 ha_post_recover 調用的是 replay_all ,其邏輯如下描述:

  1. thread_id
    thread_id
    trx
    
  2. replay_allinnodb_ddl_log 所有記錄逆序方式獲取出來,依次執行 Replay 動作,最後刪除已經重演的記錄。

可以看到,以上兩個函數都有將記錄逆序的獲取的過程, 為什麼要逆序呢?

逆函數

1、反向操作

我們如果將 DDL 中每個步驟看做一個函數,參數為數據庫系統。假設第 i 個步驟函數為,那麼 個步驟就是 n 個函數的複合函數:

也即,複合函數的逆時所有步驟逆函數的反向複合。所以反向操作需要將 DDL log 逆序進行處理。

2、清理操作

DDL 的清理動作往往沒有順序要求,逆向操作與正向操作效果往往是一樣的,所以統一進行逆序處理也沒有問題。

冪等性

與 Redo、Undo 類似,每個類型的日誌重演均要考慮其冪等性。

所謂冪等性,就是執行多次和執行一次的效果是一樣的。 特別是在崩潰恢復的時候,在重演反向操作的時候,尚未完成時發生掉電故障,重新進行崩潰恢復。此時某項重演操作可能發生多次。

因此,MySQL 8.0 實現這些重演操作,必須要考慮冪等性。最典型是重演一些刪除操作,必須先判斷數據庫對象是否存在。如果存在,才進行刪除,否則什麼都不做。

Tips:説到這裏,筆者推薦一本書《 具體數學:計算機科學基礎 》此書講解了許多計算機科學中用到的數學知識及技巧,並特別著墨於算法分析方面。

Server 層的動作

  1. DDL 開始更新,無論失敗與否,table share 都要進行緩存更新,tdc_remove_table;

  2. DDL 成功之後,執行事務提交,否則執行事務回滾;

  3. post_ddl
    post_ddl
    innodb_ddl_log
    
  4. ha_post_recover
    ha_post_recover
    post_ddl
    
  5. binglog 處理只有一個原則,就是 DDL 事務成功。並且提交之後,才調用 write_bin_log 寫 binlog。

注意事項

  1. MySQL 8.0 支持原子 DDL,並不意味着 DDL 可以通過 SQL 語句命令進行回滾。 實際上除了 SQLServer 外,幾乎所有的數據庫系統不支持 DDL 的 SQL 命令進行回滾,DDL 回滾引入的問題遠遠多於其帶來的好處。

  2. MySQL 8.0 只承諾單個 DDL 語句的原子性,並不能保證多個 DDL 組合也能保持原子性。 某大廠為了實現   Truncate table flashback ,僅僅在 MySQL 的 Server 層將   truncate table 動作轉換為   rename table 動作,flashback 的時候將表、索引、約束重新以 RENAME DDL 組合執行來實現 flashback,這個是及其危險的,不保證其原子性。筆者也完成過此功能,並沒有如此取巧,而是老老實實的從 Server 層、InnoDB 存儲引擎、binlog 各方面進行改造,完整保證其原子性。

  3. MySQL 8.0 用這種方法實現原子 DDL,並不意味着其它數據庫也是這種方式實現原子 DDL。

參考鏈接

  • http://dev.mysql.com/doc/refman/8.0/en/atomic-ddl.html

  • http://www.slideshare.net/StleDeraas/dd-and-atomic-ddl-pl17-dublin

  • http://dev.mysql.com/blog-archive/atomic-ddl-in-mysql-8-0/