MySQL报错MY-012671导致故障，远程帮忙修复解决方案分享

前段时间，我们遇到一个挺让人头疼的数据库问题，那天早上，业务部门突然反馈说核心系统卡得厉害，很多操作都超时了，我赶紧登录到服务器上查看,发现MySQL数据库实例已经几乎不响应任何请求了。

我习惯性地去检查MySQL的错误日志文件，也就是那个通常叫做error.log的文件，一打开日志，满屏都是红色的错误信息，其中最显眼、重复出现最多的就是一个编号为MY-012671的错误，这个错误信息的大意是说，在InnoDB存储引擎层，尝试向重做日志文件写入数据时失败了，重做日志你可以理解成是数据库的一个“流水账”，所有对数据的修改操作都会先记录在这里，以保证数据的安全和一致性，现在这个“流水账”写不进去了，问题就非常严重了，数据库为了保护数据，很多写操作都会被迫挂起,导致系统整体卡死。

错误信息里还提到了一个更具体的错误原因，是No space left on device，这让我心里咯噔一下，难道是磁盘空间满了？我马上用df -h命令检查了一下服务器上各个磁盘分区的使用情况，结果发现，存放MySQL数据文件的那个分区，使用率果然是100%,空间被完全耗尽了。

到底是哪个文件或者哪些文件占用了这么大的空间呢？我使用du -sh *命令，在MySQL的数据目录下一层层排查，很快，罪魁祸首浮出了水面：是重做日志文件本身变得异常巨大，正常情况下，这个文件的大小应该是配置好的一个固定值，但我们看到的这个文件大小已经远远超过了预设值，达到了几十个GB,把整个磁盘分区都撑满了。

问题根源找到了：磁盘空间不足，导致InnoDB无法再向重做日志中写入新的记录，进而触发了MY-012671错误,引发数据库故障。

接下来就是紧急修复了，思路很清晰：首要任务是尽快释放磁盘空间，让数据库恢复写入能力，由于是生产环境，需要非常小心,我们采取的步骤如下：

第一步，先尝试清理一些不必要的文件，我们检查并删除了服务器上一些旧的日志备份文件、临时文件，腾出了一点点空间，但这只是杯水车薪,主要问题还是那个巨大的重做日志文件。

第二步，也是最关键的一步，需要重启MySQL实例并重建重做日志文件，这是因为，在MySQL 8.0版本中（我们使用的正是8.0），重做日志文件的大小是可以在线调整的，但前提是文件系统上有足够的空闲空间，现在我们没有这个条件，所以只能采用重启重建的方式,具体操作是：

1. 我们选择了一个业务流量最低的时段（虽然当时已经是故障状态，但还是要通知业务方做好数据暂存和长时间维护的准备）,停止了MySQL服务。
2. 为了安全起见，我们并没有直接删除旧的重做日志文件（通常是ib_logfile0和ib_logfile1）,而是将它们备份到了其他还有空间的磁盘上。
3. 修改MySQL的配置文件my.cnf，我们找到了innodb_log_file_size这个参数，将其调整为一个更合理的大小，比如从默认的几百MB调整到了几个GB（具体大小需要根据业务量和服务器资源来定，不能盲目设大）。
4. 保存配置文件后，重新启动MySQL服务，这时，InnoDB引擎在启动过程中会发现配置文件里指定的重做日志大小和之前的不一致，并且磁盘上原有的重做日志文件也不存在了，它会自动创建一组全新的、大小为我们刚设定的值的重做日志文件。
5. 启动完成后，我们密切监控数据库的状态，确认MY-012671错误不再出现,并且应用程序能够正常连接和读写数据。

经过这一系列操作，数据库终于恢复了正常，事后我们复盘，这次故障的根本原因在于前期容量规划不足，没有对数据库所在磁盘的空间使用情况进行有效监控和预警,导致空间用满而未能提前发现。

为了避免未来再次发生类似问题,我们做了以下几件事：

• 加强了服务器磁盘空间的监控告警，设置了80%、90%等多个阈值,提前预警。
• 定期审查和优化重做日志文件的大小，使其既能满足业务高峰期的性能需求,又不会过度占用磁盘空间。
• 建立了更完善的数据库日志文件定期巡检机制。

这次处理MY-012671错误的经历再次提醒我们，对于数据库这类核心组件，基础的资源监控和容量管理是运维工作的重中之重,任何疏忽都可能引发严重的线上故障。