さくらの 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 に裏で残っているということについては大変勉強になりました。マウントって苦手でしたが、どんどん活用していきたいと思います。今回はとても複雑なので必死にブログに考えをまとめていないと、自分が何を考えて、何をしているのかが分からなくなるところでしたが、無事目的を達成することができて良かったです。
コメント