前言

DDL 相對于數據庫的 DML 之類的其他操作，相對來說是比較耗時、相對重型的操作; 因此對業務的影比較嚴重。MySQL 從5.6版本開始一直在持續改進其DDL性能：引入了 online DDL，inplace DDL，instant DDL 等實用性極強的功能， DDL 目前對業務的影響持續降低。

MySQL 8.0.29 引入了 instant add/drop column 功能，支持在任意位置添加 column, drop column 也不需要表數據的任何形式的移動， 只需要修改表的元數據就可以完成 add/drop column，所以 instant add/drop column 的操作是輕型操作，速度快，資源需求量少。

ALTER table drop column a, ALGORITHM=INSTANT;

8.0.29 引入了新的alter 算法 INSTANT。

但是這個新功能目前很不穩定，導致的問題比較多; 而且通常都比較嚴重: 數據損壞，或者數據庫無法啟動等。

本文是分析其中的一個問題: 對表進行 instant drop 后，進行 update ，之后數據庫停機，而后數據庫無法啟動。

為分析這個問題， 我們會從 instant add/drop column 在 Innodb 的實現原理與細節方面來闡述這個數據腐化bug的具體原因。

Instant add or drop column的主線邏輯

因為這個功能的WorkLog無法從官方獲取，所以無法得到準確的設計出發點，通過閱讀相關代碼，得出要實現這個功能，必須要處理以下關鍵點：

• 因為要支持在任意位置添加/刪除列，同時不會更改表數據文件，所以表的邏輯定義與row的實際存儲形式需要映射關系，不再是所見即所得的一一對應的關系。即為了實現這樣功能：

表中列的定義順序與表中行數據(row)的存儲順序是不同的。

同時對同一個table可以做多次instant DDL, 所以需要引入版本機制，在表的數據文件中,不同row對應的表定義可能是不同的，需要在row中記住表定義的version。

以上可以認為是該功能的設計原則與實現的主線邏輯。

表定義的列順序與row 存儲列順序闡述

在引入這個功能之前， create table 時列定義的順序與列在 InnoDB 中存儲的順序是一致的。（這里我們不用考慮 InnoDB 添加系統隱藏列）

Instant add/drop column 要實現的亮點功能是在表定義的任意位置添加或者減少 column，同時做這樣的操作的時候，能夠做到不需要重構表數據。

我們稱 column 在表定義中出現的順序為邏輯順序;

而 column 在行數據的存儲順序為物理順序。

要做到修改表定義，而不重構表數據，就必須將邏輯順序與物理順序解耦: 不能再像MySQL 8.0.29之前的版本那樣，邏輯順序與物理順序是完全一致的；而從8.0.29開始通過表的元數據保存了邏輯順序與物理順序的映射關系。這種映射關系的構建與維護構成了 instant add/drop column 的基礎.

如下圖簡單闡述了邏輯/物理順序的關系。

引入row版本的必要性

對于同一張表，Instant add/drop DDL可以執行多次；每一次執行后，邏輯/物理順序的映射關系就發生變化；同時 instant add/drop DDL 并不需要做表數據的重構操作；因此可以得出經過多次 instant add/drop DDL，InnoDB存儲的行數據與表定義存在多種邏輯/物理順序映射關系：比如說，在 ibd 文件中，前十行數據對應原始的表定義，接下來的十行可能對應著 instant add column 后的數據，再接下來的十行，可能對應著 instant drop column 后的數據。

為了管理這種形式的邏輯/物理，在 InnoDB 中，為每一行實際存儲的數據引入了版本號的概念：每個版本號對應著一個邏輯/物理映射關系。

為存儲這個版本信息，InnoDB 中，row 的信息頭記錄的格式有稍微的變化:

如上圖所示，在row的extra中存儲了其對應的版本號， 同時在 row header 中有標志位指示出了是否存在版本號信息。

根據版本號獲取相應的映射關系，就可以正確的解析行數據。

目前版本號最大支持到64， instant add/drop column 到達這個限制后報錯；其后如果還需要 instant add/drop column DDL 操作，可能需要做一次能夠觸發 table rebuild 操作才可以。

數據腐化問題

由 instant add/drop column 引入了多個數據腐化問題，其中一個問題可以從：

[PS-8292] MySQL 8.0.29 fails to perform crash recovery - Percona JIRA(https://jira.percona.com/browse/PS-8292) 查看。

這個問題簡單來說：在對表進行 instant drop 后，進行update操作，之后MySQL server 重啟，在啟動階段恢復之前的 update 操作會引發 assert 崩潰(debug版本的情況下)。

從代碼上看，這個bug可能會造成數據的靜默錯誤(數據完全錯亂而且不報任何錯誤)，而不僅僅是崩潰這一種現象。

通過對core文件的簡單分析，造成該問題的大概原因如下：

在通過redo做恢復的時候，字段的邏輯順序與物理存儲順序之間的映射關系不對(錯位)導致的。在恢復期間可能會找不到對應的字段，或者更新了錯誤的字段。

原因分析

從原始的問題看，這個是發生在 InnoDB 啟動恢復階段。這一階段離不開 redo log的參與。前面介紹 instant add/drop 設計要點的時候，那些列出的要點，可以認為是在在 DDL 期間的工作以及編碼的基本邏輯；那么在完成 instant DDL 時候， 在 DML 的時候也需要將必要的信息寫入 redo log 才能做到 recovery。

• 為支持 instant add/drop column，redo log 記錄的格式發生了變化，因為代碼bug，導致在解析 redo log 做恢復的時候，得到的字段信息錯誤，導致數據腐化。
• 問題表現出來可能是: 恢復始終無法執行，數據庫無法啟動；還可能是恢復到錯誤的數據，數據庫能夠啟動。

因為 redo log 的種類較多，信息也比較繁雜，這里我們只關注問題本身中出現的 update 相關的 redo log ，進而較多的關注 update redo log 與該問題相關的字段信息。

下圖簡要的闡述了 update redo log 相關內容:

到這里，可以看到 在MySQL 8.0.29中，update redo log 引入了 instant column 的物理邏輯順序。

下面從 InnoDB 的恢復流程跟蹤問題發生的原因，其中主要需要關注的是恢復過程中的表(索引)定義。

• 應用 redo log 是在數據庫啟動階段最開始就執行，此時數據字典無法打開，獲取不到待恢復表的定義信息
• 但是此時需要表的定義信息去解析 redo log 中的相關數據
• 此時就會根據redo log中記錄的長度信息，以及記錄長度的順序構建臨時的表定義，此時僅僅是為了恢復，并不需要精確的表定義，此時只需要知道field的長度和位置即可。
• 同時如果 redo log 中如果有instant DDL 的信息，那么也會用這些信息去修改臨時構建的表定義:這是問題發生的初始錯誤的地方。
• 恢復過程中，構建出的臨時表實際上表中列的邏輯順序，這是符合正常運行的需求的。
• 但是實際上8.0.29中字段長度的記錄順序是按字段(列)的物理存儲順序寫入的。
• 如果帶有 instant DDL 的信息，那么修改表定義時就會按物理順序去修改邏輯順序的表定義，這樣會修改到非預期的字段，導致錯誤發生!

Bug重現與解析

CREATE TABLE `tb1` (
  `col1` VARCHAR(10) NOT NULL,
  `col2` char(13),
  `col3` varchar(11),
  PRIMARY KEY (`col1`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_0900_ai_ci;
INSERT INTO tb1  VALUES ('4000','50','100');
--echo # the FIRST INSTANT ALTER
ALTER TABLE tb1 DROP COLUMN col2, LOCK=DEFAULT;
INSERT INTO tb1  VALUES( '4545', '52' );
UPDATE tb1 SET col3 = '46' WHERE col1 = '4545';
--echo # crash and restart 1
--source include/kill_and_restart_mysqld.inc
CHECK TABLE tb1;
DROP TABLE tb1;

以上MySQL MTR 測例可以重現 InnoDB 啟動恢復期間始終 core 的問題。我們從這個例子出發，結合上面解釋的 instant drop DDL 代碼行為看看問題是如何一步步發生的。

1. 首先說明一下，在測例運行期間邏輯順序與物理順序的變化。 如下圖所示稍微展示了 table 的邏輯定于與 InnoDB row 存儲的以下細節。這里注意的是 被 dropped column 仍然會以隱藏列的形式存在于表定于中：因為 drop 之前存在的 row 還是需要這樣信息解析字段。

• 結合 redo log 的恢復過程看看問題發生的第一現場。這里針對這個測例摘取相關 redo log 的部分信息：



• 2.1 按照字段長度列表（8.0.29中是物理順序寫入的列表）創建的專門用于恢復的表，類似于: create table dummy_table (d1:10, d2:13, d3:11)
  2.2 按照 instant 字段信息修改 dummy 表：按照 physical pos=1 去修改后，結果類似于：create table dummy_table (d1:10, d2:13[dropped], d3:11)
  2.3 期望的正確的表應該類似于：create table dummy_table(d1:10, d3:11, d2:13[dropped]);
  2.4 Redo log中的Field_no=1, 去恢復時期望用到的是 #2.3 的表，但是過程中創建的是#2.2中錯誤的表，這樣當Field_no=1去恢復數據時，會錯誤的發現對應的field(column)已經dropped, 導致core！

MySQL8.0.30修復方案

知道了問題發生的原因,修復起來就比較簡單了：

• MySQL 8.0.30的代碼修復方案

Redo log中字段的長度列表，按照字段的邏輯順序寫入，不再按存儲順序寫入。

在 redo log 的 instant column 信息中也包含了字段的邏輯位置。

Redo log 的記錄本身的版本設置為 1 ，與8.0.29的版本為 0 ，做出差別。

8.0.30的修復代碼本身也是不能正確解析8.0.29產生的 redo log ，只是根據版本號檢測出8.0.29 redo log，進而報錯防止數據進一步惡化。實際上8.0.29的 redo log ，在 instant DDL 后，是不可能正確解析的，因為沒有邏輯/物理的映射關系。

• 修復的邏輯比較簡單:

Redo log中字段的長度列表，按照字段的邏輯順序寫入：

保證在恢復階段構建的臨時表是按正確的邏輯定義順序構建的。

• 在redo log 的 instant column 信息中也包含字段的邏輯位置：

保證在更新臨時表的字段時，按照邏輯順序，不會出現錯誤更新的情況。

下面是MySQL 8.0.30 update redo log 相關字段信息:

從上圖可以看出，MySQL 8.0.30 redo log 中已經不存儲物理位置相關的信息了，全部是邏輯位置相關的信息；這樣就和MySQL 8.0.29 redo log 這種有問題的記錄方式是曇花一現了。

附帶的這個測例可以重現數據的靜默錯誤(恢復過程沒問題， 但是數據實際上錯了)

CREATE TABLE `tb2` ( `c1` char(4) NOT NULL, `c2` char(4), `c3` char(4), PRIMARY KEY (`c1`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_0900_ai_ci;
begin;
INSERT INTO tb2  VALUES ('1000','2000','3000');
commit;
--echo # the FIRST INSTANT ALTER
ALTER TABLE tb2 add COLUMN c4 char(4) after c1, LOCK=DEFAULT;
INSERT INTO tb2 VALUES ('1001','4001', '2001', '3001');
SELECT * FROM tb2;
UPDATE tb2 set c4='4002' WHERE c1='1001';
--echo # crash and restart 1
--source include/kill_and_restart_mysqld.inc
select * from tb2;
CHECK TABLE tb2;

需要把這個測例放到innodb test case suite中。