MySQL 8.0.29 instant DDL 數據腐化問題分析

作者：黨中華 2023-06-12 08:18:19

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

前言

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

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 代碼行為看看問題是如何一步步發生的。

首先說明一下，在測例運行期間邏輯順序與物理順序的變化。如下圖所示稍微展示了 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中。

責任編輯：武曉燕來源： GreatSQL社區