Sun Java System Calendar Server 6 2005Q4 管理ガイド

データベース問題の処理

ここでは、Calendar Server データベースに関するさまざまな問題について説明します。

Berkeley データベースのツールの検索

多くのトラブルシューティングの手順では、Berkeley データベースのユーティリティープログラムへのアクセス権が必要です。これらのユーティリティープログラムは、Calendar Server バンドルで入手できますが、これらのプログラムはサポートされていません。詳細は、直接 Sleepycat Software (http://www.sleepycat.com) から入手できます。

ここで説明する内容は次のとおりです。

Berkeley データベースユーティリティーにアクセスするには

LD_LIBRARY_PATH 環境変数を設定してエクスポートし、次のディレクトリに反映させます。

cal_svr_base/SUNWics5/cal/tools/unsupported/bin/

使用可能なツールの一覧

次の表は、よく使用される Berkeley データベースのツール (ユーティリティープログラム) の一覧を示しています。

Berkeley データベースのツール	説明
`db_archive`	使用されなくなったログファイルのパス名を、標準出力に 1 行に 1 つずつ書き込みます。
`db_checkpoint`	データベースログを監視し、定期的にチェックポイントルーチンを呼び出して、チェックポイントを指定するデーモンプロセスです。
`db_deadlock`	データベース環境のロック領域をトラバースして、デッドロックまたはタイムアウトになっているロック要求を検出するたびに、ロック要求を中止します。
`db_dump`	指定したファイルを、`db_load` ユーティリティーが理解するフラットテキスト形式で標準出力に書き込みます。
`db_load`	標準出力から読み込み、指定したデータベースファイルにロードします。ファイルが存在しない場合は、ファイルを作成します。
`db_printlog`	人間が読める形式でログファイルをダンプするデバッグユーティリティーです。
`db_recover`	予期しないアプリケーション、データベース、またはシステムの障害が発生したあと、データベースを整合性のある状態に復元します。
`db_stat`	データベース環境の統計情報を表示します。
`db_verify`	1 つ以上のファイルおよびファイル内に含まれるデータベースの構造を検証します。

データベースのデッドロックを検出して解決するには

Berkeley データベースがデッドロック状態にある場合は、データベースをリセットする必要があります。できるだけ早期にこの状態を検出することが重要です。

システムが定期的にデータベースをチェックして、デッドロック状態を検出し、管理者に通知するようにするには、次のように実行します。

手順

設定を変更する権限を持つ管理者としてログインします。

/etc/opt/SUNWics5/cal/config ディレクトリに移動します。

古い ics.conf ファイルをコピーして名前を変更し、保存します。

必要に応じて、ics.conf ファイルを編集して次の値を設定します。

local.caldb.deadlock.autodetect=”yes”

注 –
このパラメータが “yes” に設定されている場合は、ロック領域を監視する db_deadlock デーモンが起動されます。

データベースの破損の検出

カレンダデータベースは、システムリソースの競合、ハードウェアの障害、アプリケーションエラー、データベース障害、人為的な原因など、さまざまな原因で破損することがあります。ここでは、カレンダデータベースの破損を検出する方法について説明します。

データベース破損の基本的考え方

データベースが破損しないとだれにも保証はできません。ですが、データの損失と運用停止時間を最小限にとどめることができます。破損を早期に検出するには、厳密にデータベースおよびカレンダサービスを監視することが重要です。頻繁に完全なバックアップを行っておくことが、破損が検出された場合に復元する秘訣です。

カレンダデータベースで起こりうる破損には、2 つのレベルがあります。

アプリケーションレベル: 1 つ以上のデータベースファイルのエントリに問題があると、それらを基にしている場合、サーバーが稼動しなくなります。
データベースレベル: Berkeley データベースのページが破損すると、さまざまな問題が発生します。一般的な症状は、csdb check を実行するとループすることです。もう一つの一般的な症状は、次のようなエラーメッセージが表示されることです。
```
“illegal page type or format”, 
or “page 97895 doesn’t exist, create flag not set.”
```

ログファイルの監視

データベース破損の兆候を示すエラーメッセージについて、アラームログを含む Calendar Server ログファイルを監視します。ログファイルについては、「Calendar Server ログファイルの使用」を参照してください。

ALERT、CRITICAL、ERROR、および WARNING レベルのエラーについて、ログファイルを定期的に調べてください。これらのエラーが見つかったときは、Calendar Server の動作で考えられる問題について調査します。NOTICE および INFORMATION レベルのログ予定は、Calendar Server の通常動作中に生成されることがあります。これは、サーバーアクティビティの監視に役立つように提供されています。

データベースディレクトリ内のトランザクションログファイルを削除しないでください。トランザクションログファイルにはトランザクションの更新 (追加、変更、削除) が記録されており、これを削除すると復元できない状態にまでカレンダデータベースが破損してしまうことがあります。

注 –

Calendar Server に関するテクニカルサポートを依頼する場合、問題解決のためにログファイルの提出が必要となることがあります。

csmonitor の使用

Calendar Server を監視するには、csmonitor ユーティリティーを使用します。このユーティリティーは、複数のトランザクションログファイルの発生や、カレンダデータベースのディスク容量の不足などの問題が生じた時点で、管理者に電子メールを送信するようにします。詳細は、「csmonitor」を参照してください。

カレンダデータベースの破損をチェックするには

カレンダプロパティー (calprops)、予定、および仕事 (作業) を含め、カレンダデータベースを走査して破損がないかどうか調べるには、check コマンドを使用します。check コマンドにより回復不能な不整合が検出された場合、その状況がレポートとして出力されます。

check コマンドは、アラームまたは GSE (グループスケジューリングエンジン) データベースの破損をチェックしません。

手順

Calendar Server がインストールされているシステムの管理権限を持つユーザーとしてログインします。

Calendar Server は稼動中でも停止していてもかまいませんが、可能であれば停止してください。

カレンダデータベースのコピーをまだ作成していない場合は、コピーを作成します。

データベース (.db) ファイルだけをコピーします。共有ファイル (__db.*) やログファイル (log.*) をコピーする必要はありません。

cal_svr_base/SUNWics5/cal/sbin ディレクトリに移動します。

たとえば、Solaris オペレーティングシステムでは、デフォルトのディレクトリには次のように入力します。
cd /opt/SUNWics5/cal/sbin

カレンダデータベースのコピーに対して check コマンドを実行します。
./csdb check dbdir /tmp/check.out
dbdir を指定しない場合、現在のディレクトリに格納されているデータベースに対して check が実行されます。

check コマンドは大量の情報を生成する可能性があるため、この例で示すように stdout や stderr を含むすべての出力をファイルとして書き出すことをお勧めします。

check の実行が完了したら、出力ファイルを確認します。データベースが破損していた場合は、rebuild コマンドを実行します。

「破損したカレンダデータベースの再構築」を参照してください。

データベース破損時のサービス停止の防止 (読み取り専用モード)

ここでは、リカバリモードの間も破損したデータベースにアクセスできる方法について説明します。ここで説明する内容は次のとおりです。

読み取り専用モードの使用

データベースの破損が見つかった場合、サービスの停止を防ぐ 1 つの方法は、データベースを読み取り専用モードにすることです。このモードでは、エンドユーザーはデータベースのエントリを読むことはできますが、追加、変更、または削除はできません。エンドユーザーがカレンダデータを追加、変更、または削除しようとすると、システムによりエラーメッセージが表示されます。また、カレンダの予定および仕事を追加、変更、または削除する管理者ツールも、データベースが読み取り専用モードの間は機能しません。

注 –

データベースを読み取ることができないほど破損している場合は、バックアップを復元するまでの間、サービスを停止する必要があります。バックアップを復元する最短の方法は、有効なホットバックアップを取ることです。「復元する前に」を参照してください。

データベースを読み取り専用モードにするには

手順

必要がなくても、カレンダサービスを一時的に停止して、データベースがさらに破損するのを防ぐ場合もあります。

カレンダダービスを停止するには、次のようにように実行します。

cal_svr_base/SUNWics5/cal/sbin/stop-cal

コマンド行で、ics.conf が格納されているディレクトリに移動します。

cd /etc/opt/SUNWics5/config

カレンダデータベースに対して読み取り専用モードを指定します。

caldb.berkeleydb.readonly=”yes”

ics.conf ファイルの編集が終わったら、Calendar Server を再起動します。

cal_svr_base /SUNWics5/cal/sbin/start-cal

ics.conf の変更を有効にするには、サービスを再起動する必要があります。

一般的なデータベース障害の処理

ここでは、いくつかの一般的なデータベース障害と、推奨する対応策について説明します。ここで説明する内容は次のとおりです。

csadmind が起動しない、または起動時にクラッシュする

csadmind では GSE (グループスケジューリングエンジン) とアラームディスパッチエンジンの両方のサービスを処理するため、GSE キュー内、またはアラームキュー内のエントリに問題があると、これらの問題が発生する可能性があります。

対応策

手順

csadmind が稼動していない場合は、すぐに stop-cal を実行します。

カレンダサービスを稼動したままにしておくと、トランザクションログが累積し、それが原因でデータベースがさらに破損して、トランザクションログファイルとデータベースを照合するのに時間がかかる場合があります。

csadmind の再起動を試みます (start-cal の再実行)。

正常に起動したら、次のようにして 2 つのキューが機能していることを確認します。
1. csschedule を使用して、GSE キューをチェックします。
2. dbrig を使用して、アラームキューをチェックします。
  
  csschedule および dbrig の実行方法については、付録 D 「Calendar Server のコマンド行ユーティリティーのリファレンス」を参照してください。

csadmind がダンプでクラッシュした場合は、pstack を分析します。

トレースに GSE に関連した機能がある場合は (中に GSE の文字がある)、GSE キューの最初のエントリおよび予定データベースの参照エントリを調べます。ほとんどの場合、GSE エントリで参照されている予定が、問題を起こしているエントリです。この問題を解決するには次を実行します。
1. csschedule を使用して、GSE エントリを削除します。
2. cscomponents を使用して、問題を起こしている予定をデータベースから削除します。
  
  csschedule および cscomponents の実行方法については、付録 D 「Calendar Server のコマンド行ユーティリティーのリファレンス」を参照してください。

エントリが破損していない場合は、カレンダサーバーでは処理できない特殊な例の可能性があります。

次の手順を実行します。
1. 破損したデータベースのカレンダ環境のスナップショットを取り、カスタマサポートに問い合わせます。
  
  環境のバックアップを作成するには、次のように実行します。
  1. 次の場所にある db_checkpoint ユーティリティーを使用します。
    
    cal_svr_base/SUNWics5/cal/tools/unsupported/bin/db_checkpoint
  2. db_archive -s を実行します。
    
    -s オプションを使用して、すべてのデータベースファイルを識別し、それらを CD、DVD、テープなどのリムーバブルメディアにコピーします。
  3. db_archive -l を実行します。
    
    -l オプションを使用して、すべてのログファイルを識別し、使用されていないファイルをリムーバブルメディアデバイスにコピーします。
2. サービスの停止を避けるには、カレンダデータベースを一時的に読み取り専用の状態にして、ホットバックアップのコピーに戻ります。
  - カレンダデータベースを一時的に読み取り専用の状態にすると、トランザクションの追加、変更、または削除はできなくなります。エンドユーザーがカレンダデータを追加、変更、または削除しようとすると、エラーメッセージが表示されます。カレンダの予定および仕事を追加、変更、または削除する管理者ツールも、データベースが読み取り専用モードの間は機能しません。
    
    カレンダデータベースを読み取り専用モードにするには、ics.conf ファイルを編集して、次のパラメータを “yes” に設定します。
    
    caldb.berkeleydb.readonly=”yes”
  - 「自動バックアップコピーの復元」にある手順を使用して、ホットバックアップコピーに戻ります。
    
    csstored を設定して有効にすると、ホットバックアップが使用可能になり、数分以内に最新の状態になります。また、常にホットバックアップコピーを検証して、破損していないことを確認するとよいでしょう。その場合は、db_verify を実行します。

ほかの方法がすべて失敗した場合、ダンプと再ロードの手順を実行して、データベースを修復できるかどうか確認します。

この手順は、「ダンプとロードによるカレンダデータベースの復元」で説明しています。

サービスがハングし、エンドユーザーが接続できない: 親のないロック

この状態は、制御スレッドが原因で発生する場合があります。これは Berkeley DB データベースのページをロックし、ロックを解除しないで終了します。この問題を確認するには、cshttpd プロセスおよび csadmind 上で pstack を実行します。pstack は標準 UNIX ユーティリティーで、次の場所に格納されています。/usr/bin/pstack。このユーティリティーにより、ロックを獲得するために待機しているスレッドが表示されます。

問題を解決するには、次のようにして Calendar Server を再起動します。

手順

start-cal が存在するディレクトリに移動します。

cd cal_svr_base/SUNWics5/cal/sbin

start-cal コマンドを実行します。

./start-cal

csdb rebuild が終了しない: データベースのループ

データベースのループは、通常、データベースファイルの破損により起こります。データベースが破損しているため、回復不能になる可能性があります。次のいくつかの選択肢があります。

手順

ホットバックアップに戻ります。

破損が最近起こったのであれば、いずれかのホットバックアップコピーを使用できます。

壊滅的アーカイブのリカバリプロセスを使用します。

推奨されるプロセスについては、「自動バックアップコピーの復元」を参照してください。

ダンプと再ロードの手順を使用します。「ダンプとロードによるカレンダデータベースの復元」を参照してください。

破損したカレンダデータベースの再構築

ここでは、csdb rebuild コマンドの使用方法について説明します。ここで説明する内容は次のとおりです。

rebuild の概要

rebuild コマンドはカレンダデータベースを走査し、カレンダプロパティー (calprops) の予定と仕事 (作業) をチェックして破損がないかどうかを調べます。不整合を検出すると、rebuild コマンドは再構築したカレンダデータベース (.db ファイル) を cal_svr_base /SUNWics5/cal/sbin/rebuild_db ディレクトリに生成します。

-g オプションを指定せずに rebuild コマンドを実行すると、GSE (グループスケジューリングエンジン) データベース以外のすべてのデータベースが再構築されます。GSE データベースも再構築するときは、-g オプションを指定します。

GSE データベースにエントリが含まれているかどうかを調べるには、csschedule -v list コマンドを実行します。GSE がすべてのエントリの処理を完了してから rebuild コマンドを実行してください。

カレンダデータベースを再構築するには

手順

Calendar Server がインストールされているシステムの管理権限を持つユーザーとしてログインします。

Calendar Server を停止します。

カレンダデータベースのコピーを作成し、/tmp/db ディレクトリに置きます。

データベース (.db) ファイルとログ (log.*) ファイルをコピーします。共有ファイル (__db.*) をコピーする必要はありません。

cal_svr_base/SUNWics5/cal/sbin ディレクトリに移動します。

たとえば、Solaris オペレーティングシステムでは、デフォルトのディレクトリには次のように入力します。
cd /opt/SUNWics5/cal/sbin
注 –
sbin ディレクトリのディスク容量が問題となる場合は、別のディレクトリで rebuild コマンドを実行します。

カレンダデータベースのコピーに対して rebuild コマンドを実行します。
./csdb rebuild /tmp/db /tmp/
データベースパスを指定しない場合は、現在のディレクトリに対して rebuild が実行されます。/tmp/ パラメータは、再構築したデータベースの出力先ディレクトリを指定します。

GSE データベースも再構築するときは、-g オプションを指定します。

rebuild は大量の情報を生成する可能性があるため、stdout や stderr を含むすべての出力をファイルとして書き出すことをお勧めします。

注 –
カレンダデータベースを再構築するときは、常に最新のバックアップコピーを使用してください。

ただし、膨大なデータが失われ、データベースの定期バックアップで複数のコピーを利用できるときは、最新のコピーからもっとも古いコピーの順に再構築を行います。この方法の唯一の欠点は、すでに削除されているカレンダコンポーネントが再構築されたデータベースに再表示されることです。

たとえば、3 つのバックアップカレンダデータベースファイルが db_0601、db_0615、および db_0629 というディレクトリに格納されている場合は、次の順序で rebuild コマンドを実行します。
./csdb rebuild db_0629 ./csdb rebuild db_0615 ./csdb rebuild db_0601
次に、rebuild コマンドは再構築したデータベースを cal_svr_base/SUNWics5/cal/sbin/rebuild_db ディレクトリに書き込みます。

rebuild の実行が完了したら、rebuild.out ファイルを確認します。

再構築が正常に完了した場合、rebuild.out ファイルの最後の行は次のようになります。
Calendar database has been rebuilt

前の手順で再構築が正常に完了したことを確認したら、再構築したデータベースファイル (.db) を rebuild_db ディレクトリから運用データベースにコピーします。

破損したデータベースのディレクトリに共有ファイル (__db.*) やログファイル (log.*) が含まれていた場合は、それも運用ディレクトリに移動します。

Calendar Server を再起動します。

再構築出力のサンプル

次の例は、コマンドと、そのコマンドにより生成された出力を示しています。

# ./csdb -g rebuild
Building calprops based on component information.
Please be patient, this may take a while...
Scanning events database...
512 events scanned
Scanning todos database...
34 todos scanned
Scanning events database...
512 events scanned
Scanning todos database...
34 todos scanned
Scanning deletelog database...
15 deletelog entries scanned
Scanning gse database...
21 gse entries scanned
Scanning recurring database...
12 recurring entries scanned
Successful components db scan
Calendar database has been rebuilt
Building components based on calprops information.
Please be patient, this may take a while...
Scanning calprops database to uncover events...
25 calendars scanned
Scanning calprops database to uncover todos...
25 calendars scanned
Successful calprops db scan
Calendar database has been rebuilt

注 –

上記の出力サンプルでは、予定と仕事のデータベースがそれぞれ 2 回走査されたことを示しています。これはエラーではありません。最初の走査ではカレンダプロパティーデータベース内の情報を確認し、次に再走査して、カレンダプロパティーデータベースがアクセス可能であることを確認します。

ダンプとロードによるカレンダデータベースの復元

ここで説明する内容は次のとおりです。

ダンプとロードの概要

ダンプとロードの手順を使用して破損したデータベースの復元を試みます。ダンプとロードの手順では、Berkeley データベースの db_dump ユーティリティーと db_load ユーティリティーを使用します。Calendar Server では、これらのユーティリティーは次のディレクトリに格納されています。

cal_svr_base/SUNWics5/cal/tools/unsupported/bin

db_dump ユーティリティーはデータベースファイルを読み取り、エントリを db_load ユーティリティーと互換性のある形式で出力ファイルに書き込みます。

db_dump ユーティリティーと db_load ユーティリティーのマニュアルについては、次の Sleepycat Software の Web サイトを参照してください。

http://www.sleepycat.com/docs/utility/index.html

db_dump と db_load によるデータベースの復元が成功するかどうかは、データベースの破損具合によって決まります。データベースを復元するまでに、db_dump オプションを何度か実行しなければならないこともあります。ただし、破損が著しいデータベースは復元できません。この場合は、データベースの最終ホットバックアップまたはアーカイブを使用する必要があります。

注 –

ダンプとロードの手順を実行するときは、カレンダデータベースが Berkeley DB バージョン 3.2.9 以上である必要があります。それ以前のバージョンを使用している場合は、最初に cs5migrate ユーティリティーを使用してカレンダデータベースをアップグレードしてください。

最新バージョンの cs5migrate については、ご購入先のテクニカルサポートに問い合わせてください。

ダンプとロードの手順を実行するには

手順

Calendar Server を実行するユーザーやグループ (icsuser と icsgroup など)、またはスーパーユーザー (root) としてログインします。

Calendar Server が停止していなければ、停止します。

csbackup ユーティリティーや Sun StorEdge Enterprise Backup^TM ソフトウェア、Legato Networker® などを使用して、破損しているデータベースのバックアップを作成します。

詳細は、第 17 章「Calendar Server データのバックアップと復元」を参照してください。

db_dump ユーティリティーを使用して、破損しているデータベースの各ファイルをダンプします。

データベースファイルは、ics50calprops.db、ics50journals.db、ics50alarms.db、ics50events.db、ics50todos.db、および ics50gse.db です。

データベースが復元されるまで (または復元不可能であると判断されるまで)、次のオプションを順に指定して db_dump を実行します。
- オプションなし: 軽度のデータベース破損。
- -r オプション: 中度のデータベース破損。
- -R オプション: 重度のデータベース破損。-R オプションを指定した場合、破損しているデータベースから、部分的なレコードや削除されたレコードなども含め、-r オプションを指定した場合より多くのデータがダンプされます。
  
  たとえば、-r オプションを指定して db_dump を実行するときは、次のように入力します。
  db_dump -r ics50events.db \> ics50events.db.txt

db_load ユーティリティーを使用して、出力ファイルを新しいデータベースファイルにロードします。

次に例を示します。
db_load new.ics50events.db < ics50events.db.txt
db_load が奇数のキーまたはデータエントリをレポートする場合は、db_dump 出力ファイルを編集して、異常のあるキーまたはデータエントリを削除します。次に、db_load を再実行します。

破損しているその他のデータベースファイルに対して、前の 2 つの手順を繰り返します。

つまり、破損しているその他のデータベースファイルに対して db_dump を実行します。

「破損したカレンダデータベースの再構築」で説明している csdb rebuild コマンドを使用して、復元したデータベースファイルを再構築します。

rebuild の実行が完了したら、出力ファイルを確認します。再構築が正常に完了した場合、rebuild.out ファイルの最後の行は次のようになります。
Calendar database has been rebuilt
csdb rebuild コマンドが正常に終了しなかった場合は、次レベルの db_dump オプション (-r または -R) を使用してデータベースのダンプを行います。

db_dump -R オプションを実行しても破損しているデータベースを復元できない場合は、ご購入先のテクニカルサポートまたは販売代理店までご連絡ください。それまでの間は、データベースの最終バックアップを使用する必要があります。

自動バックアップコピーの復元

第 10 章「自動バックアップ (csstored) の設定」で説明されている自動バックアップ機能を使用している場合、ライブデータベースが破損したときにバックアップコピーを復元できます。

ここでは、2 つの異なる自動バックアップの復元方法について説明します。

復元する前に

バックアップを復元する前に、必ず次の操作を行っていることを確認してください。

どのトランザクションがライブデータベースの破損の原因になったか診断を試みていること。
新規のアーカイブが破損されないように、破損しているトランザクションを削除または修正していること。
破損したデータベースを、別のディレクトリまたはリムーバブルメディアにコピーして保存していること。このコピーは、テクニカルサポートに問い合わせを行う際に必要になります。

ホットバックアップを復元するには

ライブデータベースが破損した場合は、ホットバックアップがバックアップの最初の選択肢となります。バックアップを復元するには、次の手順を実行します。

手順

破損したライブデータベースのディレクトリで、適用されていない、または書き込み可能な状態のログファイルを識別します。

書き込み可能なログを閉じます。このログには、最新のトランザクションが含まれています。

新規の (復元) ディレクトリを作成します。

現在のホットバックアップのコピーを、新規の復元データベースのディレクトリにコピーします。

log.* ファイルを、破損したライブデータベースのディレィトリから、新規の復元データベースのディレクトリにコピーします。

データベースのアーカイブコピーを保持している場合は、ライブデータベースに適用されなかったログをアーカイブディレクトリにコピーします。

新規の復元データベースに対して指定された -c -h オプションを指定して、db_recover を実行します。

たとえば、新規の復元ディレクトリの名前が recoverydb の場合、コマンドは次のようになります。

db_recover -c -h recoverydb

log.* ファイルは、新規のディレクトリに残しておきます。

db_recover プログラムではログファイルを新規の復元データベースに適用しましたが、バージョン 4.2 以降、Berkeley DB ではログファイルをそのまま残しておくことを勧めします。

新規の復元ディレクトリ内のデータベースファイルに対して、db_verify を実行します。

手順については、「カレンダデータベースの破損をチェックするには」を参照してください。

新規の復元ディレクトリに対して、csdb -v list を実行します。

新規の復元ディレクトリで上記の 3 つの手順を実行したら、古い破損したライブデータベースを新規の復元ディレクトリと置き換えます。

新しいスナップショットとして機能させるために、新規のライブデータベースをホットバックアップのディレクトリにコピーします。

次の定期的なスナップショットが取得されるまで、すべての新しいログがこのコピーに適用されます。

Calendar Server を起動します。

新規の復元ディレクトリでいずれかの手順に失敗した場合は、次のようにして破損していない古いホットバックアップを特定します。
1. ホットバックアップを新しい順から逆にたどり、各ファイルに対して順番に db_verify および csdb -v list を実行して、破損していない最新のコピーを見つけます。
2. パスする最初のホットバックアップコピーが、ライブデータベースのディレクトリに復元されます。
  
  「ホットバックアップを復元するには」で説明している手順に従い、破損したライブデータベースを新規のホットバックアップと置き換えます。最初に、必ず「復元する前に」をお読みください。
3. ホットバックアップがどれも動作せず、アーカイブバックアップがない場合は、テクニカルサポートに問い合わせてください。アーカイブバックアップがある場合は、「アーカイブバックアップを復元するには」にある手順を実行します。「復元する前に」も参照してください。

アーカイブバックアップを復元するには

破損したホットバックアップはないが、アーカイブバックアップとトランザクションログがある場合は、次の手順を実行して、アーカイブしたデータベースの最新の破損していないデータベースを復元できます。

手順

破損したライブデータベースのディレクトリで、適用されていない、または書き込み可能な状態のログファイルを識別します。

書き込み可能なログを閉じます。このログには、最新のトランザクションが含まれています。

新規の (復元) ディレクトリを作成します。

最新のアーカイブコピーとそのログファイルを、新規の復元データベースのディレクトリにコピーします。

適用されていない log.* ファイルを、破損したライブデータベースのディレクトリから、新規の復元データベースのディレクトリにコピーします。

新規の復元データベースに対して指定された -c -h オプションを指定して、db_recover を実行します。

たとえば、新規の復元ディレクトリの名前が recoverydb の場合、コマンドは次のようになります。

db_recover -c -h recoverydb

log.* ファイルは、新規の復元ディレクトリに残しておきます。

db_recover プログラムではログファイルを新規の復元データベースに適用しましたが、バージョン 4.2 以降、Berkeley DB ではログファイルをそのまま残しておくことを勧めします。

新規の復元ディレクトリ内のデータベースファイルに対して、db_verify を実行します。

手順については、「カレンダデータベースの破損をチェックするには」を参照してください。

新規の復元ディレクトリに対して、csdb -v list を実行します。

新規の復元ディレクトリで上記の 3 つの手順を実行したら、古い破損したライブデータベースを新規の復元ディレクトリと置き換えます。

新しいスナップショットとして機能させるために、新規のライブデータベースをホットバックアップのディレクトリにコピーします。

Calendar Server を起動します。

新規の復元ディレクトリがいずれかの手順に失敗した場合は、次のようにして破損していない古いアーカイブバックアップを特定します。
1. アーカイブバックアップのコピーを新しい順から逆に調べて、順に各ファイルに対して次の 3 つのリカバリプログラムを実行して、破損していない最新のコピーを見つけます。db_recover -c-h、db_verify、および csdb -v list。
2. パスする最初のアーカイブアップコピーが、ライブデータベースのディレクトリに復元されます。
  
  「アーカイブバックアップを復元するには」で説明している手順に従い、破損したライブデータベースを新規のアーカイブバックアップと置き換えます。
3. アーカイブバックアップがどれも動作しない場合は、テクニカルサポートに問い合わせてください。

カスタムのバックアップスクリプトの修復

ここで説明する内容は次のとおりです。

現在、動的ライブラリでコンパイルされている Berkeley ツール

カスタムバックアップスクリプトが Berkeley データベースのツール (db_recover など) を使用して作成されている場合は、Calendar Server にアップグレードすると、機能しなくなる可能性があります。これは、Calendar Server の以前のバージョンでは、ツールを静的ライブラリでコンパイルしていたためです。現在では、ツールは動的ライブラリの libdb-4.2.so でコンパイルされています。

カスタムのバックアップスクリプトを修復するには

既存のカスタムスクリプトで新しい動的ライブラリを使用するには、次に示す大域変数を設定します。

LD_LIBRARY_PATH=libdb-4.2.so