リカバリ完了

ども、slidermanです。

先ほどようやくDBのリカバリ作業が完了しました。

これで晴れて僕も釈放です。

DBエンジニアの仕事ってどういうものがあるかについてはまた書きますが、こうやって壊れたDBを復旧するのも重要な業務の一つです。

ちなみにタイトルのリカバリというのは、一応簡単にいうと何らかの事情により壊れてしまったデータベースを元に戻すために、バックアップを戻し（これをリストアと言う）、各データベースで用意されているリカバリコマンドを発行し、ある特定の時点までデータベースの状態を戻す作業のことです。

だいたいこのリカバリ系の仕事はいつも突然入り、そして深夜から朝に帰宅するハメになります・・・

今回の事象についてはこれも後日まとめますが、教訓として以下だけは記しておきます。

　取得したバックアップが使いものになるとは限らない。

　必ずバックアップが使えるものかどうか確認すること！

今回のお客様のバックアップも、お客様は自信満々に「バックアップがあります！」とは言っていたものの、いざそのバックアップを使ってもリカバリできませんでした。

いやぁ、ホントこういうことってよくあるんですよね。

皆様もお気をつけて。

必ずバックアップ取ったら、戻るかテストしてくださいね。

今後の予定

こんばんわ～。

色々書きたいことがあるのですが、現在まさにDBシステムのトラブルに直面しています・・・。

解決したら本件についても書きますので、しばしお待ちを。

一先ず当面は、可用性という項目について僕の考えをまとめ、現状と対策の分析を記載していきたいなぁと思っています。

よくDBマガジン等にも似たことは書いてあるんですが、全体を一般化した可用性に関する文書ってなかなかないのでは？と思ってるので。

それはさておき、とりあえずシステムエンジニアの皆さん、F/Oテストやリカバリ検証はちゃんとやっておいてくださいね！！

エライ目にあいますから、これを省くと。

では、また。

DBシステムで可用性が低い理由

可用性という言葉を使う際に、よく言われるのが SPOF(Single Point of Failure)という言葉。

かなり平たく言ってしまえば、1箇所がダメになればシステム全体がダメになる、という場所の事。

たった1箇所がダメになっただけで全てが止まってしまう、という意味では、例えば車ならエンジン、自転車ならタイヤ、をイメージしてもらえればわかりやすいかもしれませんね。

DBシステムにおいても、1箇所がダメになったからといってシステムダウンする事は基本的に許されないわけです。

可用性を高めるということは、SPOFを極力無くし、1箇所がダメになっても残りの生きている部分でシステムを稼動し続けさせるということに他なりません。

では、可用性を高めるためにはどうすれば良いのでしょうか？

以下が物凄く一般的なDBシステム構成図です。

皆さんがインターネットでショッピングをしたり、こうしてブログを見たり、会社で精算をしたりするシステムのほとんどは上記のような構成になっています（細かい点は大幅に省いてますけどね）。

左側が皆さんのPCで、通常はインターネットエクスプローラー等のブラウザを使って、URL（httpで始まるやつ）を指定すれば、アプリケーション・サーバというところにアクセスし、何か検索をしたりすればその背後（上記図では右側）にあるデータベース・サーバからデータを取ってくる形になっています。

ここからが本題ですが、上記でSPOFとなり得るのはどの部分でしょうか？

かなりざっくりとまとめると以下の部分になります。

(1) PC本体、及びそこに繋がるLANケーブル、ネットワーク・カード等

(2) LANケーブル、公衆回線、FireWall、プロキシ・サーバ、ネットワーク・ケーブル等

(3) アプリケーション・サーバ、ネットワーク・カード、ロード・バランサ等

(4) データベース・サーバ、共有ディスク・・・等々

ここまで書くと、多くのシステムエンジニアの方から、「そんなことはわかってるよ！」と突っ込まれそうですね

しかし、本当に上記部分を全て意識して構築されたシステムはどの程度あるのでしょうか？

僕が知る限り、ほとんどないか、かなり少ないのではないかと思います。

例えばデータベース・サーバがダウンしたら上記システムは完全停止になります。

それを防ぐ手立てとしては、最も有名な商用データベース・ソフトウェアであるORACLEであれば、RAC（Real Application Clusters）という構成で、データベース・サーバを複数台で1台に見せかける技術により、SPOFを防ぎます。

RAC構成は複数台のマシンが1つの共有ディスクを見る形になるため、共有ディスクはRAID構成で更に最近流行の高速コピー機能のディスクにする事で何かあってもすぐにリカバリできるようにします。

アプリケーション・サーバがダウンしてもダメですから、一般的には複数台のアプリケーションを用意しておき、且つ、PCとの間にロード・バランサを用意する事で、SPOFを防ぎます。

ロードバランサも2台用意しておき、全てのネットワーク･カード、回線も多重化する事で、SPOFを更に防ぎます。

世の中的にはこういった形で全ての階層を「多重化」する事でSPOFを最小化しようとします。

ここで問題なのは、

どの部分を、どの機能（ハードウェア？ソフトウェア？）でカバーするのか

何か問題があったときに、どう対処すべきか

を全て把握できる人材が、極端に少ないということです。

かく言う僕も、お恥ずかしい限りですが全てはとても把握できていません。。。

例えばディスクにはRAIDという機能があります。

簡単にいえば、ディスクの一部が壊れても稼動し続ける事が出来たりするような機能です。

これをデータベースを絡めた場合に、データベースを構成するファイルの配置はどうすべきでしょうか？

RAIDグループとデータベースを構成するファイルの配置は気にしなくても大丈夫でしょうか？

データベース・サーバがダウンしても、他のデータベース・サーバを使用して処理を継続したい場合、アプリケーション・サーバ側、データベース・サーバ側で意識すべきOSパラメータは何でしょうか？

ロードバランサはソフトウェア、ハードウェアのどちらを使用すべきでしょうか？

NIBって何でしたっけ・・・？

HBAって・・・？

VIOって・・・？

クラスタって・・・？

インターコネクト回線・・・？

これらを網羅する事は非常に困難ですし、上記図以外にも可用性を高めるために意識しなければならないポイントもあります。

ここまでで高い可用性を維持することが如何に難しい事か、おわかり頂けたでしょうか。

可用性を高める機能は無数にあっても、それを現実のシステムに落とし込むところが非常に難しいわけです。

ディスク屋さん、ネットワーク屋さん、ソフトウェア・ベンダ、ハードウェア・ベンダ等々、各分野の専門家はいたるところにいますが、システムをトータルで見る能力をもった「人材」が少なく、この点が可用性を高くすることが難しい最大の要素なのです。

ちょっと長くなってしまいましたが、今日はここまで。

では、また！

■可用性まとめ

可用性とは
DBシステムで可用性が低い理由
可用性と予算の関係性
DBシステムの高可用性構成概要（Active/Standby）　その1
DBシステムの高可用性構成概要（Active/Standby）　その2
DBシステムの高可用性構成概要（Active/Active）　その1
DBシステムの高可用性構成概要（Active/Active）　その2