MySQL8.0 - 新特性 - Crash Safe DDL

阿新 • • 發佈：2019-01-07

前言

在MySQL8.0之前的版本中，由於架構的原因，mysql在server層使用統一的frm檔案來儲存表元資料資訊，這個資訊能夠被不同的儲存引擎識別。而實際上innodb本身也儲存有元資料資訊。這給ddl帶來了一定的挑戰，因為這種架構無法做到ddl的原子化，我們在線上經常能夠看到資料目錄下遺留的臨時檔案，或者類似server層和innodb層列個數不一致之類的錯誤。甚至某些ddl可能還遺留元資料在innodb內，而丟失了frm，導致無法重建表…..（我們為了解決這個問題，實現了一個叫drop table force的功能，去強制做清理….）

(以下所有的討論都假定使用InnoDB儲存引擎)

到了8.0版本，我們知道所有的元資料已經統一用InnoDB來進行管理，這就給實現原子ddl帶來了可能，幾乎所有的對innodb表，儲存過程，觸發器，檢視或者UDF的操作，都能做到原子化：

- 元資料修改，binlog以及innodb的操作都放在一個事務中
- 增加了一個內部隱藏的系統表`mysql.innodb_ddl_log`，ddl操作被記錄到這個表中，注意對該表的操作產生的redo會fsync到磁碟上，而不會考慮innodb_flush_log_at_trx_commit的配置。當崩潰重啟時，會根據事務是否提交來決定通過這張表的記錄去回滾或者執行ddl操作
- 增加了一個post-ddl的階段，這也是ddl的最後一個階段，會去：1. 真正的物理刪除或重新命名檔案; 2. 刪除innodb_ddl_log中的記錄項; 3.對於一些ddl操作還會去更新其動態元資料資訊(儲存在`mysql.innodb_dynamic_metadata`，例如corrupt  flag, auto_inc值等)
- 一個正常執行的ddl結束後，其ddl log也應該被清理，如果這中間崩潰了，重啟時會去嘗試重放：1.如果已經走到最後一個ddl階段的（commit之後)，就replay ddl log，把ddl完成掉；2. 如果處於某個中間態，則回滾ddl

由於引入了atomic ddl，有些ddl操作的行為也發生了變化:

- DROP TABLE: 在之前的版本中，一個drop table語句中如果要刪多個表，比如t1,t2, t2不存在時，t1會被刪除。但在8.0中，t1和t2都不會被刪除，而是丟擲錯誤。因此要注意5.7->8.0的複製問題 (DROP VIEW， CREATE USER也有類似的問題)
- DROP DATABASE: 修改元資料和ddl_log先提交事務，而真正的物理刪除資料檔案放在最後，因此如果在刪除檔案時崩潰，重啟時會根據ddl_log繼續執行drop database

測試:

MySQL很貼心的加了一個選項innodb_print_ddl_logs

，開啟後我們可以從錯誤日誌看到對應的ddl log，下面我們通過這個來看下一些典型ddl的過程

[email protected](none) 11:12:19>SET GLOBAL innodb_print_ddl_logs = 1;                                                                                                                                    
Query OK, 0 rows affected (0.00 sec)

[email protected](none) 11:12:22>SET GLOBAL log_error_verbosity = 3;                                                                                                                                                       
Query OK, 0 rows affected (0.00 sec)

CREATE DATABASE

mysql> CREATE DATABASE test;
Query OK, 1 row affected (0.02 sec)

建立資料庫語句沒有寫log_ddl，可能覺得這不是高頻操作，如果建立database的過程中失敗了，重啟後可能需要手動刪除目錄。

CREATE TABLE

mysql> USE test;
Database changed
mysql> CREATE TABLE t1 (a INT PRIMARY KEY, b INT);
Query OK, 0 rows affected (0.06 sec)

[InnoDB] DDL log insert : [DDL record: DELETE SPACE, id=428, thread_id=7, space_id=76, old_file_path=./test/t1.ibd]
[InnoDB] DDL log delete : by id 428
[InnoDB] DDL log insert : [DDL record: REMOVE CACHE, id=429, thread_id=7, table_id=1102, new_file_path=test/t1]
[InnoDB] DDL log delete : by id 429
[InnoDB] DDL log insert : [DDL record: FREE, id=430, thread_id=7, space_id=76, index_id=190, page_no=4]
[InnoDB] DDL log delete : by id 430
[InnoDB] DDL log post ddl : begin for thread id : 7
InnoDB] DDL log post ddl : end for thread id : 7

從日誌來看有三類操作，實際上描述瞭如果操作失敗需要進行的三項逆向操作：刪除資料檔案，釋放記憶體中的資料詞典資訊，刪除索引btree。在建立表之前，這些資料被寫入到ddl_log中，在建立完表並commit後，再從ddl log中刪除這些記錄。
另外上述日誌中還有DDL log delete日誌，其實在每次寫入ddl log時是單獨事務提交的，但在提交之後，會使用當前事務執行一條delete操作，直到操作結束了才會提交。

加列(instant)

mysql> ALTER TABLE t1 ADD COLUMN c INT;
Query OK, 0 rows affected (0.08 sec)
Records: 0  Duplicates: 0  Warnings: 0


[InnoDB] DDL log post ddl : begin for thread id : 7
[InnoDB] DDL log post ddl : end for thread id : 7

注意這裡執行的是Instant ddl, 這是8.0.13新支援的特性，加列操作可以只修改元資料，因此從ddl log中無需記錄資料

刪列

mysql> ALTER  TABLE t1 DROP COLUMN c;
Query OK, 0 rows affected (2.77 sec)
Records: 0  Duplicates: 0  Warnings: 0


[InnoDB] DDL log insert : [DDL record: DELETE SPACE, id=487, thread_id=7, space_id=83, old_file_path=./test/#sql-ib1108-1917598001.ibd]
[InnoDB] DDL log delete : by id 487
[InnoDB] DDL log insert : [DDL record: REMOVE CACHE, id=488, thread_id=7, table_id=1109, new_file_path=test/#sql-ib1108-1917598001]
[InnoDB] DDL log delete : by id 488
[InnoDB] DDL log insert : [DDL record: FREE, id=489, thread_id=7, space_id=83, index_id=200, page_no=4]
[InnoDB] DDL log delete : by id 489

[InnoDB] DDL log insert : [DDL record: DROP, id=490, thread_id=7, table_id=1108]
[InnoDB] DDL log insert : [DDL record: RENAME SPACE, id=491, thread_id=7, space_id=82, old_file_path=./test/#sql-ib1109-1917598002.ibd, new_file_path=./test/t1.ibd]
[InnoDB] DDL log delete : by id 491
[InnoDB] DDL log insert : [DDL record: RENAME TABLE, id=492, thread_id=7, table_id=1108, old_file_path=test/#sql-ib1109-1917598002, new_file_path=test/t1]
[InnoDB] DDL log delete : by id 492
[InnoDB] DDL log insert : [DDL record: RENAME SPACE, id=493, thread_id=7, space_id=83, old_file_path=./test/t1.ibd, new_file_path=./test/#sql-ib1108-1917598001.ibd]
[InnoDB] DDL log delete : by id 493
[InnoDB] DDL log insert : [DDL record: RENAME TABLE, id=494, thread_id=7, table_id=1109, old_file_path=test/t1, new_file_path=test/#sql-ib1108-1917598001]
[InnoDB] DDL log delete : by id 494
[InnoDB] DDL log insert : [DDL record: DROP, id=495, thread_id=7, table_id=1108]
[InnoDB] DDL log insert : [DDL record: DELETE SPACE, id=496, thread_id=7, space_id=82, old_file_path=./test/#sql-ib1109-1917598002.ibd]

[InnoDB] DDL log post ddl : begin for thread id : 7
[InnoDB] DDL log replay : [DDL record: DELETE SPACE, id=496, thread_id=7, space_id=82, old_file_path=./test/#sql-ib1109-1917598002.ibd]
[InnoDB] DDL log replay : [DDL record: DROP, id=495, thread_id=7, table_id=1108]
[InnoDB] DDL log replay : [DDL record: DROP, id=490, thread_id=7, table_id=1108]
[InnoDB] DDL log post ddl : end for thread id : 7

這是個典型的三階段ddl的過程：分為prepare, perform 以及commit三個階段:

Prepare: 這個階段會修改元資料，建立臨時ibd檔案#sql-ib1108-1917598001.ibd, 如果發生異常崩潰，我們需要能把這個臨時檔案刪除掉，因此和create table類似，也為這個idb寫了三條日誌：delete space, remove cache,以及free btree
Perform: 執行操作，將資料拷貝到上述ibd檔案中，（同時處理online dmllog）, 這部分不涉及log ddl操作
Commit: 更新資料詞典資訊並提交事務, 這裡會寫幾條日誌：
- DROP : table_id=1108
- RENAME SPACE: #sql-ib1109-1917598002.ibd檔案被rename成t1.ibd
- RENAME TABLE: #sql-ib1109-1917598002被rename成t1
- RENAME SPACE: t1.ibd 被rename成#sql-ib1108-1917598001.ibd
- RENAME TABLE: t1表被rename成#sql-ib1108-1917598001
- DROP TABLE: table_id=1108
- DELETE SPACE: 刪除#sql-ib1109-1917598002.ibd

實際上這一步寫的ddl log描述了commit階段操作的逆向過程：將t1.ibd rename成#sql-ib1109-1917598002, 並將sql-ib1108-1917598001 rename成t1表，最後刪除舊錶。其中刪除舊錶的操作這裡不執行，而是到post-ddl階段執行

Post-ddl: 在事務提交後，執行最後的操作：replay ddl log, 刪除舊檔案，清理mysql.innodb_dynamic_metadata中相關資訊
- DELETE SPACE: #sql-ib1109-1917598002.ibd
- DROP: table_id=1108
- DROP: table_id=1108

加索引

mysql> ALTER TABLE t1 ADD KEY(b);
Query OK, 0 rows affected (0.14 sec)
Records: 0  Duplicates: 0  Warnings: 0


[InnoDB] DDL log insert : [DDL record: FREE, id=431, thread_id=7, space_id=76, index_id=191, page_no=5]
[InnoDB] DDL log delete : by id 431

[InnoDB] DDL log post ddl : begin for thread id : 7
[InnoDB] DDL log post ddl : end for thread id : 7

建立索引採用inplace建立的方式，沒有臨時檔案，但如果異常發生的話，依然需要在發生異常時清理臨時索引, 因此增加了一條FREE log，用於異常發生時能夠刪除臨時索引.

TRUNCATE TABLE

mysql> TRUNCATE TABLE t1;
Query OK, 0 rows affected (0.13 sec)


[InnoDB] DDL log insert : [DDL record: RENAME SPACE, id=439, thread_id=7, space_id=77, old_file_path=./test/#sql-ib1103-1917597994.ibd, new_file_path=./test/t1.ibd]
[InnoDB] DDL log delete : by id 439
[InnoDB] DDL log insert : [DDL record: DROP, id=440, thread_id=7, table_id=1103]
[InnoDB] DDL log insert : [DDL record: DELETE SPACE, id=441, thread_id=7, space_id=77, old_file_path=./test/#sql-ib1103-1917597994.ibd]
[InnoDB] DDL log insert : [DDL record: DELETE SPACE, id=442, thread_id=7, space_id=78, old_file_path=./test/t1.ibd]
[InnoDB] DDL log delete : by id 442
[InnoDB] DDL log insert : [DDL record: REMOVE CACHE, id=443, thread_id=7, table_id=1104, new_file_path=test/t1]
[InnoDB] DDL log delete : by id 443
[InnoDB] DDL log insert : [DDL record: FREE, id=444, thread_id=7, space_id=78, index_id=194, page_no=4]
[InnoDB] DDL log delete : by id 444
[InnoDB] DDL log insert : [DDL record: FREE, id=445, thread_id=7, space_id=78, index_id=195, page_no=5]
[InnoDB] DDL log delete : by id 445

[InnoDB] DDL log post ddl : begin for thread id : 7
[InnoDB] DDL log replay : [DDL record: DELETE SPACE, id=441, thread_id=7, space_id=77, old_file_path=./test/#sql-ib1103-1917597994.ibd]
[InnoDB] DDL log replay : [DDL record: DROP, id=440, thread_id=7, table_id=1103]
[InnoDB] DDL log post ddl : end for thread id : 7

Truncate table是個比較有意思的話題，在早期5.6及之前的版本中, 是通過刪除舊錶建立新表的方式來進行的，5.7之後為了保證原子性，改成了原地truncate檔案，同時增加了一個truncate log檔案，如果在truncate過程中崩潰，可以通過這個檔案在崩潰恢復時重新truncate。到了8.0版本，又恢復成了刪除舊錶，建立新表的方式，與之前不同的是，8.0版本在崩潰時可以回滾到舊資料，而不是再次執行。以上述為例，主要包括幾個步驟：

將表t1.ibd rename成#sql-ib1103-1917597994.ibd
建立新檔案t1.ibd
post-ddl: 將老檔案#sql-ib1103-1917597994.ibd刪除

RENAME TABLE

mysql> RENAME TABLE t1 TO t2;
Query OK, 0 rows affected (0.06 sec)

DDL LOG:

[InnoDB] DDL log insert : [DDL record: RENAME SPACE, id=450, thread_id=7, space_id=78, old_file_path=./test/t2.ibd, new_file_path=./test/t1.ibd]
[InnoDB] DDL log delete : by id 450
[InnoDB] DDL log insert : [DDL record: RENAME TABLE, id=451, thread_id=7, table_id=1104, old_file_path=test/t2, new_file_path=test/t1]
[InnoDB] DDL log delete : by id 451

[InnoDB] DDL log post ddl : begin for thread id : 7
[InnoDB] DDL log post ddl : end for thread id : 7

這個就比較簡單了，只需要記錄rename space 和rename table的逆操作即可. post-ddl不需要做實際的操作

DROP TABLE

DROP TABLE t2

[InnoDB] DDL log insert : [DDL record: DROP, id=595, thread_id=7, table_id=1119]
[InnoDB] DDL log insert : [DDL record: DELETE SPACE, id=596, thread_id=7, space_id=93, old_file_path=./test/t2.ibd]

[InnoDB] DDL log post ddl : begin for thread id : 7
[InnoDB] DDL log replay : [DDL record: DELETE SPACE, id=596, thread_id=7, space_id=93, old_file_path=./test/t2.ibd]
[InnoDB] DDL log replay : [DDL record: DROP, id=595, thread_id=7, table_id=1119]
[InnoDB] DDL log post ddl : end for thread id : 7

先在ddl log中記錄下需要刪除的資料，再提交後，再最後post-ddl階段執行真正的刪除表物件和檔案操作

程式碼實現:

主要實現程式碼集中在檔案storage/innobase/log/log0ddl.cc中，包含了向log_ddl表中插入記錄以及replay的邏輯。

隱藏的innodb_log_ddl表結構如下

  def->add_field(0, "id", "id BIGINT UNSIGNED NOT NULL AUTO_INCREMENT");
  def->add_field(1, "thread_id", "thread_id BIGINT UNSIGNED NOT NULL");
  def->add_field(2, "type", "type INT UNSIGNED NOT NULL");
  def->add_field(3, "space_id", "space_id INT UNSIGNED");
  def->add_field(4, "page_no", "page_no INT UNSIGNED");
  def->add_field(5, "index_id", "index_id BIGINT UNSIGNED");
  def->add_field(6, "table_id", "table_id BIGINT UNSIGNED");
  def->add_field(7, "old_file_path",
                 "old_file_path VARCHAR(512) COLLATE UTF8_BIN");
  def->add_field(8, "new_file_path",
                 "new_file_path VARCHAR(512) COLLATE UTF8_BIN");
  def->add_index(0, "index_pk", "PRIMARY KEY(id)");
  def->add_index(1, "index_k_thread_id", "KEY(thread_id)");

記錄型別

根據不同的操作型別，可以分為如下幾類：

FREE_TREE_LOG
目的是釋放索引btree，入口函式log_DDL::write_free_tree_log，在建立索引和刪除表時會呼叫到

對於drop table中涉及的刪索引操作，log ddl的插入操作放到父事務中，一起要麼提交要麼回滾
對於建立索引的case, log ddl就需要單獨提交，父事務將記錄標記刪除，這樣後面如果ddl回滾了，也能將殘留的index刪掉。

DELETE_SPACE_LOG

入口函式：Log_DDL::write_delete_space_log

用於記錄刪除tablespace操作，同樣分為兩種情況：

drop table/tablespace, 寫入的記錄隨父事務一起提交，並在post-ddl階段replay
建立tablespace, 寫入的記錄單獨提交，並被父事務標記刪除，如果父事務回滾，就通過replay刪除參與的tablespace
RENAME_SPACE_LOG

入口函式：Log_DDL::write_rename_space_log

用於記錄rename操作，例如如果我們把表t1 rename成t2,在其中就記錄了逆向操作t2 rename to t1.
在函式Fil_shard::space_rename()中，總是先寫ddl log, 再做真正的rename操作. 寫日誌的過程同樣是獨立事務提交，父事務做未提交的刪除操作

DROP_LOG

入口函式： Log_DDL::write_drop_log

用於記錄刪除表物件操作，這裡不涉及檔案層操作，寫ddl log在父事務中執行

RENAME_TABLE_LOG

入口函式： Log_DDL::write_rename_table_log

用於記錄rename table物件的逆操作，和rename space類似，也是獨立事務提交ddl log, 父事務標記刪除

REMOVE_CACHE_LOG

入口函式： Log_DDL::write_remove_cache_log

用於處理記憶體表物件的清理，獨立事務提交，父事務標記刪除

ALTER_ENCRYPT_TABLESPACE_LOG

入口函式： Log_DDL::write_alter_encrypt_space_log

用於記錄對tablespace加密屬性的修改，獨立事務提交. 在寫完ddl log後修改tablespace page0 中的加密標記

綜上，在ddl的過程中可能會提交多次事務，大概分為三類：

獨立事務寫ddl log並提交，父事務標記刪除, 如果父事務提交了，ddl log也被順便刪除了，如果父事務回滾了，那就要根據ddl log做逆操作來回滾ddl
獨立事務寫ddl log 並提交, (目前只有ALTER_ENCRYPT_TABLESPACE_LOG)
使用父事務寫ddl log，在ddl結束時提交。需要在post-ddl階段處理

post_ddl

如上所述，有些ddl log是隨著父事務一起提交的，有些則在post-ddl階段再執行, post_ddl發生在父事提交或回滾之後: 若事務回滾，根據ddl log做逆操作，若事務提交，在post-ddl階段做最後真正不可逆操作（例如刪除檔案）

入口函式： Log_DDL::post_ddl -->Log_DDL::replay_by_thread_id

根據執行ddl的執行緒thread id通過innodb_log_ddl表上的二級索引，找到log id,再到聚集索引上找到其對應的記錄項，然後再replay這些操作，完成ddl後，清理對應記錄

崩潰恢復

在崩潰恢復結束後，會呼叫ha_post_recover介面函式，進而呼叫innodb內的函式Log_DDL::recover(), 同樣的replay其中的記錄，並在結束後刪除記錄。但ALTER_ENCRYPT_TABLESPACE_LOG型別並不是在這一步刪除，而是加入到一個數組ts_encrypt_ddl_records中,在之後呼叫resume_alter_encrypt_tablespace來恢復操作，

參考文件

1. 官方文件
 2. wl#9536: support crash safe ddl

MySQL8.0 - 新特性 - Crash Safe DDL

前言

測試:

CREATE DATABASE

CREATE TABLE

加列(instant)

刪列

加索引

TRUNCATE TABLE

RENAME TABLE

DROP TABLE

程式碼實現:

記錄型別

post_ddl

崩潰恢復

參考文件

MySQL8.0 - 新特性 - Crash Safe DDL

深入解讀MySQL8.0 新特性：Crash Safe DDL

MySQL8.0新特性——支持原子DDL語句

MySQL8.0新特性

MySQL8.0 新特性：Partial Update of LOB Column

MySQL8.0新特性——不可見索引（Invisible Indexes）

MySQL8.0新特性——資源管理

MySQL8.0新特性——默認使用caching_sha2_password作為身份驗證插件

MySQL8.0新特性之統計直方圖

MySQL8.0新特性: Instant Add Column

MySQL8.0新特性之預設使用caching_sha2_password作為身份驗證外掛

MySQL分支版本選擇+MySQL8.0新特性

MySQL8.0新特性--group by

MySQL 8.0新特性之原子DDL

MySQL8.0 - 新特性 - Descending Index

MySQL 8.0 新特性之原子 DDL

MySQL8.0新特性和安裝

MySQL8.0-新特性-線上修改系統變數，並將修改後的持久化到磁碟

MySQL8.0新特性：增加系統檔案追蹤space ID和物理檔案的對映

MySQL8.0 新特性 Hash Join

MySQL8.0 - 新特性 - Crash Safe DDL

前言

測試:

CREATE DATABASE

CREATE TABLE

加列(instant)

刪列

加索引

TRUNCATE TABLE

RENAME TABLE

DROP TABLE

程式碼實現:

記錄型別

post_ddl

崩潰恢復

參考文件

相關推薦