第 57 期：MySQL 清理 undo log 居然用了 10 个小时

目前，ChatDBA 还在最后的准备阶段，会尽快跟大家见面。想预约试用的朋友，可以扫码文末的 预约试用 二维码或点击 原文链接。我们正在对 DBA 群体试用大模型的情况进行调研，这对我们打磨 ChatDBA 的使用体验非常重要。

下面让我们正式进入《一问一实验：AI 版》的第 57 期。

问题

undo log 长时间处于清理状态导致备份失败

问题现象：有客户反映有 3 套 MGR 环境全备失败，MySQL 版本为 8.0.18 ，Xtrabackup 版本为 8.0.9 。报错信息如下：

xtrabackup: Generating a list of tablespaces
Directories to scan '.;./;.'
Scanning './'
Completed space ID check of 2 files.
Allocated tablespace ID 12 for zxc/a, old maximum was 0
Undo tablespace number 1 was being truncated when mysqld quit.
Cannot recover a truncated undo tablespace in read-only mode
xtrabackup: error: xb_load_tablespaces() failed with error code 57

实验

1. 将问题丢给 ChatDBA。

我们先把这个问题丢给 ChatDBA，让他看下具体出了什么问题。

可以在爱可生开源社区 B 站或视频号查看本期完整操作视频。

上图为本次问题生成的流程分析画布，展示 ChatDBA 对此问题的排查逻辑。

2. ChatDBA 问答过程

第一轮交互

首先将问题输入给 ChatDBA，ChatDBA 首先根据此问题会生成初步的参考结果，同时还会生成对应的检索关键词以及进行相关 Bug 的检索。针对这个问题 ChatDBA 还需要收集相关的错误日志来供下一步分析，同时还给到了一些潜在的操作。

第二轮交互

然后我们给到 ChatDBA 对应的错误日志，ChatDBA 根据错误日志首先确认是由于 InnoDB 尝试访问丢失的 tablespace 导致的问题，同时给到了对应的解决方案。

3. 实验总结。

在该问题中，通过排查发现 undo log 过了 10 个小时依然没有清理完，正常情况下不会出现该情况，而是由于参数 super_read_only 触发的 bug 导致的。可以通过调大 innodb_max_undo_log_size 参数，undo log 大小达到阈值前被 purge 掉，这样空间可以重用，很难达到阈值，所以不会触发 undo log truncate，所以也就不会触发 bug 导致问题。

问题原文：《故障分析 | undo log 长时间处于清理状态导致备份失败》

第三方大模型对比：ChatGPT-4o

因为在问题中给到了版本的信息，所以 ChatGPT 就会往版本的方向上引导，同时也给出来一些解决方案但是粒度较为粗糙。