さくらの VPS 4G で使える 120GB を全て使って MySQL などを大容量で運用する方法

さくらの VPS 4G にサービスを移転しました。120GBという表記だったのですが、SaaSes の様に一つのハードディスクとしてまとめているわけではなく、100GB が割り当てられるという構成で、実際には別のハードディスクとして提供されるようです。

さくらのVPS にてご提供しております仮想ハードディスクにつきましては、hda、hdb といった様に、仮想サーバ上では物理的に異なるハードディスクとなります。

異なるハードディスクを確認する

試しに以下のようにディスクの使用状況を表示してみると。

1
df -h

以下のように /dev/hda2 は下位プランのように同じ容量で、別で /dev/hdb1 に99GBが割り当てられています。/home はユーザーディレクトリ等がありますので、たまたま dump ファイルをそこに入れていたので、16GBとなってます。

Filesystem サイズ 使用 残り 使用% マウント位置
/dev/hda2 17G 6.3G 9.7G 40% /
/dev/hda1 99M 18M 76M 19% /boot
tmpfs 2.0G 0 2.0G 0% /dev/shm
/dev/hdb1 99G 16G 78G 17% /home

これらのパーティションなど、さくらの VPS についての活用方法については以下の記事が分かりやすいので参考にしてください。

追加領域の /dev/hdb1 を活用する

今回は MySQL のファイルが60GBあるサイトを移転したいと思います。それにあたって以下のページが大変参考になりましたので、こちらのページを参考にしながら進めていきたいと思います。

MySQL のファイルなどを別 HDD にする失敗編1

参考ページによると /var/www を別 HDD で運用したいなら以下のように別 HDD に対象のディレクトリをマウントすれば良いようです。

1
mount /dev/hdb1 /var/www

ただ、私としてはマウントとは以下のような意味だと思ってました。

コンピュータに接続した周辺機器や外部記憶装置(あるいは、装置に挿入されたディスクなどの記録メディア)をOSに認識させ、利用可能な状態にすること。

利用可能にするというわけで、分かりやすい例だと画像ファイルの入った USB メモリを差して、マウントして自分のパソコンから見たり、USB メモリ内のファイルを編集したりと言うわけで。ちょっと引っかかります。

ちなみに話がそれますが、次回起動時にもマウントさせるには以下のコマンドです。ファイルが開きますので、他の設定を参考に一番下に追加すると良いです。以下、次回起動時についてはこのコマンドを省いていきますので、適宜補完してください。

1
vi /etc/fstab

参考ページでは以上の作業で実現しようとしていました。そういう風にすれば別 HDD を利用できるのでしょうか。私では Web ファイルも MySQL のファイルも別 HDD で運用したいわけですから、/var/www と /var/lib/mysql が含まれている /var をマウントすればいいのだろうかと思って以下のようにしました。

1
mount /dev/hdb1 /var

上手くマウントされたようですが、再起動をしたところ SSH で接続できなくなりました。さくらの VPS の仮想コンソールより SSH をチェックしたら、/var の中にファイルを作って起動するようで、/var がおかしなことになっているので起動できなくなっていました。そのため、一度マウントを解除して再起動すれば、再度 SSH を起動して接続することができるようになりました。

MySQL のファイルなどを別 HDD にする失敗編2

しかし、参考ページでは /var/www をマウントして上手く行っていたので、SSH が起動できなくなったことも含めて考えると、この方法は有効なのかもしれません。必要なところを部分ごとにという方法をとってみます。私は MySQL を別 HDD で運用したいので MySQL のファイルがある /var/lib/mysql をマウントしてみます。

1
mount /dev/hdb1 /var/lib/mysql

そして再起動してみたらログインできなくなりました。さくらのバーチャルコンソールからはログインできますので、ユーザーディレクトリを見に行ったらこんなことになっていました。もちろん入れませんので、root でログインして見るとファイルは残っていました。

1
2
3
4
5
6
7
8
9
10
total 28756
-rw-rw---- 1 mysql mysql  5242880 Dec 13 20:46 ib_logfile0
-rw-rw---- 1 mysql mysql  5242880 Dec 13 20:34 ib_logfile1
-rw-rw---- 1 mysql mysql 18874368 Dec 13 20:46 ibdata1
drwxr-xr-x 3 mysql mysql     4096 Dec 13 19:07 lib 
drwx------ 2 mysql mysql    16384 Oct  3 18:18 lost+found 
drwx------ 2 mysql mysql     4096 Dec 13 20:34 mysql 
drwx------ 2 mysql mysql     4096 Dec 13 20:34 performance_schema 
drwx------ 5 mysql mysql     4096 Dec 13 19:07 example
drwx------ 2 mysql mysql     4096 Dec 13 20:34 test

これはおそらく、既に /home ディレクトリが割り当てられてる状態で /var/lib/mysql を割り当てたので、それと混ざったのかもしれません。既にあったものはなぜか mysql が所有者に。MySQL のデフォルトファイルが再生成されて混ざってる感じみたいです。

そして、ここで先ほどのモヤモヤが解けました。

利用可能にするというわけで、分かりやすい例だと画像ファイルの入った USB メモリを差して、マウントして自分のパソコンから見たり、USB メモリ内のファイルを編集したりと言うわけで。ちょっと引っかかります。

これについてですが、要は /dev/hdb1 という名の増設した HDD があるということです。/home にアクセスすると /dev/hdb1 が参照される、/varにアクセスしても /dev/hdb1 が参照されるようになっていた。そして、サーバーを起動しようとすると /var ディレクトリに必要なファイルがないので、システムが自動的に作成してくれた、それが MySQL のファイルなんだと思います。考えてみれば起動直後は MySQL は起動していなかったので起動をしたのです。実際に確認すれば /dev/hdb1 というのがあります。cd で移動しようとしてもアクセスできませんが。また、メインである /dev/hda1 も /dev/hda2 もあります。

この状態からの復元について

ということを考えると問題が起こったのは /dev/hdb1 だけとなります。システム全体に被害が及んだと思いましたが、理解してみると大したことはないですね。/dev/hdb1、すなわち /home ディレクトリにできた /var 用のファイル、言わばユーザーディレクトリ以外を削除した後、以下のコマンドで再帰的に所有者を戻してあげます。

1
chown -R user/user /home/user

結局どうするのが最適なのか

いくつか方法があります。

/home にシンボリックリンクを貼る方法

これは友達に教えてもらった方法ですが、既に /home ディレクトリが /dev/hdb1 に割り当てられていますので、そこに MySQL のファイルを入れることで、/dev/hdb1 で MySQL を管理する方法があります。

1
2
3
mkdir /home/example/mysql
cp -rf /var/lib/mysql/* /home/example/mysql
rm -rf /var/lib/mysql

このように、まず MySQL のファイルを全て /dev/hdb1 に、今回はユーザーのディレクトリ内に入れ、その上で本来 MySQL のファイルがあったところ、すなわち /var/lib/mysql からシンボリックリンクを、/dev/hdb1 の MySQL、つまり /home/example/mysql ディレクトリに貼ります。

1
ln -s /home/USERNAME/mysql /var/lib/mysql

もしくはシンボリックリンクではなく /etc/my.cnf の設定で /var/lib/mysql ではなく /home/example/mysql に変える方法もありますが、シンボリックリンクでの操作は CentOS などではよくあることなので、シンボリックリンクで実現するのが一般的で良さそうです。

/home と /var を入れ替える方法

/dev/hdb1 の中身を /var に差し替えて、/var を /dev/hdb1 にマウント、/home はメイン HDD に割り当てて運用するという方法です。おそらくシンボリックリンクでやるのが直感的ですし、さくらの VPS がデフォルトで /home を /dev/hdb1 に割り当てることを考慮すると、シンボリックリンクの方が相性の良い方法ではあると思いますが、今回は私の考えが実現可能なのかどうかということを試すためにも実践してみます。この方法については以下で説明します。

追加領域の /dev/hdb1 に /var を割り当てる成功篇

まず、デフォルトの /home が /dev/hdb1 に割り当てられていて、/var がメイン HDD に割り当てられているデフォルトの状態から始めます。

/home を退避する

ルートに /backup というディレクトリを作成して、そこに /home ディレクトリ内のユーザーデータなどを入れます。ユーザーデータが巨大じゃないかについて注意しましょう。

1
2
mkdir /backup
cp -rf /home/* /backup

/home すなわち /dev/hdb1 に /var の内容をコピー

/home に入れると言うと頭がごちゃごちゃしそうですが、実際には /dev/hdb1 です。ここに先に /var の内容をコピーしておきます。

1
cp -rf /var/* /home

メイン HDD の MySQL を削除

MySQL もろとも /var のデータは全て /dev/hdb1 にコピーが完了しましたので、古いデータについてはメイン領域の節約のために削除します。

1
2
cd /var/lib/mysql/
rm -rf hoge/ fuga/ piyo/

マウントを切り替える

データの反映が終わっていますので、マウントを切り替えます。

1
2
umount /home
mount /dev/hdb1 /var

再起動しても反映されるように /etc/fstab も設定しておきます。

1
vi /etc/fstab

退避していた /bacakup 内のデータを /home に戻します。

1
cp -rf /backup/* /home

新しく移動した先のユーザーファイルの所有者に気をつけてください。これで差し替えは完了したはずです。あとは reboot して、きちんとサーバーが起動するか、MySQL はきちんと前の状態を引き継いでいるか、サーバーの HDD の仕様状況はどのように変わったかについてをチェックします。

割り当てを確認する

割り当て変更前が以下です。

Filesystem サイズ 使用 残り 使用% マウント位置
/dev/hda2 17G 6.3G 9.7G 40% /
/dev/hda1 99M 18M 76M 19% /boot
tmpfs 2.0G 0 2.0G 0% /dev/shm
/dev/hdb1 99G 16G 78G 17% /home

割り当て変更後は以下になりました。

Filesystem サイズ 使用 残り 使用% マウント位置
/dev/hda2 17G 2.3G 14G 15% /
/dev/hda1 99M 18M 76M 19% /boot
tmpfs 2.0G 0 2.0G 0% /dev/shm
/dev/hdb1 99G 20G 74G 22% /var

/dev/hdb1 の中身はごっそり変わりましたが確実に使えていますね、これを知らずにそのまま運用していたら HDD を使い切ることができなかったかもしれません。

MySQL が使えない

MySQL が起動していない。以下のコマンドを実行すると。

1
/etc/init.d/mysqld start

なん…だと…。

1
2
MySQL Daemon failed to start.
Starting mysqld:                                           [FAILED]

原因がわからないのでログを見てみます。

1
tail /var/log/mysqld.log

全てが上手く言ったと思ったのですが、最後の最後で問題がありました。

1
2
111214  2:57:46 [ERROR] /usr/libexec/mysqld: Can't create/write to file '/var/run/mysqld/mysqld.pid' (Errcode: 13)
111214  2:57:46 [ERROR] Can't start server: can't create PID file: Permission denied

エラーの部分にだけ注目してみると、どうやら /var/run/mysqld/mysqld.pid に書き込みができないことでエラーが出ているようです。というわけで確認してみたところ、コピーする際にユーザーが root になってしまったことが判明しました。mysql フォルダ内のデータベースファイルも root になっており、所有者とか意識してコピーすることを心がければ良かったかもしれません。

1
chown -R mysql mysqld

これで MySQL が起動するようになりましたが、実際には使えません。よく見てみるとその他にも所有者が違うところがあります。まったく同じ構成のサーバーを持ってますので、それを参考に全て一つずつ変えていきます。RPG をやっているつもりで頑張ります。

ちなみに所有者は数十分で反映終わりましたが /var/lib/php/session のパーミッションに問題があって SESSION が使えなかったりとトラブルがたくさん。正しい /var のデータはありますので、再度コピーを試みても良いかもしれませんが、エラー対応していくのも勉強になるのでこのままで良さそうです。SESSION や MySQL などは上手く使えているので24時間稼働テストをして、サーバー移転をしたいと思います。

以下のサイトが参考になりました。

おわりに

私はサーバーはあまり詳しくないので、なぜ /dev/hdb1 が /home にデフォルトで割り当てられているかは分かりません。初心者の私の意見としては /var/www に Web サイトのデータを入れたり、/var/lib/mysql で MySQL を管理するので、最初から /var に割り当てて欲しいと思うところです。

しかしながら、今回の割り当て変更を通して、Linux などでのマウントについて学ぶことができました。特にディレクトリを別の HDD にマウントした場合、前のディレクトリが上書きされたり消えたりするわけではなくメインの HDD に裏で残っているということについては大変勉強になりました。マウントって苦手でしたが、どんどん活用していきたいと思います。今回はとても複雑なので必死にブログに考えをまとめていないと、自分が何を考えて、何をしているのかが分からなくなるところでしたが、無事目的を達成することができて良かったです。

コメント

コメントは受け付けていません。