MySQL报错MY-010187打不开错误日志，远程帮忙修复故障的那些事儿

那天下午，办公室的电话突然像着了火一样响个不停，我接起来，听筒那头传来一个焦急的声音，是合作公司的一位网管，我们就叫他小张吧，小张几乎是语无伦次地说，他们一台很重要的MySQL数据库服务器好像出问题了，关键是，连错误日志都打不开了，系统提示一个“MY-010187”的错误代码，他们几个人折腾了半天，完全找不到北，眼看着线上服务可能要受影响,只好紧急求助。

我一听“MY-010187”，心里大概就有了谱，这通常不是什么数据库核心引擎崩溃的大问题，但却是能让人急得跳脚的“拦路虎”——它意味着MySQL服务想记录自己运行时发生的状况，却找不到或者无法访问那个指定的错误日志文件，就像一个想写日记的人，发现日记本丢了，或者被锁进了自己打不开的保险箱,那种有苦说不出的感觉。

我让小张别慌，先远程连上他们的服务器，第一步，自然是去查看MySQL的配置文件，根据MySQL官方文档的说明，错误日志的路径通常在my.cnf（或者在Windows上是my.ini）这个文件里，由一个叫log-error的参数指定，我让小张找到这个文件，然后看看log-error后面跟着的是什么路径。

他很快找到了，路径是/var/log/mysql/error.log，看起来是个很标准的位置，下一个怀疑对象就是权限问题了，在Linux系统里，文件和目录不光要存在，还得有正确的“所有权”和“访问权限”，MySQL服务运行的那个系统用户（通常叫mysql）必须得有权利在这个位置写文件，我让他用ls -l /var/log/mysql/命令看看。

命令结果一出来，问题就暴露了。error.log文件本身是存在的，但是它的所有者（owner）居然是root用户，而且权限是-rw-r--r--，这意味着只有root用户可以读写，其他用户（包括mysql用户）只能读，不能写，这肯定不行，MySQL服务进程是以mysql用户身份运行的，它试图去写这个被root独占的文件，就像你想在别人的笔记本上写字却被拦住了，于是就只能报出MY-010187错误,然后启动失败。

原因找到了，解决起来就简单了，我指导小张，先用sudo chown mysql:mysql /var/log/mysql/error.log命令，把文件的所有者和所属组都改成mysql，这样，mysql用户就拥有了这个文件的完全控制权，为了保险起见，我又让他把目录的权限也检查一下，确保/var/log/mysql/这个目录mysql用户也有写的权限，果然,目录权限也没问题。

小张按照指示操作完，深吸一口气，然后尝试重启MySQL服务，电话那头安静了几秒钟，只能听到他敲击键盘的声音，他带着点不敢相信的语气说：“哎？起来了！服务正常启动了！”

事情到这还没完，我提醒小张，得去看看错误日志里现在有没有记录新的内容，确认它真的能正常写入了，他用tail命令一看，最新的几条启动信息已经安安稳稳地躺在日志文件里了，至此，MY-010187这个错误才算被彻底解决。

小张长舒一口气，连连道谢，他好奇地问，为什么之前还好好的，突然就出现这个权限问题了呢？我跟他分析，这种情况很常见，可能之前某次服务器磁盘空间满了，有人手动用root权限去清理或截断了这个日志文件（比如用了echo > error.log这样的命令），这个操作会创建一个全新的error.log文件，而新文件的所有者自然就变成了执行操作的root用户，自那以后，MySQL服务就再也写不进去日志了，还有一种可能，就是服务器被意外重启，而文件系统在异常关机重启后，有时会导致一些文件权限混乱,不过这种情况相对少见。

这次远程帮忙修复故障，说起来技术含量并不高，就是基础的权限调整，但关键就在于，要快速准确地定位到问题根源，MY-010187这个错误代码就像一个明确的路标，直接把我们引向了错误日志文件本身的可访问性问题上，在MySQL的官方手册里，对这个错误代码的解释也是直接指向文件权限或路径问题，遇到报错，尤其是带有明确错误代码的情况，第一件事就是去查阅官方文档,那是最权威的指南。

这件事也给我们提了个醒：在运维工作中，任何手动干预都要格外小心，尤其是在使用高权限账户（如root）操作与核心服务相关的文件时，一个不经意的动作，可能就会埋下意想不到的隐患，定期检查重要服务和日志的权限配置，也应该成为日常巡检的一部分，这次有惊无险的经历,想必比看多少页操作手册都来得印象深刻。