MySQL 8.0/8.4执行DDL会丢数据？是，但影响有限

老叶茶馆_2024-12-20 12:29

问题是有，但好在规避办法也比较简单，影响也有限。

先说解决办法，从简单到麻烦：

  1. 执行 ALTER TABLE 时，显式指定ALGORITHM=INSTANT/COPY，反正不要使用 INPLACE。

  2. 适当调大 innodb_ddl_buffer_size 参数值，其默认值1MB，例如调大到100MB就可以应对大部分业务表的DDL操作场景。

  3. 利用 pt-osc 或 gh-ost 等工具进行 Online DDL 操作。

  4. 在业务低谷时段执行DDL操作，有条件的话甚至可以在业务维护期间再执行DDL操作。

  5. 升级版本到已修复的 Percona 分支版本（下文会提到）。

问题来源

在 MySQL 8.0.27 版本中新增并行DDL功能后才"引入"了这个问题。目前在最新的 8.1.x/8.3.x/8.3.x/8.4.x/9.0.x/9.1.x 等版本中依然存在，预计到 MySQL 8.0.41 新版本会修复。

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

触发原因：在INPLACE模式的DDL操作中重建主键索引时，因错误处理会略过部分记录，导致数据丢失。

触发条件：只影响INPLACE模式的DDL操作，不影响COPY和INSTANT模式的DDL操作。以下是几种常见的可能触发问题的DDL操作场景：

  • 场景1：ALTER TABLE ENGINE=INNODB 重整表空间操作，需要重建主键索引。

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

其他例如INSTANT模式加新字段，增删索引则不会触发该问题。

关于该问题的详细解读详见几篇文章：

涉及到2个MySQL bug：

该问题核心就存在于如果涉及到需要用INPLACE算法重建主键索引的DDL操作，就需要在 innodb_ddl_buffer_size 用满后直接插入到 #sql-ibXXX 数据文件中，这个时候可能正在page的中间的某个位置，插入的时候会暂时放弃page上的mutex，并且保存游标到持久游标，然后插入数据，插入完成后再从持久游标恢复游标。这样做的目的可能是为了提高page修改的并发，但是这里保存和恢复持久游标却出了问题，主要是page中的数据可能出现修改，这种修改对应了前面的2个BUG：

  • Purge线程，清理del flag。

  • 其他线程INSERT了数据。

具体游标的保存和恢复出现的问题，可以参考Rex老师的文章 MySQL 8.4-LTS DDL会导致数据丢失。

问题影响

目前该问题已知影响的版本列表如下：

  • 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 版本。

未受影响或已修复的版本列表如下：

  • 所有早于 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 版本均未修复，已安排在MySQL 8.0.41版本修复该问题。GreatSQL也会在下一个新版本中修复该问题。

问题复现/模拟

模拟测例1

经过测试，该问题触发概率和 update/delete 并发负载有关，结合 MySQL bug #113812 提供的案例，我进行了简化和改造，测试用例如下：

go 复制代码 
#/bin/sh
# bugtest.sh，测例1
# 需要先安装 mysql_random_data_load 测试工具
# 通过socket方式连接MySQL时用root密码并且是空密码
MYSQL="mysql -N -s -uroot -S/data/MySQL/mysql.sock"
HOST=127.0.0.1
PORT=3306
USER="yejr"
PWD="yejr"

echo "1. Prepare work"

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/null 2>&1
 c_before_del=`${MYSQL} -e "select count(*) from test.t1;"`
 c_delete=`${MYSQL} -e "select count(*) from test.t1 where c3 < curdate() - interval 7 day;"`
 ${MYSQL} -e "delete from test.t1 where c3 < curdate() - interval 7 day;"
 c_before_alter=`${MYSQL} -e "select count(*) from test.t1;"`
 ${MYSQL} -e "alter table test.t1 engine=innodb;"
 c_after_alter=`${MYSQL} -e "select count(*) from test.t1;"`
 if [ ${c_before_alter} -ne ${c_after_alter} ] ; then
  echo "run ${i} times, delete: ${c_delete}, before alter: ${c_before_alter}, after alter: ${c_after_alter}"
  exit
 fi
 if [ `expr ${i} % 10` -eq 0 ] ; then
  echo "run ${i} times"
 fi
done

执行该测试用例脚本，当发现有问题时，结果显式如下：

go 复制代码 
$ sh ./bugtest.sh
1. Prepare work
2. Starting run test
run 10 times
run 20 times
run 30 times
...
run 175 times, delete: 979, before alter: 3436, after alter: 3435

这就表示执行到第175次后触发问题，发现丢了一条记录。在这个测例中，如果加大 innodb_ddl_buffer_size 参数值到10MB，则不再触发问题。

模拟测例2

对上面的测试用例再进行调整后，改成下面这个测例，在执行完1000次后仍未触发问题（可见并不总是会触发问题，只有个别情况下会踩雷）：

go 复制代码 
#!/bin/sh
# bugtest.sh，测例2
# 需要先安装 mysql_random_data_load 测试工具
# 通过socket方式连接MySQL时用root密码并且是空密码
MYSQL="mysql -N -s -uroot -S/nvme/GreatSQL/mysql.sock"
HOST=127.0.0.1
PORT=3306
USER="yejr"
PWD="yejr"

echo "1. Prepare work"

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/null 2>&1
 c_before_del=`${MYSQL} -e "select count(*) from test.t1;"`
 ${MYSQL} -e "delete from test.t1 LIMIT 980;"
 c_before_alter=`${MYSQL} -e "select count(*) from test.t1;"`
 ${MYSQL} -e "alter table test.t1 engine=innodb;"
 c_after_alter=`${MYSQL} -e "select count(*) from test.t1;"`
 if [ ${c_before_alter} -ne ${c_after_alter} ] ; then
  echo "run ${i} times, before alter: ${c_before_alter}, after alter: ${c_after_alter}"
  exit
 fi
 if [ `expr ${i} % 10` -eq 0 ] ; then
  echo "run ${i} times"
 fi
done

从多次反复测试的结果来看，大致的规律是当执行 ALTER TABLE 操作特别频繁时，就可能会在表重建时遇到被 Purge 的记录还没来得及被抹掉，这就比较容易触发问题。试着把上面的测例1做些微调，把 ALTER TABLE 这部分的处理逻辑修改成下面这样：

go 复制代码 
...
 47  if [ `expr ${i} % 20` -eq 0 ] ; then
 48   sleep 2
 49   ${MYSQL} -e "alter table test.t1 engine=innodb;"
 50  fi
...

即每完成20轮测试后再执行 ALTER TABLE 操作，并且在此之前还要先休眠等待2秒。改用新逻辑后，就没再触发问题。

模拟测例3

提示：该测例需要改成MySQL debug版本运行（平时使用的是release二进制包，是无法复现的）。

  • 准备测试数据
go 复制代码 
CREATE TABLE t1 (pk CHAR(5) PRIMARY KEY);
INSERT INTO t1 VALUES ('aaaaa'), ('bbbbb'), ('bbbcc'), ('ccccc'), ('ddddd'), ('eeeee');
  • 测试方法
S1 S2
这一步的目的是2行数据key buffer就满
SET DEBUG='+d,ddl_buf_add_two';
set global innodb_purge_stop_now=ON;
DELETE FROM t1 WHERE pk = 'bbbcc';
进行DDL，并且来到ddl0par-scan.cc:238 行
ALTER TABLE t1 ENGINE=InnoDB, ALGORITHM=INPLACE
SET GLOBAL innodb_purge_run_now=ON;
DDL继续进程(丢数据)

  • 测试结果

写在后面

在线上生产环境中，除了必要的增删字段、增删索引、修改字段定义外，直接执行 ALTER TABLE ... ENGINE=InnoDB 或 OPTIMIZE TABLE 重建整个表空间的行为还是比较少的，尤其是操作大表时，也基本上都习惯了用类似 pt-osc 之类的第三方辅助工具来完成。

此外，调大 innodb_ddl_buffer_size 参数值也可以应对大部分业务表的DDL操作需求，在我的测试中，调大到10MB就可以保证上述测试表有几十万行数据时不出问题，调大到100MB则可以保证上述测试表有千万行数据时不出问题。如果是更大、更宽的表就需要进一步测试验证了。

总的来看，这个问题在线上生产环境中并不是百分百会触发，只是存在一定较低的几率，在文章一开始也提到了几个可以规避的方法，所以说其影响其实也是有限的，不必过于紧张。先采用紧急办法规避问题，后面再择机升级版本就好。

延伸阅读

以上。

题图是我的手机摄影作品 - 晨跑时的西湖

相关推荐
devpotato38 分钟前
缓存与数据库更新顺序不一致问题
java·数据库·redis
天若有情67342 分钟前
Node+MySQL小型全栈笔记项目实战课程分享
数据库·笔记·mysql
wxwx_bscxy3221 小时前
基于springboot宠物领养系统的设计与实现
数据库·spring boot·后端·spring·宠物
九月要晚安2 小时前
达梦DW与AFC对比
数据库
实战派K8S&DB2 小时前
如何在内网配置 TiDB 数据库 Agent
数据库·人工智能·分布式·tidb
实战派K8S&DB2 小时前
《基于 Dify + FastAPI + PyTiDB 搭建大模型驱动的 TiDB 智能运维 Agent》
运维·数据库·分布式·云原生·tidb·fastapi
SelectDB2 小时前
Apache Doris 5.0 年度版本前瞻（一）：构建统一的多模湖仓实时分析平台
大数据·数据库·数据分析
小白学大数据2 小时前
超简单：用 Python 让 Excel 飞起来：用 openpyxl 把重复报表整理交给脚本
开发语言·数据库·python·excel
西索斯coding2 小时前
doubao-seed-2.1-turbo 调用一直 401 怎么办？pro 版同样的 Key 却正常——5 分钟排查定位指南
java·服务器·数据库·ai
袋鼠云数栈3 小时前
整库迁移与分库分表同步：批量数据搬迁的配置简化思路
jvm·数据库·oracle
热门推荐
01国内可直接用、免费额度/永久免费的大模型API清单（含 SiliconFlow、火山、阿里、智谱、百度、Kimi、DeepSeek、DMXAPI 等）02GitHub 镜像站点03ZCode 周末送额度活动开启：3 亿 Token 免费领取04历年考研数学一、数学二、数学三真题试卷及答案PDF05蜘蛛磁力 搜索引擎大全，如何使用蜘蛛磁力查找磁力链接062026 国产 AI 大模型横评：DeepSeek、通义千问、Kimi、文心一言、星火、豆包谁更能打？07微信历史版本含下载地址（ Windows PC | 安卓 | MAC ）及设置微信不更新08AI 编程 IDE 全景解析 2026：Agent 全面接管开发链路09VSCode SSH 连接远程服务器后，Codex 插件登录失败10Agnes AI 免费 API 接入指南：文本、生图、生视频，一套接口全免费