詳談 MySQL 8.0 原子 DDL 原理
文章字數 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_log
, is_drop
為 false
,執行以上代碼執行分支 (2)
和 (3)
。注意的是 insert_delete_space_log
第一個參數為空,這意味着會在創建一個後台事務(調用 trx_allocate_for_background
)插入 DELETE_SPACE
記錄到 innodb_ddl_log
表中,然後提交該事務。注意到 (3)
處 delete_by_id
第一個參數為 trx
, 這裏的 trx
即本次 DDL 的事務, (3)
所做的動作是在本次事務中刪除 (2)
插入的記錄。
為什麼是這樣的邏輯呢?
以下分兩種情況來討論,如上圖所示:
-
trx innodb_ddl_log post_ddl
-
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 CACHE
、 FREE
日誌記錄的寫入也是類似的邏輯。複雜的 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->recover
將 innodb_ddl_log
所有的日誌記錄進行 Replay。
在 post_ddl
調用的是 replay_by_thread_id
,崩潰恢復中 ha_post_recover
調用的是 replay_all
,其邏輯如下描述:
-
thread_id thread_id trx
-
replay_all
將innodb_ddl_log
所有記錄逆序方式獲取出來,依次執行 Replay 動作,最後刪除已經重演的記錄。
可以看到,以上兩個函數都有將記錄逆序的獲取的過程, 為什麼要逆序呢?
逆函數
1、反向操作
我們如果將 DDL 中每個步驟看做一個函數,參數為數據庫系統。假設第 i 個步驟函數為,那麼 個步驟就是 n 個函數的複合函數:
也即,複合函數的逆時所有步驟逆函數的反向複合。所以反向操作需要將 DDL log 逆序進行處理。
2、清理操作
DDL 的清理動作往往沒有順序要求,逆向操作與正向操作效果往往是一樣的,所以統一進行逆序處理也沒有問題。
冪等性
與 Redo、Undo 類似,每個類型的日誌重演均要考慮其冪等性。
所謂冪等性,就是執行多次和執行一次的效果是一樣的。 特別是在崩潰恢復的時候,在重演反向操作的時候,尚未完成時發生掉電故障,重新進行崩潰恢復。此時某項重演操作可能發生多次。
因此,MySQL 8.0 實現這些重演操作,必須要考慮冪等性。最典型是重演一些刪除操作,必須先判斷數據庫對象是否存在。如果存在,才進行刪除,否則什麼都不做。
Tips:説到這裏,筆者推薦一本書《 具體數學:計算機科學基礎 》此書講解了許多計算機科學中用到的數學知識及技巧,並特別著墨於算法分析方面。
Server 層的動作
-
DDL 開始更新,無論失敗與否,table share 都要進行緩存更新,tdc_remove_table;
-
DDL 成功之後,執行事務提交,否則執行事務回滾;
-
post_ddl post_ddl innodb_ddl_log
-
ha_post_recover ha_post_recover post_ddl
-
binglog 處理只有一個原則,就是 DDL 事務成功。並且提交之後,才調用
write_bin_log
寫 binlog。
注意事項
-
MySQL 8.0 支持原子 DDL,並不意味着 DDL 可以通過 SQL 語句命令進行回滾。 實際上除了 SQLServer 外,幾乎所有的數據庫系統不支持 DDL 的 SQL 命令進行回滾,DDL 回滾引入的問題遠遠多於其帶來的好處。
-
MySQL 8.0 只承諾單個 DDL 語句的原子性,並不能保證多個 DDL 組合也能保持原子性。 某大廠為了實現
Truncate table flashback
,僅僅在 MySQL 的 Server 層將truncate table
動作轉換為rename table
動作,flashback 的時候將表、索引、約束重新以 RENAME DDL 組合執行來實現 flashback,這個是及其危險的,不保證其原子性。筆者也完成過此功能,並沒有如此取巧,而是老老實實的從 Server 層、InnoDB 存儲引擎、binlog 各方面進行改造,完整保證其原子性。 -
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/
- 技術分享 | orchestrator--運維--配置集羣自動切換&測試
- AIOPS的莫拉維克悖論
- 詳談 MySQL 8.0 原子 DDL 原理
- 為什麼不建議用 from xxx import *
- 最近解決的兩個拖延數年的問題
- Oracle數據庫解決方案集錦
- 新一代雲原生數據庫暢想
- MySQL8.0賬户system_user權限,你瞭解嗎?
- Data Fabric,下一個風口?
- 帶着孩子做開學準備清單
- 十多年前的入職第一天
- 技術分享 | MySQL 編寫腳本時避免煩人的警吿
- GoldenGate案例一則:抽取進程無法捕獲數據
- 技術分享 | MySQL 設置管理員密碼無法生效一例
- PG數據庫的鎖咋弄得這麼複雜呢
- 金融業分佈式數據庫選型及HTAP場景實踐
- 我們的企業為什麼寫不好文檔
- 新數據庫時代,DBA 發展之路該如何選擇
- MySQL:修改系統時鐘會導致數據庫hang住嗎?
- 從程序員的盡頭是業務説起