なんとレンタルサーバが逝ってしまった。ファイルシステムエラーとかで、OS
のクリーンインストールになってしまった。実を言うと少し前からちょっとお
かしかったんで、兆候はあったらしいのだが...
それで先週のある晩、リブートかけたら戻ってこなくなったって。そっこで障害に連絡し
てみてもらったら、再インストールになるらしとのこと、このサーバ借りたの
は６年ちかく前なのでその当時のRedhat es3からRedhat es5へディスクも80GBだっ
たのが320GBになった。ディスクの容量アップはムーアの法則通りですね。２
年で倍々ゲーム。
しかし、問題はアプリ関係でphpもバージョンあがったし、mysqlもバージョン
あがった。phpは元々4だったからあまり問題ないけど、問題はDB。mysqlはそ
の当時そのレンサバは3.23だった。すでに4系が出て新しい物ずきは4を使って
いるよな状況だったが(自分も社内では4系にしていた)3.23でちょっと古いな
あと思っていたのだが、まあ、仕方ないとおもいつつ。
それで、3.23で問題なのは、バックアップとっていたのだが/var/lib/mysql/
以下をまるまるバックアップしていたのだ。同じバージョンならそのまま戻せ
ば問題ないのだがバージョン違うとだめ。特に4.1からかわったんで、データ
消えたりするらしい。とりあえず、一度3.23でdumpして、5にリストアっての
が一番良さそうなんで3.23をセットすることに。しかし、もう今時3.23ってな
いんだよなこれが。webで検索した結果だと半年くらい前までSoftAgencyのサ
イトにあったみたいだがいまはもうなくなっていて、古くても４系だけ。古い
アプリを新しいOSにいれるのはライブラリなど依存関係で結構手直しが必要に
なる。
こうなりゃ、昔のディストロのCDひっぱりだしてくるしかない。実はつい数週
間前、昔のCD群を処分しようとしていろいろ整理したところだった。
Redhat6.1、7.2とかTurboLinux６、７、vine2.15とかいろいろあった。それで、
Redhatは残しておいたんだ、こういうこともあるとおもって。
それで7.2を余ってるPCにインストしてバックアップから/var/lib/mysqlをコ
ピーしてDBの復帰完了。それでmysqldumpでデータはき出して、文字コードは
今回は変えないことにした。mysql5なんでutf8がいいんだけど、いろいろとア
プリの関係もあってここ変えるとすべてに関わってくるからなあ。とりあえず
そのままでdump。
それでdumpデータをmysql5に戻してデータが戻ってることを確認。後はユーザー
を再登録し直してこんな時のために登録用のスクリプト作ってあるし。ユーザー
多いから大変なんだよいちいち登録するの。
あとは、php.iniを修正して、Pear入れ直して、一つSmartyをPearifiedの
Channelから入れてたんだけど、どうも消滅していた。なので、こちらだけは
本家から入れ直し。それでSmarty関連のイニシャルファイルを修正。Smarty使っ
てるところではすべてこのファイルrequireさせてるから、ここだけ修正すれ
ばOK。これでとりあえず復旧できました。１日かかってしまった。
今回の事柄から考えたこと
よく、動いているシステムさらに安定しているシステムにわざわざ手を入れる
ことはタブーとされているが昨今の目覚ましいソフトウェアの進歩によってす
ぐにバージョン遅れになってくる。たとえばレンタルサーバを移行するとかな
ると移行した先では新しいバージョンで動いていたりということは当たり前。
そんなんで、最新を追うのは違うのはわかるだろうが、新しいバージョンが安
定して枯れた感じになったときにバージョンアップしておいた方が得策なので
はないかと。ぎりぎりまで使って、一気にバージョンアップてのもありなのか
もしれないが、いきなりの時に困る。
あと、やっぱデータをバックアップしておいてとかは当たり前なんだけど、ど
うしてもこのようにダウンタイムが出てしまう。まあ、とめちゃいけないクリ
ティカルなサービスではないんだけど、やっぱりこれはめんどくさい。それで
この際２台でDNSラウンドロビンで回してみたいにして、夜間に同期とって同
じ状態のサーバ２台にするのが得策かと。その場合、やっぱり有償OSよりは
CentOSとかFreeBSDとかのほうがいいねぜったい。
社内だとCentOSかFreeBSDなんだけど、レンサバもあわせた方がいいとわかっ
た。
のクリーンインストールになってしまった。実を言うと少し前からちょっとお
かしかったんで、兆候はあったらしいのだが...
それで先週のある晩、リブートかけたら戻ってこなくなったって。そっこで障害に連絡し
てみてもらったら、再インストールになるらしとのこと、このサーバ借りたの
は６年ちかく前なのでその当時のRedhat es3からRedhat es5へディスクも80GBだっ
たのが320GBになった。ディスクの容量アップはムーアの法則通りですね。２
年で倍々ゲーム。
しかし、問題はアプリ関係でphpもバージョンあがったし、mysqlもバージョン
あがった。phpは元々4だったからあまり問題ないけど、問題はDB。mysqlはそ
の当時そのレンサバは3.23だった。すでに4系が出て新しい物ずきは4を使って
いるよな状況だったが(自分も社内では4系にしていた)3.23でちょっと古いな
あと思っていたのだが、まあ、仕方ないとおもいつつ。
それで、3.23で問題なのは、バックアップとっていたのだが/var/lib/mysql/
以下をまるまるバックアップしていたのだ。同じバージョンならそのまま戻せ
ば問題ないのだがバージョン違うとだめ。特に4.1からかわったんで、データ
消えたりするらしい。とりあえず、一度3.23でdumpして、5にリストアっての
が一番良さそうなんで3.23をセットすることに。しかし、もう今時3.23ってな
いんだよなこれが。webで検索した結果だと半年くらい前までSoftAgencyのサ
イトにあったみたいだがいまはもうなくなっていて、古くても４系だけ。古い
アプリを新しいOSにいれるのはライブラリなど依存関係で結構手直しが必要に
なる。
こうなりゃ、昔のディストロのCDひっぱりだしてくるしかない。実はつい数週
間前、昔のCD群を処分しようとしていろいろ整理したところだった。
Redhat6.1、7.2とかTurboLinux６、７、vine2.15とかいろいろあった。それで、
Redhatは残しておいたんだ、こういうこともあるとおもって。
それで7.2を余ってるPCにインストしてバックアップから/var/lib/mysqlをコ
ピーしてDBの復帰完了。それでmysqldumpでデータはき出して、文字コードは
今回は変えないことにした。mysql5なんでutf8がいいんだけど、いろいろとア
プリの関係もあってここ変えるとすべてに関わってくるからなあ。とりあえず
そのままでdump。
それでdumpデータをmysql5に戻してデータが戻ってることを確認。後はユーザー
を再登録し直してこんな時のために登録用のスクリプト作ってあるし。ユーザー
多いから大変なんだよいちいち登録するの。
あとは、php.iniを修正して、Pear入れ直して、一つSmartyをPearifiedの
Channelから入れてたんだけど、どうも消滅していた。なので、こちらだけは
本家から入れ直し。それでSmarty関連のイニシャルファイルを修正。Smarty使っ
てるところではすべてこのファイルrequireさせてるから、ここだけ修正すれ
ばOK。これでとりあえず復旧できました。１日かかってしまった。
今回の事柄から考えたこと
よく、動いているシステムさらに安定しているシステムにわざわざ手を入れる
ことはタブーとされているが昨今の目覚ましいソフトウェアの進歩によってす
ぐにバージョン遅れになってくる。たとえばレンタルサーバを移行するとかな
ると移行した先では新しいバージョンで動いていたりということは当たり前。
そんなんで、最新を追うのは違うのはわかるだろうが、新しいバージョンが安
定して枯れた感じになったときにバージョンアップしておいた方が得策なので
はないかと。ぎりぎりまで使って、一気にバージョンアップてのもありなのか
もしれないが、いきなりの時に困る。
あと、やっぱデータをバックアップしておいてとかは当たり前なんだけど、ど
うしてもこのようにダウンタイムが出てしまう。まあ、とめちゃいけないクリ
ティカルなサービスではないんだけど、やっぱりこれはめんどくさい。それで
この際２台でDNSラウンドロビンで回してみたいにして、夜間に同期とって同
じ状態のサーバ２台にするのが得策かと。その場合、やっぱり有償OSよりは
CentOSとかFreeBSDとかのほうがいいねぜったい。
社内だとCentOSかFreeBSDなんだけど、レンサバもあわせた方がいいとわかっ
た。