因为是个用了很久的系统，所以不考虑变更数据库系统了。只是把当前数据库迁移到新的设备上，这应当是很简单的事情。按理说，数据文件大点，拷贝要时间，也超不过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 toInnoDB: the directory.InnoDB: File name ./ibdata1InnoDB: 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的额外权限设置，可参考下面链接中介绍的两个方法操作。
参考文献：