溫馨提示×
您好，登錄后才能下訂單哦！
點擊 登錄注冊 即表示同意《億速云用戶服務條款》
您好，登錄后才能下訂單哦！
本篇內容主要講解“MySQL8.0的Crash Safe DDL有什么用”，感興趣的朋友不妨來看看。本文介紹的方法操作簡單快捷，實用性強。下面就讓小編來帶大家學習“MySQL8.0的Crash Safe DDL有什么用”吧!
在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的過程
root@(none) 11:12:19>SET GLOBAL innodb_print_ddl_logs = 1; Query OK, 0 rows affected (0.00 sec) root@(none) 11:12:22>SET GLOBAL log_error_verbosity = 3; Query OK, 0 rows affected (0.00 sec)
mysql> CREATE DATABASE test; Query OK, 1 row affected (0.02 sec)
創建數據庫語句沒有寫log_ddl，可能覺得這不是高頻操作，如果創建database的過程中失敗了，重啟后可能需要手動刪除目錄。
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操作，直到操作結束了才會提交。
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，用于異常發生時能夠刪除臨時索引.
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刪除
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 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階段處理
如上所述，有些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來恢復操作，
到此，相信大家對“MySQL8.0的Crash Safe DDL有什么用”有了更深的了解，不妨來實際操作一番吧！這里是億速云網站，更多相關內容可以進入相關頻道進行查詢，關注我們，繼續學習！
免責聲明：本站發布的內容（圖片、視頻和文字）以原創、轉載和分享為主，文章觀點不代表本網站立場，如果涉及侵權請聯系站長郵箱：is@yisu.com進行舉報，并提供相關證據，一經查實，將立刻刪除涉嫌侵權內容。
