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

目前，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 导致问题。

问题原文：《》

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