1. DDL原子性概述
8.0之前并沒有統一的數據字典dd，server層和引擎層各有一套元數據，sever層的元數據包括(.frm,.opt,.par,.trg等)，用于存儲表定義，分區表定義，觸發器定義等信息；innodb層也有自己一套元數據，包括表信息，索引信息等，這兩套元數據并沒有機制保證一致性，這就導致了在異常情況下可能存在元數據不一致問題，一種典型場景下，刪表操作，sever層的frm已經成功刪除了，但引擎層數據字典并沒有更新，導致再建重名表失敗的問題。同樣的，比如drop table t1,t2;可能出現只刪除了t1，而t2仍然存在等問題。
8.0的一個重要工作是將數據字典統一，獨立了DD(數據字典)模塊，廢棄了server層的元數據，將innodb的元數據抽象出一條DD接口供server層和innnodb層公用。在DD的基礎上，引入了DDL的原子性特性，確保DDL操作要么全做，要么全不做的能力。實現這一套邏輯的關鍵點在于將ddl涉及到的修改，包括dd數據字典修改，引擎層的修改(創建文件，初始化tablespace，創建btree等)和寫binlog作為一個“事務”，利用事務的原子性特點來保證ddl操作的原子性。
2.DDL原子性實現原理
實現原子性的關鍵在于確保dd數據字典修改，引擎層的修改和寫binlog是一個事務。MySQL已有的XA事務機制能有效保證DML事務和binlog的一致性。而ddl數據字典也是通過innodb引擎存儲，因此做到dd數據字典修改和binlog一致是容易的；那么還需要解決的一個問題是，dd數據字典和引擎層修改的一致性，引擎層的修改并不都是記redo的，比如創建文件，rename文件名，或者清理cache等，無法簡單地通過XA機制解決問題，因此8.0還引入了一套DDL_LOG機制。具體而言，就是將不記redo的一些操作，通過記日志的方式寫入到ddl_log表中，而這個表是innodb引擎表，通過保證ddl_log數據與dd數據字典修改達成一致，而最終解決dd數據字典修改，引擎層的修改和寫binlog一致性問題。
3.DD引入前后對比
?
?
?
4.DDL操作實現邏輯
引入ddl_log表后，ddl操作在原有的基礎上有一些變化，主要有兩點，一點是在執行ddl的過程中，會記錄ddl操作到ddl_log表中；另一點是新增了一個post_ddl階段，ddl事務提交后，做一些ddl的收尾動作，比如drop-table，真正的刪除物理文件是在post-ddl階段做的。post-ddl做的事情主要就是，讀取ddl-log內容，進行回放執行。ddl操作類型如下：
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
|
enum class Log_Type : uint32_t {/** Smallest log type */SMALLEST_LOG = 1,/** Drop an index tree */FREE_TREE_LOG = 1,/** Delete a file */DELETE_SPACE_LOG,/** Rename a file */RENAME_SPACE_LOG,/** Drop the entry in innodb_dynamic_metadata */DROP_LOG,/** Rename table in dict cache. */RENAME_TABLE_LOG,/** Remove a table from dict cache */REMOVE_CACHE_LOG,/** Alter Encrypt a tablespace */ALTER_ENCRYPT_TABLESPACE_LOG,/** Biggest log type */BIGGEST_LOG = ALTER_ENCRYPT_TABLESPACE_LOG}; |
通過innodb_print_ddl_logs開關，可以看到ddl過程中寫入到innodb_ddl_log表中的內容。下面會以幾個典型的ddl操作產生的ddl_log來說明如何保證ddl的原子性。
4.1 create table
語句：create table dd_tt(id int primary key, c1 int);
|
1
2
3
4
5
6
7
8
|
[InnoDB] DDL log insert : [DDL record: DELETE SPACE, id=352, thread_id=23, space_id=71, old_file_path=./mysql/dd_tt.ibd][InnoDB] DDL log delete : 352[InnoDB] DDL log insert : [DDL record: REMOVE CACHE, id=353, thread_id=23, table_id=1128, new_file_path=mysql/dd_tt][InnoDB] DDL log delete : 353[InnoDB] DDL log insert : [DDL record: FREE, id=354, thread_id=23, space_id=71, index_id=231, page_no=4][InnoDB] DDL log delete : 354[InnoDB] DDL log post ddl : begin for thread id : 23[InnoDB] DDL log post ddl : end for thread id : 23 |
說明：
1.所有insert操作都是一個單獨的事務，對應的逆向delete操作是整個ddl事務的一部分。
2.insert操作記錄的是文件操作的逆向操作，比如建table_space,逆向操作就是delete_space_log。
3.如果ddl事務最終成功，那么所有逆向delete操作也最終生效，ddl_log日志被正常清理；如果ddl事務執行過程中失敗(比如實例crash)，那么delete操作回滾，ddl_log表中殘留3條insert_log，recover時，replay這些ddl_log，即可以清理ddl過程中產生的垃圾。
4.crash-recovery時，若binlog已經落盤，則對應的ddl事務處于prepare狀態，那么最終事務要提交，ddl_log被清理干凈；若binlog沒有落盤，則ddl事務需要回滾，ddl_log表中殘留3條記錄，在故障恢復結束后，需要replay這些記錄，實際上就是建文件，創建btree等逆向操作，確?；貪L后是干凈的。
4.2 drop table
語句：drop table dd_tt;
|
1
2
3
4
5
6
|
[InnoDB] DDL log insert : [DDL record: DROP, id=355, thread_id=23, table_id=1128][InnoDB] DDL log insert : [DDL record: DELETE SPACE, id=356, thread_id=23, space_id=71, old_file_path=./mysql/dd_tt.ibd][InnoDB] DDL log post ddl : begin for thread id : 23[InnoDB] DDL log replay : [DDL record: DELETE SPACE, id=356, thread_id=23, space_id=71, old_file_path=./mysql/dd_tt.ibd][InnoDB] DDL log replay : [DDL record: DROP, id=355, thread_id=23, table_id=1128][InnoDB] DDL log post ddl : end for thread id : 23 |
說明：對于drop操作而言，執行過程中只是操作ddl_log，并不做真正的drop物理表操作。在post-ddl階段，會讀取ddl_log表中的記錄并replay，做真正的刪除動作。如果執行過程中crash了，那么整個ddl事務會回滾，這其中也包含ddl_log中的內容也會回滾，那么整個drop操作就相當于沒發生一樣。
4.3 add index
語句：alter table dd_tt add index idx_c1(c1);
|
1
2
3
4
|
[InnoDB] DDL log insert : [DDL record: FREE, id=360, thread_id=23, space_id=72, index_id=233, page_no=5] [InnoDB] DDL log delete : 360[InnoDB] DDL log post ddl : begin for thread id : 23 [InnoDB] DDL log post ddl : end for thread id : 23 |
說明： 建索引與建表類似，insert操作部分是一個事務，單獨提交，配套會記錄一個delete操作，這個操作是整個ddl事務的一部分，事務如果最終提交，那么ddl-log內容被刪除；如果事務最終回滾，那么ddl-log中會殘留一條FREE-log，通過replay則可以清理建好的索引，達到回滾的效果。
4.4 drop index
語句：alter table dd_tt drop index idx_c1;
|
1
2
3
4
|
[InnoDB] DDL log insert : [DDL record: FREE, id=361, thread_id=23, space_id=72, index_id=233, page_no=5][InnoDB] DDL log post ddl : begin for thread id : 23[InnoDB] DDL log replay : [DDL record: FREE, id=361, thread_id=23, space_id=72, index_id=233, page_no=5][InnoDB] DDL log post ddl : end for thread id : 23 |
說明：
與drop table類似，執行過程中只記錄日志，在post-ddl階段才進行真正的刪除操作。
4.5 add column
語句：alter table dd_tt add column c2 int;
|
1
2
|
[InnoDB] DDL log post ddl : begin for thread id : 23[InnoDB] DDL log post ddl : end for thread id : 23 |
說明：
8.0加列是instant-ddl，只修改元數據，與dml事務類似，不依賴ddl-log保證原子性。
4.6 drop column
語句：alter table dd_tt drop column c2;
語句分解：
1.prepare階段：
|
1
2
3
4
5
6
7
8
|
create table #sql-ib1129-2815969725;[InnoDB] DDL log insert : [DDL record: DELETE SPACE, id=362, thread_id=23, space_id=73, old_file_path=./mysql/#sql-ib1129-2815969725.ibd] [InnoDB] DDL log delete : 362[InnoDB] DDL log insert : [DDL record: REMOVE CACHE, id=363, thread_id=23, table_id=1130, new_file_path=mysql/#sql-ib1129-2815969725] [InnoDB] DDL log delete : 363[InnoDB] DDL log insert : [DDL record: FREE, id=364, thread_id=23, space_id=73, index_id=234, page_no=4] [InnoDB] DDL log delete : 364 |
2.peform階段：nothing about ddl-log
3.commit階段：
3.1 alter table dd_tt rename to #sql-ib1130-2815969726;
|
1
2
3
4
|
[InnoDB] DDL log insert : [DDL record: DROP, id=365, thread_id=23, table_id=1129] <br>[InnoDB] DDL log insert : [DDL record: RENAME SPACE, id=366, thread_id=23, space_id=72, old_file_path=./mysql/#sql-ib1130-2815969726.ibd, new_file_path=./mysql/dd_tt.ibd][InnoDB] DDL log delete : 366[InnoDB] DDL log insert : [DDL record: RENAME TABLE, id=367, thread_id=23, table_id=1129, old_file_path=mysql/#sql-ib1130-2815969726, new_file_path=mysql/dd_tt][InnoDB] DDL log delete : 367 |
逆向操作：alter table mysql/#sql-ib1130-2815969726 rename to dd_tt;
3.2 alter table #sql-ib1129-2815969725 rename to dd_tt;
|
1
2
3
4
|
[InnoDB] DDL log insert : [DDL record: RENAME SPACE, id=368, thread_id=23, space_id=73, old_file_path=./mysql/dd_tt.ibd, new_file_path=./mysql/#sql-ib1129-2815969725.ibd][InnoDB] DDL log delete : 368[InnoDB] DDL log insert : [DDL record: RENAME TABLE, id=369, thread_id=23, table_id=1130, old_file_path=mysql/dd_tt, new_file_path=mysql/#sql-ib1129-2815969725][InnoDB] DDL log delete : 369 |
逆向操作：alter table dd_tt rename to mysql/#sql-ib1129-2815969725;
|
1
2
3
4
|
[InnoDB] DDL log insert : [DDL record: RENAME SPACE, id=368, thread_id=23, space_id=73, old_file_path=./mysql/dd_tt.ibd, new_file_path=./mysql/#sql-ib1129-2815969725.ibd][InnoDB] DDL log delete : 368[InnoDB] DDL log insert : [DDL record: RENAME TABLE, id=369, thread_id=23, table_id=1130, old_file_path=mysql/dd_tt, new_file_path=mysql/#sql-ib1129-2815969725][InnoDB] DDL log delete : 369 |
僅僅記錄操作，在post-ddl階段才做清理。
post-ddl階段：
|
1
2
3
4
5
6
|
drop table #sql-ib1130-2815969726;[InnoDB] DDL log insert : [DDL record: RENAME SPACE, id=368, thread_id=23, space_id=73, old_file_path=./mysql/dd_tt.ibd, new_file_path=./mysql/#sql-ib1129-2815969725.ibd][InnoDB] DDL log delete : 368[InnoDB] DDL log insert : [DDL record: RENAME TABLE, id=369, thread_id=23, table_id=1130, old_file_path=mysql/dd_tt, new_file_path=mysql/#sql-ib1129-2815969725][InnoDB] DDL log delete : 369 |
說明：drop column是copy類型的ddl，基本邏輯是新建一張臨時表，拷貝數據，最后再進行一次rename操作。主要包括4個階段：
1.prepare階段：建臨時表的過程與建表過程的ddl-log操作類似，insert-log作為單獨事務直接提交，delete-log是整個事務的一部分。
這個階段如果出現異常，ddl-log表中殘留了逆操作記錄，crash-recovery時，可以在replay實現清理。
2.peform階段: 拷貝數據結束，實現online-ddl邏輯。
3.拷貝數據結束后，需要進行rename交換表名操作。
1)DROP,刪除臨時表
2)RENAME SPACE/TABLE 將./mysql/#sql-ib1130-2815969726.ibd 重命名為dd_tt.idb
3)REANAME SPACE/TABLE 將dd_tt.idb重名為/#sql-ib1129-2815969725.idb
4)記錄刪除舊表sql-ib1130-2815969726.ibd操作，post-ddl階段做真正的刪除。
如果這個階段出現異常，同樣的insert-log單獨一個事務，delete作為整個事務的一部分，insert-log會殘留在ddl-log表中，通過replay可以做清理，還原dd_tt的數據，并清理臨時表#sql-ib1130-2815969726.ibd。
4.post-ddl階段：
1).物理刪除舊文件./mysql/#sql-ib1130-2815969726.ibd
2).清理mysql.innodb_dynamic_metadata中相關信息。
需要注意的是，由于ddl-log表存放的內容實際上逆向操作，所以搜集ddl-log時，實際上是逆序搜集回放的。
4.7 truncate table
語句：truncate table dd_tt;
語句分解：
1.rename dd_tt to #sql-ib1130-2815969727;
|
1
2
|
[InnoDB] DDL log insert : [DDL record: RENAME SPACE, id=372, thread_id=23, space_id=73, old_file_path=./mysql/#sql-ib1130-2815969727.ibd, new_file_path=./mysql/dd_tt.ibd[InnoDB] DDL log delete : 372 |
2.drop table #sql-ib1130-2815969727;
|
1
2
|
[InnoDB] DDL log insert : [DDL record: DROP, id=373, thread_id=23, table_id=1130] [InnoDB] DDL log insert : [DDL record: DELETE SPACE, id=374, thread_id=23, space_id=73, old_file_path=./mysql/#sql-ib1130-2815969727.ibd] |
3.create table dd_tt;
|
1
2
3
4
5
6
7
8
9
10
11
|
[InnoDB] DDL log insert : [DDL record: DELETE SPACE, id=375, thread_id=23, space_id=74, old_file_path=./mysql/dd_tt.ibd] [InnoDB] DDL log delete : 375[InnoDB] DDL log insert : [DDL record: REMOVE CACHE, id=376, thread_id=23, table_id=1131, new_file_path=mysql/dd_tt] [InnoDB] DDL log delete : 376[InnoDB] DDL log insert : [DDL record: FREE, id=377, thread_id=23, space_id=74, index_id=235, page_no=4] [InnoDB] DDL log delete : 377[InnoDB] DDL log post ddl : begin for thread id : 23 [InnoDB] DDL log replay : [DDL record: DELETE SPACE, id=374, thread_id=23, space_id=73, old_file_path=./mysql/#sql-ib1130-2815969727.ibd] [InnoDB] DDL log replay : [DDL record: DROP, id=373, thread_id=23, table_id=1130] [InnoDB] DDL log post ddl : end for thread id : 23 |
說明：
1.將dd_tt重命名為sql-ib1130-2815969727
2.標記sql-ib1130-2815969727表刪除，post-ddl階段才真正刪除
3.新建表dd_tt，同樣的insert操作是作為單獨事務提交，delete操作是整個事務的一部分，如果回滾，最終殘留了insert操作，通過replay動作清理。
5.DDL操作代碼堆棧
5.1 create-table
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
|
Sql_cmd_create_table::execute-->mysql_create_table -->mysql_create_table_no_lock -->create_table_impl -->rea_create_base_table -->ha_create_table -->ha_create -->ha_innobase::create -->innobase_basic_ddl::create_impl -->create_table_info_t::create_table { ...... } -->trans_commit_implicit -->ha_commit_trans -->MYSQL_BIN_LOG::prepare -->ha_prepare_low //所有事務引擎prepare { binlog_prepare innobase_xa_prepare } -->MYSQL_BIN_LOG::commit -->MYSQL_BIN_LOG::ordered_commit -->MYSQL_BIN_LOG::process_flush_stage_queue -->MYSQL_BIN_LOG::flush_thread_caches -->binlog_cache_mngr::flush -->binlog_cache_data::flush -->MYSQL_BIN_LOG::write_gtid -->Log_event::write -->MYSQL_BIN_LOG::Binlog_ofile::write //寫binlog-gtid -->MYSQL_BIN_LOG::write_cache --> MYSQL_BIN_LOG::do_write_cache -->Binlog_cache_storage::copy_to -->stream_copy -->Binlog_event_writer::write -->MYSQL_BIN_LOG::Binlog_ofile::write //寫binlog-ddl語句 -->MYSQL_BIN_LOG::sync_binlog_file -->MYSQL_BIN_LOG::process_commit_stage_queue -->ha_commit_low { binlog_commit innobase_commit -->trx_commit_for_mysql -->trx_commit -->trx_commit_low -->trx_commit_in_memory -->trx_undo_insert_cleanup } -->innobase_post_ddl(ht->post_ddl(thd)) -->Log_DDL::post_ddl -->replay_by_thread_id-->create_table_info_t::create_table -->create_table_def -->dict_mem_table_create //構造innodb內存是字典內存對象 -->row_create_table_for_mysql -->dict_build_table_def -->dict_build_tablespace_for_table -->新建xxx.idb文件 -->Log_DDL::write_delete_space_log { -->Log_DDL::insert_delete_space_log -->trx_start_internal //內部開啟事務，單獨提交。 -->構造DDL_Record(DELETE_SPACE_LOG) -->DDL_Log_Table::insert(寫入物理B-Tree) -->Log_DDL:delete_by_id //刪除ddl_log操作，作為ddl事務的一部分。 } -->fil_ibd_create -->初始化segment，extent，page -->Log_DDL::write_remove_cache_log -->Log_DDL::insert_remove_cache_log -->Log_DDL::delete_by_id -->create_index(主表，二級索引) -->dict_create_index_tree_in_mem -->btr_create -->Log_DDL::write_free_tree_log -->Log_DDL::insert_free_tree_log -->Log_DDL:delete_by_id<br>crash-recovery -->ha_post_recover -->post_recover_handlerton -->innobase_post_recover -->Log_DDL::recover -->Log_DDL::replay_all -->Log_DDL::replay { replay_delete_space_log replay_remove_cache_log replay_free_tree_log ...... } -->delete_by_ids -->DDL_Log_Table::remove |
5.2 drop table
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
|
mysql_rm_table -->mysql_rm_table_no_locks -->drop_base_table -->ha_delete_table -—>handler::ha_delete_table -->ha_innobase::delete_table -->innobase_basic_ddl::delete_impl -->row_drop_table_for_mysql -->Log_DDL::write_drop_log // 記錄刪innodb_dynamic_metadata日志 -—>Log_DDL::write_delete_space_log // 記錄刪ibd日志 -->dd::drop_table -->dd::cache::Dictionary_client::drop<dd::Table> -->dd::cache::Storage_adapter::drop<dd::Table> -->dd::sdi::drop -->innobase_post_ddl -->Log_DDL::post_ddl -->Log_DDL::replay_by_thread_id -->Log_DDL::replay —>Log_DDL::replay_delete_space_log // post-ddl 真正刪除innodb_dynamic_metadata —>Log_DDL::replay_drop_log // post-ddl 真正刪除ibd -->delete_by_ids -->DDL_Log_Table::remove |
drop table時，只記錄刪除動作日志，這些日志作為事務的整體的一部分，如果最終事務提交，那么post_ddl階段會讀取日志真正刪除；如果事務回滾，那么ddl_log也會作為事務的一部分而回滾。
參考文檔
https://dev.mysql.com/worklog/task/?id=9045
https://dev.mysql.com/worklog/task/?id=9173
https://dev.mysql.com/worklog/task/?id=9175
https://dev.mysql.com/worklog/task/?id=9525
https://dev.mysql.com/worklog/task/?id=9536
總結
以上所述是小編給大家介紹的MySQL8.0 DDL原子性特性及實現原理,希望對大家有所幫助，如果大家有任何疑問請給我留言，小編會及時回復大家的。在此也非常感謝大家對服務器之家網站的支持！
如果你覺得本文對你有幫助，歡迎轉載，煩請注明出處，謝謝！
原文鏈接：https://www.cnblogs.com/cchust/archive/2019/07/01/11099450.html
