新型数据库层出不穷，MySQL一幅日薄西山的样子。其实还有很多人或者偏爱、或者使用以前遗留的系统，仍然生活在MySQL的世界。
我也是有很久不用了，这个很久超过十年。
不过前几天有个朋友让我帮忙为他们升级服务器，才发现，老革命居然碰到个新问题。
因为是个用了很久的系统，所以不考虑变更数据库系统了。只是把当前数据库迁移到新的设备上，这应当是很简单的事情。按理说，数据文件大点，拷贝要时间，也超不过20分钟搞定，接下来小酒、撸串才是正理。
$ sudo su
# service mysql stop
# cd /var/lib
// 注意下面的mysql是当前的数据文件路径，/media/data是挂载的新存储阵列
// 使用-a选项，是已经考虑了要把文件的权限属性一起拷贝，免得拷贝完成再设置权限
# cp -Ra mysql /media/data/
// 老文件先不删除，保留备份防止意外
# mv mysql mysql-bak
// 偷个懒，直接建一个链接，免得要修改mysql启动脚本和设置文件
# ln -s /media/data/mysql/ .
# service mysql start
回车键按下，系统提示：
start: Job failed to start
赤裸裸打脸:(
查看日志文件：/var/log/mysql/error.log，得到一些错误信息：
190811 10:24:24 InnoDB: Operating system error number 13 in a file operation.
InnoDB: The error means mysqld does not have the access rights to
InnoDB: the directory.
InnoDB: File name ./ibdata1
InnoDB: File operation call: 'open'.
InnoDB: Cannot continue operation.
饶是之前就考虑了文件权限问题，拷贝之后，仍然出现了权限错误。
老的文件夹尚未删除，逐个对比了文件的权限，未发现问题。
在网上搜索了一下资料，发现大家不约而同的采用mv命令来移动数据文件夹，也是为了避免出现权限问题。而这里我为了保存备份，采用了cp -Ra。
这给出了一点线索，当前服务器Linux的版本，都已经默认了更高的安全设置。在Centos是SELinux，在Ubuntu是AppArmor。
这里说起来只是一句话，当时在现场，是做了很多无用功才在查看服务器启动脚本中想到了这个问题，时间浪费不少。
找到原因，解决不难，这台服务器使用了Ubuntu，对维护人员比较友好，只要编辑AppArmor的配置文件就好：
# vi /etc/apparmor.d/usr.sbin.mysqld
// 将以下4行：
/var/lib/mysql/ r,
/var/lib/mysql/** rwk,
/var/lib/mysql-files/ r,
/var/lib/mysql-files/** rwk,
// 修改为：
/media/data/mysql/ r,
/media/data/mysql/** rwk,
/media/data/mysql-files/ r,
/media/data/mysql-files/** rwk,
// 改的时候根据你的数据路径，调整上面4行的设置
// 此外考虑到/var/lib/mysql这个路径也可能会有测试需要，所以原始的4行保留，额外增加4行也可，不差那一点点运算
// 编辑完成存盘，接着更新配置和重启AppArmor服务：
# apparmor_parser -r /etc/apparmor.d/usr.sbin.mysqld
# service apparmor reload
接着再一次启动mysql服务：
# service mysql start
一切正常了。
如果使用了Centos，则要更改SELinux的额外权限设置，可参考下面链接中介绍的两个方法操作。
参考文献：How to Move MySQL Data Directory to New Location on CentOS and Ubuntu
