MySQL在数据量增长或磁盘空间不足时，常常需要把数据目录从默认路径迁移到更大的分区。但不少人在拷贝完目录、修改配置后重启服务，却发现MySQL起不来。这种现象背后涉及权限、安全策略、配置一致性等多个环节，任何一处遗漏都会让启动直接失败。
一、为什么移动数据目录会导致启动失败
MySQL进程在启动时会以特定系统用户（通常是mysql）的身份去读取数据目录下的文件。如果只用cp或mv把目录搬走，原文件的属主和属组可能发生变化，或者新位置的父目录权限不允许mysql用户进入，就会触发Permission denied错误。此外，像Ubuntu的AppArmor、RHEL系的SELinux这类强制访问控制机制，会限制mysqld只能访问策略中声明的目录，迁移后新路径不在白名单内，同样会拦截启动。
另一个容易被忽略的点是配置文件不同步。很多人改了datadir，却忘了socket、log-error、pid-file等参数如果写的是相对或旧绝对路径，也会让进程找不到关键文件。还有的是用了软链接但权限不对，或者残留了旧目录里的socket文件，导致新实例绑定失败。这些问题单独出现或叠加，都会表现为启动退出、状态异常。
二、标准迁移与排错步骤
1. 确认配置文件中的路径
先打开MySQL配置文件，通常是/etc/mysql/my.cnf或/etc/my.cnf，检查并统一修改以下项：
[mysqld] datadir=/new_disk/mysql_data socket=/new_disk/mysql_data/mysql.sock log-error=/new_disk/mysql_data/error.log pid-file=/new_disk/mysql_data/mysqld.pid
修改后保存，注意不要保留旧路径的注释行造成混淆。若原来数据目录在/var/lib/mysql，现在整体移到了/new_disk/mysql_data，那么上述四个参数都要指向新位置。
在改配置前，建议用mysqld --verbose --help | grep datadir确认编译期默认值和配置文件优先级，避免多个配置文件互相覆盖。只有确保本次修改的文件确实被读取，后续排错才有意义。
2. 修复目录权限与属主
迁移后的目录必须属于mysql用户和mysql组，且权限不能过松。执行以下命令：
sudo chown -R mysql:mysql /new_disk/mysql_data sudo chmod 750 /new_disk/mysql_data sudo systemctl stop mysql sudo rm -f /new_disk/mysql_data/mysql.sock sudo systemctl start mysql
这里删除旧的socket文件很重要，因为有些版本不会自动覆盖，若指向旧路径会引发拒绝连接。chmod 750保证同组可读执行、其他用户无权限，符合MySQL安全基线。
如果启动仍失败，应立刻查看错误日志。在配置里指定的log-error路径，或系统日志journalctl -u mysql中，通常会写明是哪一步权限不足。根据报错行号逐级向上检查父目录：例如/new_disk本身是否允许mysql用户穿透，可用namei -l /new_disk/mysql_data逐层列出权限。
3. 处理安全模块限制
在Ubuntu上，AppArmor可能绑定了旧目录。可临时关闭测试：
sudo systemctl stop apparmor sudo systemctl disable apparmor sudo systemctl restart mysql
若关闭后启动成功，说明需修改/etc/apparmor.d/usr.sbin.mysqld，把/new_disk/mysql_data/及子项加入白名单，再重新启用。对于SELinux，则用semanage fcontext -a -e /var/lib/mysql /new_disk/mysql_data然后restorecon -Rv /new_disk/mysql_data来继承原上下文。
不建议长期关闭安全模块，正确做法是补全策略。可以用ausearch -m avc -ts recent抓取拒绝记录，根据提示生成允许规则，这样既保证迁移可用，也不削弱系统防护。
三、用表对比常见错误与现象
| 现象 | 根本原因 | 快速验证 |
|---|---|---|
| Job failed for mysql.service | datadir未改或指错 | 检查my.cnf中datadir行 |
| Can't find file './ibdata1' | 属主变root | ls -l /new_disk/mysql_data |
| AppArmor denial in syslog | 新路径不在策略 | dmesg | grep apparmor |
| ERROR 2002 socket超时 | socket参数错位 | 客户端指定-h 127.0.0.1试连 |
这张表覆盖了大部分工单里的情况。实际处理时，建议从配置到权限再到安全模块依次排除，而不是同时改多项，否则分不清哪步生效。
有时还会遇到InnoDB报错说日志序列号不匹配，那是因为拷贝时实例没干净关闭。正确迁移前应先systemctl stop mysql确保无写入，再用rsync保持属性：rsync -avz /var/lib/mysql/ /new_disk/mysql_data/，这样能规避半吊子复制带来的字典不一致。
四、迁移后的校验清单
服务起来后，不要马上认为完事。登录进MySQL执行：
SELECT @@datadir; SHOW DATABASES; CHECK TABLE mysql.user;
确认@@datadir返回新路径，业务库都在，系统库表无损坏。再模拟一次重启systemctl restart mysql，看是否稳定。如果一切正常，旧目录可备份一段时间后删除，释放原磁盘。
整个排错核心在于：配置、权限、安全策略三处必须齐步到位。只要按上文顺序走，MySQL移动数据目录后的启动失败基本都能在十分钟内解决，不必重装或导数据。