================================================================ データベース運用編（α版） ================================================================ ---------------------------------------------------------------- 4. データベースの運用 ---------------------------------------------------------------- 4.1 データベースライブラリ nomosサーバシステムでは、データベースについての 「環境設定ファイル」「構造情報」「内容情報」「動作中の情報」 等といった情報の一揃いをまとめて『データベースライブラリ』と呼びます。 データベースライブラリは、ファイル空間上に いくつでも自由に作成し、保持することができます。 ひとつのnomosサーバは、一度にひとつのデータベースライブラリを メモリ上に展開して動作します。 いくつかのデータベースライブラリのうち、どれを起動するかは、 nomosのコマンドラインオプションで指定できます。 (データベース名が無指定の場合は、 データベースライブラリ名は"default"となります) 例：データベースライブラリ名：cone15Sep1997 nomos -p 7001 cone15Sep1997 4.2 サーバが利用するライブラリ名と、ライブラリ用ディレクトリ サーバが利用するライブラリ名を$nameと表すと、 データベースライブラリは、ファイル空間上では、 $NOMOS/lib/$name/ というディレクトリ以下に納められます。 例：データベースライブラリ名：cone15Sep1997 $NOMOS/lib/cone15Sep1997/ また、ライブラリ名の中に'/'を利用すると、 ライブラリを階層的に指定することができます。 例：データベースライブラリ名：cone/backup/1997/Sep/15 $NOMOS/lib/cone15Sep1997/cone/backup/1997/Sep/15 4.3 データベースライブラリの新規作成 データベースライブラリを新規に作成する場合には、 まず、起動時オプションのライブラリ名として、 これから作成するデータベースライブラリ名を指定して、 nomosサーバを起動します。 ライブラリ名には、UNIXのファイル名として使用が 推奨される文字(A〜Z,a〜z,0〜9,+,-,.,_)のみを利用するのが 無難です。 例： nomos -p ポート番号 新規ライブラリ名 nomosの起動時オプションによって、 「存在しないデータベース名」を指定した場合には、 その名前でデータベースライブラリのスケルトンが作成されます。 (ライブラリ名の中に'/'を利用した場合には、 実際にライブラリを保持するディレクトリに至る 各ディレクトリ階層についても、必要に応じて作成します) この状態では、データベースには「ユーザー」クラスのみが定義されています。 ほかのクラスを定義するためには、リファレンスマニュアルを参照し、 $NOMOS/lib/ライブラリ名/base/class.java クラス構造定義ファイル をエディタで編集します。 次に、こうして編集したclass.javaを読み込ませるために、 loadClass ポート番号 ライブラリ名 というコマンドを実行します。 このコマンドにより、クラス構造定義ファイルライブラリの 再読み込みが行われ、動作中のデータベースに反映されます。 また、loadClassを利用しなくても、nomosサーバを一旦 終了し、再度起動し直すことでも、新しいクラス定義ファイルを 読み込むことができます。 こうしてクラス構造の定義を終えた後には、 データベースの中身(実体)であるインスタンスを 閲覧・作成・編集・削除したり、検索を行うなどといった、 Webブラウザによるデータベースの利用が開始できます。 4.4 複数のデータベースを同時に利用する nomosのサーバシステムは、 単一のサーバマシン上において、複数のデータベースサービスを 同時に運用することも可能です。 これは、ポート番号と、データベースライブラリ名を重複しないように設定しれば、 複数のサーバプロセスを同時に起動できるようになっているためです。 例：port 7001 で service1 を起動。 port 7002 で service2 を起動。 nomos -p 7001 service1 nomos -p 7002 service2 ※ 複数のサーバが同時にひとつのデータベースライブラリを指定して 起動することはできません。この機能は、2.2で述べたように、 各データベースライブラリは、ロックファイルを作成するによって 実装されています。 ---------------------------------------------------------------- 5. データベースのバックアップ ---------------------------------------------------------------- nomosシステムでは、適宜データベースをバックアップしておくと、 そのバックアップを利用して、 バックアップ時点のデータベースの状態を再現させることが可能です。 nomosシステムでは、こうしたバックアップは、 データベースライブラリの単位で行われます。 すなわち、データベースライブラリAのバックアップを行うためには、 ライブラリAのバックアップ用として、ライブラリBを作成する、 という方法が用いられています。 5.1 サーバが停止している場合のバックアップ サーバが停止している場合には、データベースライブラリの内容は、 $NOMOS/lib/ライブラリ名/ というディレクトリ以下に全ての情報が納められています。 従って、「停止中のライブラリをファイルとしてコピーする」ことで、 最も基本的なデータベースのバックアップが行えます。 具体的な手順は以下の通りです。 ＜バックアップ＞ 1. バックアップ対象のライブラリについて、 サーバが起動していれば、これを停止する。 これにより、バックアップ対象ライブラリの内容はすべて ファイル空間内に記録される。 例： killnomos バックアップ対象ライブラリ 2. 該当するライブラリのディレクトリを、丸ごと複製する。 例： cp -r バックアップ対象ライブラリのディレクトリ \ バックアップ先ライブラリのディレクトリ ＜バックアップ内容のチェック＞ 3. 必要に応じて、バックアップ内容のチェックができる。 起動時オプションで、バックアップライブラリ名を指定してサーバを起動する。 (チェックが済んだらサーバを停止する。) 例： nomos -p ポート番号 バックアップ先ライブラリ (killnomos バックアップ先ライブラリ) ＜バックアップ内容を戻す＞ 4. バックアップディレクトリの内容で、もとのディレクトリの内容を 上書きしてから、サーバーを起動する。 例： cp -r バックアップ先ライブラリ もとのバックアップ対象のライブラリ nomos もとのバックアップ対象のライブラリ 5.2 サーバが動作中の場合のバックアップ サーバが動作中の場合には、データベースの内容は、 ファイルシステム上とメモリ内に分散して存在します。 もし可能であれば、killnomosコマンドによってサーバを一旦終了し、 5.1の方法でバックアップを作成するのが簡単です。 が、もし、データベースを24時間利用可能な状態として運用させる必要があるなど、 バックアップのためにサーバを終了させたくない場合には、 以下のコマンドの実行によって、サーバを動作させたままでの バックアップや復旧を行うことができます。 ただし、利用者が接続中に動作中データの「復旧」の機能を行った場合には、 利用者のアクセス条件などの整合性が一時的に損なわれる危険があるので、 注意が必要です。 ※サーバ動作中バックアップのログファイルの扱いについて サーバー動作中バックアップコマンドを実行した場合には、 access_log,session_logなどのログファイルは、 バックアップ先のライブラリへはコピーされません。 また、復旧動作時に、バックアップ元にログファイルがあったとしても、 現在動作中のサーバのログと融合されたり、上書きされることはなく、 復旧前のログがそのまま残ります。 ログファイルの保存を行いたい場合には、 ファイルシステム上でcpをしてください。 ・saveObject ポート番号 バックアップ先ライブラリ名 このコマンドを実行すると、 このポートで起動中のライブラリの内容が、 バックアップ先ライブラリに複製され、保存されます。 このとき、バックアップ先ライブラリとして、 すでに存在しているライブラリを指定した場合には、 以前のライブラリの内容の上に上書きしてバックアップを作成します。 まだ存在していないライブラリを指定した場合には、 ライブラリを自動的に新規作成し、バックアップを作成します。 ・loadObject ポート番号 バックアップライブラリ名 このコマンドを実行すると、 このポートで起動中のライブラリの内容を、 バックアップライブラリとして指定した ディレクトリの内容で上書きします。 5.3 バックアップライブラリ名のルール バックアップに関するここまでの機能の注意点は、 バックアップ対象ライブラリと、バックアップ先ライブラリは、 サーバプロセスにとっては、名前が異なっているだけの、 「独立した(independentな)」2つのライブラリであることです。 つまり、バックアップ対象ライブラリとバックアップ先ライブラリとを 関連づける情報を記録する作業は、データベース管理者の責任として残されています。 あるライブラリのバックアップをどんな名前で保存するかや、 ある名前のライブラリはどのライブラリのバックアップであるのかといった ルールや方針は、データベース管理者が自らを決めなければいけません。 ここでは、バックアップライブラリの名前のつけ方によって、 「バックアップ対象としたライブラリはどれか」と 「バックアップした日時はいつか」を保存する例を示します。 例：バックアップライブラリ名：backup/cone/1997/09/15/132500 バックアップ対象としたライブラリ : cone バックアップした日時 ： 1997年9月15日13時25分00秒 なお、動作中のサーバに対して、 saveBackup 7001 backup/cone というように実行すると、 バックアップを実行した日付に従って、自動的にユニークなライブラリ名が付けられ、 時間的推移にあわせて整理しながら、データベース状態の保存ができます。 ※しかし、次節で解説するように、saveBackupは情報が冗長であり、 バックアップが蓄積する速度が速いものなので、 savePackedBackupコマンドを利用することをすすめます。 ※なお、以下では、この saveBackup系コマンドによって指定した 'backup/cone'のことを、「バックアップアーカイブ名」と呼びます。 参考：saveBackup コマンドの内部的な動作 バックアップを実行した日付に従って、ライブラリ名を backup/cone/西暦4桁/月2桁/日2桁/時2桁分2桁秒2桁 の形にしてsaveObjectを実行する。 rm -f backup/cone/current ln -s backup/cone/西暦4桁/月2桁/日2桁/時2桁分2桁秒2桁 backup/cone/current を行う。 5.4 バックアップ情報の差分圧縮 ここまでに示したバックアップ方法によって作成されたバックアップ情報は、 ひとつひとつがデータベースライブラリ1つ分と同じ内容を持つために、 それぞれを普通にバックアップを行ったとすると、それらを蓄積した量は たいへん大きなものになってしまいます。 しかし、ひとつひとつのバックアップ情報を比べると、 バックアップ内容にはかなりの冗長性があることが分かります。 そこで、複数のバックアップ情報の間での差分を取り、 情報を圧縮してアーカイブ化することで、バックアップの総量を 減らすような工夫をします。 参考：savePackedBackup コマンドの内部的な動作 *********************************未実装 savePackedBackup ポート番号 バックアップ対象ライブラリ バックアップアーカイブ1 バックアップアーカイブ2 ... 例： savePackedBackup 7001 cone backup/local/cone backup/MOdisk/cone backup/remoteServer/cone このコマンドを定期的に実行することだけで、 バックアップ体制を作ることができます。 バックアップアーカイブを複数指定することで、 複数のバックアップアーカイブに同時に情報を書き込むことができます。 参考：diffLibについて ライブラリ間の差分をファイル化するコマンド。 diffLibコマンドは内部的なコマンドであり、データベース管理者が 直接実行する必要は通常はありません。 diffLib 今回保存するライブラリ 前回保存したライブラリ バックアップの差分ファイル1 ※ (新) - (旧) = (差分) と考えてください。 参考：savePackedBackupの内部的な動作 ・もし前回バックアップしたライブラリが残っていれば、 そのライブラリの名前を得る。 ・今回のバックアップを作成する。 saveObject ポート番号 今回のバックアップ先ライブラリ ・もし前回のバックアップが存在すれば次へ。存在しなければ終了。 ・今回のバックアップ差分ファイルを作成し、保存する。 diffLib 今回のバックアップ先ライブラリ 前回のライブラリ バックアップの差分 ・今回のバックアップ差分ファイルを、必要な数だけ複製して保存する。 ・前回バックアップしたライブラリを削除する。 rm -rf 前回バックアップしたライブラリ 5.5 圧縮されたバックアップ情報の復帰 savePackedBackup コマンドによって保存されたバックアップアーカイブは、 そのsavePackedBackup コマンド実行の各時点におけるライブラリの状態を とりだして復帰させることができます。 *********************************未実装 retrivePackedBackup 復帰対象ライブラリ バックアップアーカイブ このコマンドの実行により、 バックアップアーカイブ内の最新のライブラリ情報で、 復帰対象ライブラリ内のファイルが書き直されます。 retrivePackedBackup -c 10 復帰対象ライブラリ バックアップアーカイブ というように指定すれば、10回分遡ってライブラリを復帰させることができます。 5.6 いつ・どうやってバックアップすべきか UNIXには、cronという定期的なコマンド実行基盤があります。 データベースを日常的にバックアップする作業を手動で行うのでは、 手間がかかる上に、バックアップ頻度を高くすることも難しいものです。 そこで、このcronコマンドを利用してバックアップを自動化します。 具体的には、データ内容の更新頻度によってバックアップ間隔を決定し、 利用者の少ない時間を選んで、バックアップ用バックアップ用コマンドを 自動実行するように、crontabと呼ばれる設定ファイルを記述します。 こうして、定期的に savePackedBackup ポート番号 今回保存するライブラリ バックアップアーカイブ名 を実行させることができます。 このとき、バックアップ先ライブラリ名は、 バックアップするライブラリ名、日付や時間などを利用することで、 毎回のバックアップごとにユニークになるように指定する必要があります。 なお、cronの設定の仕方については、 OS添付のマニュアルを参照してください。 例：SYS/V系のシステムでのcronの設定 # MIN HOUR DAY MONTH DAYOFWEEK COMMAND 0 6 * * * /home/nomos/bin/savePackedBackup 7001 cone backup/cone というファイルをnomos.cronというファイル名で作成し、 contab nomos.cron というコマンドを実行してください。 この例では、毎月/毎日/毎曜日の午前6:00に、 /home/nomos/bin/savePackedBackup 7001 cone backup/cone というコマンドを自動的に実行します。 5.7 バックアップ経路の構築とバックアップ先デバイスの選定 一般に、バックアップ元とバックアップ先の2つのライブラリを、 同一の物理ハードディスクドライブに保存することは、 本来の意味でのバックアップ用途としては、あまり意味がありません。 ハードディスク装置が衝撃や磨耗などで破損する際には、 物理的なハードディスクドライブ単位で使用不能になることが 多いためです。 より大規模なトラブルとしては、 重大な電源障害の際には、同一の電源系統上のマシンと周辺機器の全部が 破損する可能性があります。あるいは、地震や火災などの場合には、 あるフロアー全体、また屋舎全体が被害にあうことも想定されます。 以上のような様々なリスクを考慮すると、 バックアップはできるだけ複数の場所に、 様々な距離関係で保存することが重要であることがわかります。 こうしたトラブルに備えたデータベースのシステム構築例を示します。 この例の利点は、一旦「バックアップ経路の構築」を、 ハードウェア的・制度的に行っておけば、 ソフトウェア的には「バックアップ先デバイスの選定」のみによって 運用が可能となり、最小の運用コストによって最大限の対障害性が得られることです。 データベースサーバマシン ---------------------- ＜データベース＞ [ 内蔵ハードディスク内 ] 1次バックアップ [ ] ↓ ~~~~~~~~~~~~~|~~~~~~||~~ ↓ | || SCSI 2次バックアップ--- | =========[ 外付けMOディスクドライブ内 ] ↓ ↓ | ↓ ↓ | ↓ ↓ |network ↓ ↓ | 3次バックアップ ↓ [ ネットワーク経由の ] ↓ [ 別マシン上のハードディスクドライブ内 ] ↓ ↓ MOディスクを遠隔地で保存。 1次バックアップ: 内蔵ハードディスク上。 データベース本体のあるデバイスと物理的に同じデバイスに格納。 2次バックアップ: 外づけMOディスクドライブ上。 データベース本体のあるデバイスと物理的に異なるデバイスに格納。 ※MO上のパーティションにバックアップ用のディレクトリを作っておき、 $NOMOS/lib/以下にシンボリックリンクをする。 バックアップ先ライブラリ名として、このリンク以下を指定する。 3次バックアップ: NFS等でマウントしたネットワークドライブ上。 データベース本体のあるマシンと物理的に異なるマシンに格納。 ※ネットワークドライブ上のパーティションに、 バックアップ用のディレクトリを作っておき、 $NOMOS/lib/以下にシンボリックリンクをする。 バックアップ先ライブラリ名として、このリンク以下を指定する。 具体的なバックアップシステムのソフトウェア的な手順としては、 # MIN HOUR DAY MONTH DAYOFWEEK COMMAND 0 6 * * * /home/nomos/bin/savePackedBackup 7001 cone backup/local/cone backup/MOdisk/cone backup/remoteServer/cone のようにします。 ---------------------------------------------------------------- 6. データベースの障害復旧 ---------------------------------------------------------------- nomosサーバは、 クライアントとの間のトランザクションログを保存しているので、 障害復旧を論理的に可能にするのに十分な情報が保存できます。 recoverClient.pl ポート番号 復旧用ライブラリ このコマンドの実行により、 「復旧用ライブラリ」内のトランザクションログを利用して、 「ポート番号」で動作中のサーバに対して、 一連のインスタンスの登録・削除要求のセッションが行なわれ、 データベースの復旧がなされます。 ※この障害復旧機能を利用した場合には、 オブジェクトのリソース(作成者、更新者、更新日付)の 復旧については行なわれません。