新型資料庫層出不窮，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的額外許可權設置，可參考下麵鏈接中介紹的兩個方法操作。
參考文獻：How to Move MySQL Data Directory to New Location on CentOS and Ubuntu
