mysql 文件权限_MySQL数据库文件的移动和权限设置

新型数据库层出不穷，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的额外权限设置，可参考下面链接中介绍的两个方法操作。