生产环境Ubuntu 20.04上MySQL无法启动，报/var/lib/mysql权限错误

问题根因定位 #

从直接执行mysqld捕获的日志可锁定核心故障点：

• 连续抛出的Can't create test file警告、最终的Failed to set datadir to '/var/lib/mysql/' (OS errno: 13 - Permission denied)错误，本质是运行mysqld的进程身份没有数据目录的合法读写权限
• apache2服务能正常完成重启操作，说明系统层面的systemctl运行状态本身没有故障，故障范围完全限定在MySQL服务的状态上
• 执行systemctl启停MySQL时返回的“控制进程收到致命信号”报错，是因为服务异常退出后残留的进程持有数据目录文件锁，常规服务重启流程无法正常清理残留状态。

标准修复操作流程 #

• 校验并修复数据目录权限
  首先执行ls -ld /var/lib/mysql确认目录属性，生产环境下该目录的合法属主为mysql:mysql，基础权限为750。如果属性不匹配，执行如下命令递归修正：
  chown -R mysql:mysql /var/lib/mysql
chmod -R 750 /var/lib/mysql
• 清理残留进程与文件锁
  执行ps aux | grep -v grep | grep mysqld列出所有残留的mysql服务进程，通过kill -9 <进程PID>强制结束所有残留进程，释放数据目录上持有锁的文件句柄。
• 验证服务运行状态
  完成上述操作后执行systemctl start mysql，再通过systemctl status mysql确认服务正常运行，同时检查应用数据库连接是否恢复。

关于控制台重启服务器恢复的补充说明 #

直接在云厂商控制台强制重启服务器后服务自动恢复，是因为系统重启过程中会自动清理所有残留进程、释放所有文件锁，同时重新加载文件系统的权限缓存，跳过了手动排查的步骤。但这种恢复方式没有修正最初导致权限异常的根因，后续如果出现服务异常退出、进程被意外杀死的场景，大概率会复现同样的启动失败问题，建议在业务低峰期按上述流程完成权限校验，避免再次出现生产中断。

内容的提问来源于stack exchange，提问作者Erik James Robles