0
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

MySQL データディレクトリの移行と接続確認手順

Last updated at Posted at 2024-09-05

アジェンダ

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による効率的なパフォーマンス。

ルートボリュームに依存せず、データ専用のボリュームを活用することは、長期的な運用の安定性を保つ上で重要になると思います。

参考

0
1
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
0
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?