# 詳談 MySQL 8.0 原子 DDL 原理

## 背景

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：

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

可以看到如下表結構：

```sql
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，先執行以下命令：

```sql
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` 的日誌，然後建立表：

```sql
mysql> create table t2 (a int);
Query OK, 0 rows affected (25 min 26.42 sec)
```

可以看到如下日誌：

```sql
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` 來揭秘這個過程。

```c++
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)` 插入的記錄。

為什麼是這樣的邏輯呢？

![file](https://oscimg.oschina.net/oscnet/up-563f0dce9edbc19bae1c94cb16926a25951.png)

以下分兩種情況來討論，如上圖所示：

1. 如果插入 DDL log 之後，DDL 的各個步驟都成功執行，最後事務 `trx` 成功提交，那麼 `innodb_ddl_log` 並沒有該 DDL 的記錄，因此在後續的 `post_ddl` 中什麼也不做（post_ddl 在後面會描述）。
2. 如果插入 DDL log 之後，DDL 的某個步驟失敗，則 DDL 所在的事務 `trx` 會回滾。此時，上圖中 `delete [DELETE SPACE, id=20]` 這個動作也會回滾。最後，`innodb_ddl_log` 中就會存在 `DELETE SPACE` 這條記錄，後續執行 `post_ddl` 進行 Replay（重演）， 從而刪除這次失敗的 `create table` 的 DDL 已經建立的表空間。你可以發現，`create table` 的 DDL 建立表空間，就一定會以這樣的機制往 `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`，其邏輯如下描述：

1. 依據傳入的 `thread_id` 為索引（`thread_id` 與 `trx` 是可以一一對應的)，以逆序方式將所有記錄獲取出來，然後根據記錄的內容，依次執行 Replay 動作，最後刪除已經重演的記錄。
2. `replay_all` 將 `innodb_ddl_log` 所有記錄逆序方式獲取出來，依次執行 Replay 動作，最後刪除已經重演的記錄。

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

## 逆函式

### 1、反向操作

我們如果將 DDL 中每個步驟看做一個函式，引數為資料庫系統。假設第 i 個步驟函式為 oi，那麼 n 個步驟就是 n 個函式的複合函式：

![file](https://oscimg.oschina.net/oscnet/up-9c560e5548e10cab836f93ed939ac93ba1a.png)

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

### 2、清理操作

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

## 冪等性

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

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

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

Tips：說到這裡，博主的mysql環境都是部署在[cnaaa](https://www.cnaaa.com/)伺服器上的，感興趣的夥伴可以自己也部署一套，自己進行練習嘗試下。

# Server 層的動作

1. DDL 開始更新，無論失敗與否，table share 都要進行快取更新，tdc_remove_table；
2. DDL 成功之後，執行事務提交，否則執行事務回滾；
3. 無論事務提交還是回滾，都要呼叫 `post_ddl` ， `post_ddl` 作用在前面已經描述，用以 r Replay 系統表 `innodb_ddl_log` 記錄的日誌；
4. 崩潰恢復時候，除了執行 Redo 日誌，回滾未提交的事務之後，還需要執執行 `ha_post_recover`，而 InnoDB 的 `ha_post_recover` 就是呼叫 `post_ddl` 執行 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。

詳談 MySQL 8.0 原子 DDL 原理

相關文章