title_blog2.gif

Home
'07.11.06　データベースのtable消去 プリント

うちのスタッフが、今日の朝突然、「いつも表示されているデータが表示されません！」と言い出した。

まずはサーバーの負荷やプロセスの状態を調べてみる。
これは特に問題ないようだ。

次はデータベースのログを見てみる

ERROR:  relation "table_xxxxxx" does not exist
ERROR:  relation "table_xxxxxx" does not exist
・
・


と、いっぱいエラーメッセージが出力されていた。

ん？　テーブルが見当たらない？(^^;
「テーブルが見当たらないと、言っているよ！」とスタッフに伝えると、なんだかバツが悪そうに、「昨日、誤って消してしまったようです....。」と

「えー！」　一瞬顔面が蒼白になる..。


既に自サーバーのバックアップでは、サイクリックに上書きされてしまってが、確か別サーバーにも退避されているはず...。
作業中はいろいろな最悪のケースが頭をよぎる。


「あった！」
自分でバックアップの仕組みを作っていながら、ことが起きると本当に必要データが本当にあるのか不安になるののである。

結局、データベースを一旦削除して、再度リストアすることで解決した。
夜間バッチで更新されなかった部分は、合間合間にバッチを走らせることで、すべてが正常な状態に戻った。


すべての復旧作業が終わって、スタッフに理由をたずねてみると、新しいテーブルを作るバッチを走らせた際に、そのシェルスプリクトのなかに、当該テーブルのdroptableコマンドが入っていたらしい。

いつもテスト用にテーブルを一旦消して、改めて作り直すときにつかうスプリクトだったらしいのだが、実行する前にちゃんと確認して、「これで大丈夫」と思ったらしい。
今考えてみると、「なんでそんなことに気づかない？」と思えるのだが、人はときに目に前に見えていても、それが脳にはっきりと認識できない動物なようなので、この手の人的ミスは結構頻繁に起きてしまうようだ。
現に、自分も「絶対に正しい」と思っている手順で実行したら、失敗したケースは何度も経験していて、その度に、「一番疑わないといけないのは、自分だなぁ」と思うわけです。

今回は、バックアップデータがちゃんとした手順で退避されていたから、事なきを得たことになるが、これからも「人間は必ずミスを犯す動物」と肝に命じて、いつでもリカバリーできるような手順を考えて行きかないといけませんね。　学ぶことの多い一日でした。
 
[ 戻る ]