何をして何がおきたか？
発生した現象
サーバにHDDを増設した後，DBの保管場所をそちらに切り替えようと思い，
# cp -pR /var/lib/mysql /mnt/新しいHDD/var/lib/mysql
# mv /var/lib/mysql /var/lib/mysql_old
# ln -s /var/lib/mysql /mnt/新しいHDD/var/lib/mysql /var/lib/mysql
などとして，適当に移動してみたところ，SELinuxが動いている状態では phpMyAdmin などからの接続が不能に
原因
当然ながらSELinuxが原因で，
# setenforce 0
で，SELinuxを停止すると動く
このままSELinuxを稼働させないようにして運用する手もあったが，
せっかくなのでSELinuxも稼働させつつ使えるようにがんばった記録
解決までの道のり
環境など
- OS: CentOS 7.X
- DB: MariaDB 10.X
- httpd: Apache 2.X
使ったコマンド類
semanage, restorecon, setroubleshoot-server
（ちなみにどれも入っていましたし，yumで簡単に入れられます． ）
具体的な道のり
まず，SELinuxをpermissiveモードで起動するために， /etc/sysconfig/selinux を書き換えて再起動．
下記，参考サイトに従って， # less /var/log/messages でログを確認
コピーした先のファイルに適切なSELinuxのファイルタイプが設定されていないのが原因であることが判明
ログの方の最後の方に以下のメッセージ
allow this access for now by executing:
# grep mysqld /var/log/audit/audit.log | audit2allow -M mypol
# semodule -i mypol.pp
素直にコピペ（戻って来るまで10secぐらい待つ）
# systemctrl restart mysql.serviceで，デーモン再起動
下記，参考サイトに従って， # less /var/log/messages でログを確認
まだ怒られていた，mysql.sock のファイルタイプに問題があるらしい
オリジナルの方（ /var/lib/mysql_old ）に移動して，ls -Z でファイルタイプなどを確認し，
以下のように設定
# semanage fcontext -a -t mysqld_db_t -f s '/mnt/新しいHDD/var/lib/mysql/mysql\.sock'
# restorecon -RFv /var/lib/mysql
# systemctrl restart mysql.serviceで，デーモン再起動
下記，参考サイトに従って， # less /var/log/messages でログを確認
今度は良い感じ．
# setenforce 1 にしてみても問題なく稼働
おしまい！
注意事項
mysql.socket は mysqld が使う ＆ 一つのファイルに複数のSELinuxファイルタイプは難しそう…
ということで，事前に # setsebool httpd_can_network_connect_db on はしてあり，
phpMyAdminはローカルホスト（127.0.0.1）と無駄にTCPでやりとりしています