問題是有，但好在規(guī)避辦法也比較簡單，影響也有限。

先說解決辦法，從簡單到麻煩：

執(zhí)行 ALTER TABLE 時(shí)，顯式指定ALGORITHM=INSTANT/COPY，反正不要使用 INPLACE。

適當(dāng)調(diào)大 innodb_ddl_buffer_size 參數(shù)值，其默認(rèn)值1MB，例如調(diào)大到100MB就可以應(yīng)對大部分業(yè)務(wù)表的DDL操作場景。

利用 pt-osc 或 gh-ost 等工具進(jìn)行 Online DDL 操作。

在業(yè)務(wù)低谷時(shí)段執(zhí)行DDL操作，有條件的話甚至可以在業(yè)務(wù)維護(hù)期間再執(zhí)行DDL操作。

升級版本到已修復(fù)的 Percona 分支版本（下文會(huì)提到）。

問題來源

在 MySQL 8.0.27 版本中新增并行DDL功能后才“引入”了這個(gè)問題。目前在最新的 8.1.x/8.3.x/8.3.x/8.4.x/9.0.x/9.1.x 等版本中依然存在，預(yù)計(jì)到 MySQL 8.0.41 新版本會(huì)修復(fù)。

For online DDL operations, storage is usually the bottleneck. To address this issue, CPU utilization and index building has been improved. Indexes can now be built simultaneously instead of serially. Memory management has also been tightened to respect memory configuration limits set by the user.

詳見：https://dev.mysql.com/doc/relnotes/mysql/8.0/en/news-8-0-27.html

觸發(fā)原因：在INPLACE模式的DDL操作中重建主鍵索引時(shí)，因錯(cuò)誤處理會(huì)略過部分記錄，導(dǎo)致數(shù)據(jù)丟失。

觸發(fā)條件：只影響INPLACE模式的DDL操作，不影響COPY和INSTANT模式的DDL操作。以下是幾種常見的可能觸發(fā)問題的DDL操作場景：

場景1：ALTER TABLE ENGINE=INNODB 重整表空間操作，需要重建主鍵索引。

場景2：ALTER TABLE ADD NEW-COL ...，ALGORITHM=INPLACE，新增列操作，因指定了INPLACE模式，需要重建主鍵索引。

其他例如INSTANT模式加新字段，增刪索引則不會(huì)觸發(fā)該問題。

關(guān)于該問題的詳細(xì)解讀詳見幾篇文章：

八怪老師推文 https://www.jianshu.com/p/c66fe0349345?v=1734349439280 。

Rex老師推文 MySQL 8.4-LTS DDL會(huì)導(dǎo)致數(shù)據(jù)丟失。

丁奇老師推文 丟數(shù)據(jù)風(fēng)險(xiǎn) @ MySQL官方最新版。

Percona 推文 Who Ate My MySQL Table Rows?。

涉及到2個(gè)MySQL bug：

DDL 丟數(shù)風(fēng)險(xiǎn)：https://bugs.mysql.com/bug.php?id=115608

DDL 重復(fù)行報(bào)錯(cuò)：https://bugs.mysql.com/bug.php?id=115511

該問題核心就存在于如果涉及到需要用INPLACE算法重建主鍵索引的DDL操作，就需要在 innodb_ddl_buffer_size 用滿后直接插入到 #sql-ibXXX 數(shù)據(jù)文件中，這個(gè)時(shí)候可能正在page的中間的某個(gè)位置，插入的時(shí)候會(huì)暫時(shí)放棄page上的mutex，并且保存游標(biāo)到持久游標(biāo)，然后插入數(shù)據(jù)，插入完成后再從持久游標(biāo)恢復(fù)游標(biāo)。這樣做的目的可能是為了提高page修改的并發(fā)，但是這里保存和恢復(fù)持久游標(biāo)卻出了問題，主要是page中的數(shù)據(jù)可能出現(xiàn)修改，這種修改對應(yīng)了前面的2個(gè)BUG：

Purge線程，清理del flag。

其他線程INSERT了數(shù)據(jù)。

具體游標(biāo)的保存和恢復(fù)出現(xiàn)的問題，可以參考Rex老師的文章 MySQL 8.4-LTS DDL會(huì)導(dǎo)致數(shù)據(jù)丟失。

問題影響

目前該問題已知影響的版本列表如下：

MySQL 8.0.x 系列版本中，所有 >= 8.0.27 的 MySQL 8.0.x 版本；

所有 8.4.x 系列 LTS 版本；

Percona Server for MySQL 中從 8.0.27-18 至 8.0.37-29，以及 8.4.0-1 版本。

Percona XtraDB Cluster 中從 8.0.27-18.1 至 8.0.37-29，以及 8.4.0-1 版本。

未受影響或已修復(fù)的版本列表如下：

所有早于 MySQL 8.0 的版本，及 MySQL 5.6、5.7 等版本，以及 Percona 5.6、5.7 版本；

Percona 8.0 系列中 8.0.39-30 及更高版本；

Percona 8.4 系列中 8.4.2-2 及更高版本；

Percona XtraDB Cluster 8.0 系列中 8.0.39-30 及更高版本。

目前所有活躍的 MySQL 版本均未修復(fù)，已安排在MySQL 8.0.41版本修復(fù)該問題。GreatSQL也會(huì)在下一個(gè)新版本中修復(fù)該問題。

問題復(fù)現(xiàn)/模擬

模擬測例1

經(jīng)過測試，該問題觸發(fā)概率和 update/delete 并發(fā)負(fù)載有關(guān)，結(jié)合 MySQL bug #113812 提供的案例，我進(jìn)行了簡化和改造，測試用例如下：

#/bin/sh
#bugtest.sh，測例1
#需要先安裝mysql_random_data_load測試工具
#通過socket方式連接MySQL時(shí)用root密碼并且是空密碼
MYSQL="mysql-N-s-uroot-S/data/MySQL/mysql.sock"
HOST=127.0.0.1
PORT=3306
USER="yejr"
PWD="yejr"

echo"1.Preparework"

read-r-d''bugSQL<<-EOSQL?||?true
CREATE?DATABASE?IF?NOT?EXISTS?test;
USE?test;
DROP?TABLE?IF?EXISTS?t1;
CREATE?TABLE?IF?NOT?EXISTS?t1(
?id?int?not?null,
?c1?varchar(20)?not?null,
?c2?varchar(30)?not?null,
?c3?datetime?not?null,
?c4?varchar(30)?not?null,
?PRIMARY?KEY?(id),
?KEY?idx_c3?(c3)
)?ENGINE=InnoDB;

CREATE?USER?IF?NOT?EXISTS?'${USER}'@'%';
ALTER?USER?'${USER}'@'%'?IDENTIFIED?BY?'${PWD}';
GRANT?ALL?PRIVILEGES?ON?test.t1?TO?'${USER}'@'%';
EOSQL

${MYSQL}?-f?-e?"${bugSQL}"

echo?"2.?Starting?run?test"

${MYSQL}?-e?"truncate?table?test.t1;"

for?i?in?{1..1000}
do
?mysql_random_data_load?-u${USER}?-p${PWD}?-h${HOST}?-P${PORT}?--max-threads=2?test?t1?1000?>/dev/null2>&1
c_before_del=`${MYSQL}-e"selectcount(*)fromtest.t1;"`
c_delete=`${MYSQL}-e"selectcount(*)fromtest.t1wherec3

	

	

	執(zhí)行該測試用例腳本，當(dāng)發(fā)現(xiàn)有問題時(shí)，結(jié)果顯式如下：

	

	
$sh./bugtest.sh
1.Preparework
2.Startingruntest
run10times
run20times
run30times
...
run175times,delete:979,beforealter:3436,afteralter:3435


	

	

	這就表示執(zhí)行到第175次后觸發(fā)問題，發(fā)現(xiàn)丟了一條記錄。在這個(gè)測例中，如果加大 innodb_ddl_buffer_size 參數(shù)值到10MB，則不再觸發(fā)問題。

	模擬測例2

	對上面的測試用例再進(jìn)行調(diào)整后，改成下面這個(gè)測例，在執(zhí)行完1000次后仍未觸發(fā)問題（可見并不總是會(huì)觸發(fā)問題，只有個(gè)別情況下會(huì)踩雷）：

	

	
#!/bin/sh
#bugtest.sh，測例2
#需要先安裝mysql_random_data_load測試工具
#通過socket方式連接MySQL時(shí)用root密碼并且是空密碼
MYSQL="mysql-N-s-uroot-S/nvme/GreatSQL/mysql.sock"
HOST=127.0.0.1
PORT=3306
USER="yejr"
PWD="yejr"

echo"1.Preparework"

read-r-d''bugSQL<<-EOSQL?||?true
CREATE?DATABASE?IF?NOT?EXISTS?test;
USE?test;
DROP?TABLE?IF?EXISTS?t1;
CREATE?TABLE?IF?NOT?EXISTS?t1(
?id?int?not?null,
?c1?varchar(20)?not?null,
?c2?varchar(30)?not?null,
?c3?int?not?null,
?c4?varchar(30)?not?null,
?PRIMARY?KEY?(id),
?KEY?idx_c3?(c3)
)?ENGINE=InnoDB;

CREATE?USER?IF?NOT?EXISTS?'${USER}'@'%';
ALTER?USER?'${USER}'@'%'?IDENTIFIED?BY?'${PWD}';
GRANT?ALL?PRIVILEGES?ON?test.t1?TO?'${USER}'@'%';
EOSQL

${MYSQL}?-f?-e?"${bugSQL}"

echo?"2.?Starting?run?test"

${MYSQL}?-e?"truncate?table?test.t1;"

for?i?in?{1..300}
do
?mysql_random_data_load?-u${USER}?-p${PWD}?-h${HOST}?-P${PORT}?--max-threads=2?test?t1?1000?>/dev/null2>&1
c_before_del=`${MYSQL}-e"selectcount(*)fromtest.t1;"`
${MYSQL}-e"deletefromtest.t1LIMIT980;"
c_before_alter=`${MYSQL}-e"selectcount(*)fromtest.t1;"`
${MYSQL}-e"altertabletest.t1engine=innodb;"
c_after_alter=`${MYSQL}-e"selectcount(*)fromtest.t1;"`
if[${c_before_alter}-ne${c_after_alter}];then
echo"run${i}times,beforealter:${c_before_alter},afteralter:${c_after_alter}"
exit
fi
if[`expr${i}%10`-eq0];then
echo"run${i}times"
fi
done


	

	

	從多次反復(fù)測試的結(jié)果來看，大致的規(guī)律是當(dāng)執(zhí)行 ALTER TABLE 操作特別頻繁時(shí)，就可能會(huì)在表重建時(shí)遇到被 Purge 的記錄還沒來得及被抹掉，這就比較容易觸發(fā)問題。試著把上面的測例1做些微調(diào)，把 ALTER TABLE 這部分的處理邏輯修改成下面這樣：

	

	
...
47if[`expr${i}%20`-eq0];then
48sleep2
49${MYSQL}-e"altertabletest.t1engine=innodb;"
50fi
...


	

	

	即每完成20輪測試后再執(zhí)行 ALTER TABLE 操作，并且在此之前還要先休眠等待2秒。改用新邏輯后，就沒再觸發(fā)問題。

	模擬測例3

	提示：該測例需要改成MySQL debug版本運(yùn)行（平時(shí)使用的是release二進(jìn)制包，是無法復(fù)現(xiàn)的）。

	準(zhǔn)備測試數(shù)據(jù)

	

	
CREATETABLEt1(pkCHAR(5)PRIMARYKEY);
INSERTINTOt1VALUES('aaaaa'),('bbbbb'),('bbbcc'),('ccccc'),('ddddd'),('eeeee');


	

	

	測試方法

	

				S1
			

				S2
		

				這一步的目的是2行數(shù)據(jù)key buffer就滿
			

				
		

				SET DEBUG='+d,ddl_buf_add_two';
			

				
		

				
			

				set global innodb_purge_stop_now=ON;
		

				
			

				DELETE FROM t1 WHERE pk = 'bbbcc';
		

				進(jìn)行DDL，并且來到ddl0par-scan.cc:238 行
			

				
		

				ALTER TABLE t1 ENGINE=InnoDB, ALGORITHM=INPLACE
			

				
		

				
			

				SET GLOBAL innodb_purge_run_now=ON;
		

				DDL繼續(xù)進(jìn)程(丟數(shù)據(jù))
			

				
		

	

	測試結(jié)果

	

	寫在后面

	在線上生產(chǎn)環(huán)境中，除了必要的增刪字段、增刪索引、修改字段定義外，直接執(zhí)行 ALTER TABLE ... ENGINE=InnoDB 或 OPTIMIZE TABLE 重建整個(gè)表空間的行為還是比較少的，尤其是操作大表時(shí)，也基本上都習(xí)慣了用類似 gt-osc 之類的第三方輔助工具來完成。

	此外，調(diào)大 innodb_ddl_buffer_size 參數(shù)值也可以應(yīng)對大部分業(yè)務(wù)表的DDL操作需求，在我的測試中，調(diào)大到10MB就可以保證上述測試表有幾十萬行數(shù)據(jù)時(shí)不出問題，調(diào)大到100MB則可以保證上述測試表有千萬行數(shù)據(jù)時(shí)不出問題。如果是更大、更寬的表就需要進(jìn)一步測試驗(yàn)證了。

	總的來看，這個(gè)問題在線上生產(chǎn)環(huán)境中并不是百分百會(huì)觸發(fā)，只是存在一定較低的幾率，在文章一開始也提到了幾個(gè)可以規(guī)避的方法，所以說其影響其實(shí)也是有限的，不必過于緊張。先采用緊急辦法規(guī)避問題，后面再擇機(jī)升級版本就好。