Ubuntu下面更改MySQL數(shù)據(jù)庫數(shù)據(jù)存儲(chǔ)目錄遇到的問題

之前寫過一篇博客“MySQL更改數(shù)據(jù)庫數(shù)據(jù)存儲(chǔ)目錄”，當(dāng)時(shí)的測試環(huán)境是RHEL和CentOS，誰想最近在Ubuntu下面更改MySQL數(shù)據(jù)庫數(shù)據(jù)存儲(chǔ)目錄時(shí)遇到了之前未遇到的問題，之前的經(jīng)驗(yàn)用不上了（或者說之前的總結(jié)不是太全面），修改完MySQL數(shù)據(jù)庫數(shù)據(jù)存儲(chǔ)目錄后重啟MySQL，發(fā)現(xiàn)MySQL服務(wù)無法啟動(dòng)。

root@mylnx2:/etc/mysql/mysql.conf.d# service mysql start

Job formysql.service failed because the control process exited with error code.See"systemctl status mysql.service"and"journalctl -xe"fordetails.

連MySQL的錯(cuò)誤日志也未生成，使用service mysql status命令可以輸出一些較詳細(xì)的信息，如下所示：

錯(cuò)誤信息為“[Warning] Can’t create test file /mysql_data/mysql/mylnx2.lower-test”。其實(shí)這里是踩到了“AppArmor”這個(gè)坑，之前對Ubuntu了解不多，所以直到遇到這個(gè)問題，才了解、知道這么個(gè)概念。下面是百科對AppArmor的介紹：

AppArmor是一個(gè)高效和易于使用的Linux系統(tǒng)安全應(yīng)用程序。AppArmor對操作系統(tǒng)和應(yīng)用程序所受到的威脅進(jìn)行從內(nèi)到外的保護(hù)，甚至是未被發(fā)現(xiàn)的0day漏洞和未知的應(yīng)用程序漏洞所導(dǎo)致的攻擊。AppArmor安全策略可以完全定義個(gè)別應(yīng)用程序可以訪問的系統(tǒng)資源與各自的特權(quán)。AppArmor包含大量的默認(rèn)策略，它將先進(jìn)的靜態(tài)分析和基于學(xué)習(xí)的工具結(jié)合起來，AppArmor甚至可以使非常復(fù)雜的應(yīng)用可以使用在很短的時(shí)間內(nèi)應(yīng)用成功。

AppArmor對MySQL所能使用的目錄權(quán)限做了限制，如下截圖所示，規(guī)定了MySQL使用的數(shù)據(jù)文件路徑權(quán)限。

# cat /etc/apparmor.d/usr.sbin.mysqld

我將MySQL的數(shù)據(jù)庫數(shù)據(jù)存儲(chǔ)目錄從/var/lib/mysql 切換到/mysql_data/mysql下面。所以就遇到了上面錯(cuò)誤，需要修改或新增兩條記錄，從而使mysqld可以使用/mysql_data/mysql這個(gè)目錄

/mysql_data/mysql/ r,

/mysql_data/mysql/** rwk,

然后重啟AppArmor服務(wù)后，然后就可以重啟MySQL服務(wù)了。

sudo service apparmor restart

當(dāng)然/etc/apparmor.d/usr.sbin.mysqld還有Allow plugin access需要調(diào)整，這個(gè)不是重點(diǎn)，在此略過。

猶豫了一會(huì)，還是記錄一下這個(gè)小小案例！雖然網(wǎng)上已有不少人總結(jié)這個(gè)，但是自己動(dòng)手總結(jié)一下，印象也深刻一點(diǎn)！