アジェンダ
AWS EC2 や他のサーバー環境で MySQL を運用する際、データディレクトリをルートボリューム(/var/lib/mysql
)から別のボリュームに移行することが必要になる場合があります。ここでは、MySQL データディレクトリを新しいボリュームに移行し、接続を確認する方法についてまとめます。
なぜルートボリュームからデータを移動するべきか
1. データの安全性とパフォーマンス
ルートボリュームはOSがインストールされているディスクであり、システムファイルやその他の重要なデータも含まれています。MySQLのデータがルートボリュームにあると、ディスク容量が不足するリスクがあり、システムの安定性に悪影響を及ぼす可能性があります。特にデータベースの成長に伴い、ディスク容量が逼迫するとシステム全体が正常に動作しなくなるリスクがあります。
2. 専用ボリュームによる管理の効率化
データベース専用のボリュームにデータを移行することで、容量管理やバックアップが効率化されます。専用ボリュームにすることで、バックアップやスケールアップの操作も容易になり、運用の負荷が軽減されます。
3. パフォーマンスの向上
MySQLのデータを専用のボリュームに移すことで、ディスクI/Oが分散され、データベース操作のパフォーマンスが向上します。特に高負荷なシステムでは、ディスクのI/O競合を避けるために専用のボリュームを使用することが重要です。
MySQL データディレクトリの移行手順
以下に、MySQL のデータディレクトリをルートボリュームから新しいボリュームに移行する具体的な手順を説明します。
1. MySQLの停止
MySQLデータを移行する前に、MySQLサービスを停止し、データベースへの書き込みが発生しないようにします。
sudo systemctl stop mysql
2. ボリュームのマウント手順
データディレクトリを新しいボリュームに移行する前に、まずボリュームを正しくマウントする必要があります。
1. 新しいボリュームの確認
lsblk
コマンドを使用して、新しいボリュームが認識されているか確認します。
lsblk
新しいボリュームが xvdb
として表示されていると仮定します。
2. ファイルシステムの作成
新しいボリュームにファイルシステムが存在しない場合、mkfs
コマンドでファイルシステムを作成します。
sudo mkfs -t ext4 /dev/xvdb
3. ボリュームのマウント
作成したボリュームを /data
ディレクトリにマウントします。
sudo mkdir /data
sudo mount /dev/xvdb /data
4. 永続的なマウント設定
サーバーを再起動してもマウント状態を維持するため、/etc/fstab
に以下の設定を追加します。
/dev/xvdb /data ext4 defaults 0 0
これにより、サーバー再起動後も新しいボリュームが自動的に /data
にマウントされるようになります。
3. データディレクトリの移行
rsync
を使用して、/var/lib/mysql/
のデータを新しいボリュームにコピーします。ここでは、新しいボリュームが /data
にマウントされていると仮定します。
sudo rsync -av /var/lib/mysql/ /data
-
-a
:アーカイブモードで、ファイルの所有権、パーミッション、タイムスタンプなどを保持します。 -
-v
:詳細な出力を表示します。
4. MySQL設定ファイルの編集
MySQLが新しいデータディレクトリを使用するように、設定ファイルを編集します。
通常、MySQLの設定ファイルは /etc/mysql/mysql.conf.d/mysqld.cnf
にあります。このファイルを編集して、datadir
のパスを変更します。
sudo vi /etc/mysql/mysql.conf.d/mysqld.cnf
設定ファイル内で以下の行を見つけ、datadir
を /var/lib/mysql
から /data
に変更します。
datadir = /data
5. AppArmor 設定の確認(Ubuntuの場合)
Ubuntu では、AppArmor が MySQL のアクセスを制限することがあります。AppArmor の設定を変更して、新しいディレクトリへのアクセスを許可します。
sudo vi /etc/apparmor.d/usr.sbin.mysqld
次に、以下の行を追加して、新しいディレクトリへのアクセスを許可します。
/data/ r,
/data/** rwk,
設定後、AppArmor を再読み込みします。
sudo systemctl restart apparmor
6. MySQLの再起動
設定を変更した後、MySQL サービスを再起動します。
sudo systemctl start mysql
7. MySQL 接続確認
MySQL に接続し、データベースが正しく動作しているかを確認します。
mysql -u root -p
mysql> SHOW DATABASES;
このコマンドでデータベースが表示されれば、MySQL が新しいボリューム上で正常に動作していることを確認できます。
トラブルシューティング
1. Permission denied
エラー
MySQL が /data
ディレクトリにアクセスできない場合、次の点を確認してください。
-
/data
ディレクトリの所有者がmysql
ユーザーであり、パーミッションが 700 で設定されているかを確認します。
sudo chown -R mysql:mysql /data
sudo chmod 700 /data
2. AppArmor の設定確認
AppArmor が原因で MySQL が起動しない場合は、AppArmor の設定ファイルに /data
へのアクセスが許可されていることを確認し、再度AppArmorを再読み込みします。
sudo systemctl restart apparmor
3. エラーログの確認
MySQL のエラーログを確認して、詳細なエラー情報を確認します。
sudo cat /var/log/mysql/error.log
まとめ
この手順では、MySQL のデータディレクトリをルートボリュームから別のボリュームに移行し、接続を確認する方法を解説しました。
データディレクトリを移行することで、システム全体のパフォーマンスと安全性が向上し、データの管理やバックアップも効率化されます。
- 安全性向上:ルートボリュームの容量逼迫を回避し、システム安定性を保つ。
- 管理効率化:専用ボリュームでデータ管理とバックアップが容易に。
- パフォーマンス向上:データベース専用のI/Oによる効率的なパフォーマンス。
ルートボリュームに依存せず、データ専用のボリュームを活用することは、長期的な運用の安定性を保つ上で重要になると思います。