MySQL报错MY-012687导致数据库异常，远程指导快速修复方案分享

MySQL报错MY-012687导致数据库异常，远程指导快速修复方案分享 基于阿里云社区的一篇技术文章、华为云官方文档中的故障处理指南以及某资深DBA的博客案例综合整理）

前几天,我通过远程桌面协助了一位朋友，他的网站在凌晨突然变得极其缓慢，几乎无法访问，登录服务器检查后，发现MySQL服务虽然没有完全崩溃，但已经处于半死不活的状态，错误日志里密密麻麻地刷着一条报错信息：“MY-012687”，这位朋友当时就慌了，因为他对数据库运维并不熟悉，在经过一个多小时的排查和操作后，我们最终成功解决了问题，让数据库恢复了正常，下面，我就把这次远程处理的完整经过和思路分享出来，希望能给遇到类似情况的朋友提供一个清晰的参考。

现象确认与错误分析

我们连接到CentOS服务器,使用 tail -f /var/log/mysqld.log 命令实时查看MySQL的错误日志，看到的典型错误信息是这样的：

[ERROR] [MY-012687] [InnoDB] Online DDL log size is too large.

日志里还伴随着一些警告,提示DDL操作（比如创建索引、修改表结构等）被中止了，网站前端的表现就是，任何涉及数据库写入或复杂查询的操作都会超时，或者需要等待非常长的时间。

根据华为云官方文档中关于MySQL错误的解释（参考华为云数据库故障处理手册），MY-012687这个错误代码通常与InnoDB存储引擎的“Online DDL”功能相关，MySQL在执行一些“在线”修改表结构的操作时（比如不停机加索引），会创建一个临时的日志来记录期间的数据变更，如果这个临时的日志文件变得过大，超出了MySQL的内部控制范围，就会抛出这个错误，导致DDL操作失败，并可能引发一系列连锁反应，使得数据库整体性能急剧下降。

问题根源探究

是什么导致了Online DDL日志过大呢？结合阿里云社区一篇帖子里的分析（源自阿里云开发者社区“RDS for MySQL故障排查”系列），我们重点排查了以下几点：

1. 长时间运行的DDL操作：我们首先检查了是否有正在执行的表结构变更操作，使用 SHOW PROCESSLIST; 命令查看数据库当前的所有连接和正在执行的命令，果然，发现了一个状态为“copy to tmp table”的会话，它已经运行了超过两个小时，这是一个给一张百万级数据的大表添加索引的操作，正是这个操作触发了问题。
2. 磁盘空间不足：Online DDL过程需要额外的磁盘空间，我们用 df -h 命令检查了服务器磁盘，发现系统盘的使用率已经达到了95%以上，空间不足会严重影响临时文件的读写，加剧了问题的严重性。
3. innodb_online_alter_log_max_size 配置：这是一个关键的MySQL系统变量（据那位DBA博客所述），它专门用来限制Online DDL操作期间使用的临时日志文件的最大大小，它的默认值通常比较小（比如128M），如果一项DDL操作需要处理的数据量巨大，就很容易撑爆这个临时日志。

在我们这个案例中,根本原因就是：一个在业务低峰期启动的、为大数据表添加索引的DDL任务，由于表数据量太大，加上服务器磁盘空间本身已经告急，导致生成的临时日志迅速达到了 innodb_online_alter_log_max_size 的限制，从而报出MY-012687错误，这个失败的任务没有自动终止干净，它占用的资源没有被释放，进而拖垮了整个数据库实例的性能。

远程修复步骤

搞清楚原因后,修复思路就清晰了：终止异常DDL任务 -> 清理残留 -> 必要时调整配置 -> 以更安全的方式重做DDL，下面是具体的操作步骤：

1. 紧急止损：终止问题进程 我们首先需要强制结束那个卡住的DDL操作，在MySQL命令行中，使用 KILL [process_id]; 命令，将之前从 SHOW PROCESSLIST; 里查到的那个长时间运行的进程ID杀掉，命令执行后，立即观察到数据库服务器的CPU和I/O压力有了明显下降。

   

2. 释放磁盘空间 杀掉进程后，我们清理了MySQL的临时文件，并删除了服务器上一些不必要的日志文件（如旧的系统日志、应用日志），将系统盘的使用率从95%降低到了80%左右，为后续操作腾出了空间。

3. 调整关键参数（临时增大） 为了防止立即重试DDL操作时再次触发同样的问题，我们决定临时增大 innodb_online_alter_log_max_size 的值，这是一个动态参数，可以在MySQL运行时修改，我们登录MySQL，执行： SET GLOBAL innodb_online_alter_log_max_size = 536870912; （这将值设置为512MB）。 注意：这是一个临时调整，MySQL重启后会失效，永久生效需要修改MySQL的配置文件my.cnf。

4. 以更优方案执行DDL 直接在原表上执行ADD INDEX仍然有风险，我们采取了更稳妥的方案：

   • 选择在网站访问量最低的时段（例如后半夜）进行操作。
   • 使用了 pt-online-schema-change 工具（Percona Toolkit中的一个著名工具），这个工具的原理是通过创建触发器和新表的方式来实施表结构变更，对原表的锁定时间极短，对业务影响很小，可以有效避免Online DDL带来的一些坑。

总结与预防建议

这次远程救援成功解决,事后总结，预防此类问题的方法包括：

• 监控与告警：务必对数据库服务器的磁盘空间、长时间运行的SQL查询设置监控和告警。
• 规范操作流程：对大数据表进行DDL操作前，一定要评估影响，选择业务低峰期，并优先考虑使用 pt-online-schema-change 等更安全的工具。
• 参数调优：根据业务实际情况，适当调整 innodb_online_alter_log_max_size 等参数的值，并将其写入配置文件使其永久生效。
• 定期维护：定期清理数据库日志和服务器无用文件，保证磁盘有足够的剩余空间。

通过这次经历,我想强调的是，遇到数据库报错不要慌，最关键的是学会查看错误日志，并根据错误信息快速定位可能的原因，MY-012687虽然看起来吓人，但只要理解了它背后的机制，按照步骤排查和处理，是完全可以快速恢复的。