test

Sun Java System Calendar Server 6.3 管理ガイド

第 22 章 Calendar Server 6.3 ソフトウェアのトラブルシューティング

ここでは、ログの設定方法と、一般的な問題への対処方法について説明します。

この章の内容は、次のとおりです。

22.1 Calendar Server 6.3 ソフトウェアのデバッグ情報の有効化

ここでは、Calendar Server 配備でログおよびデバッグを使用して問題解決するうえでの概念情報を提供し、その手順について説明します。

システム全体を「デバッグモード」にする ics.conf パラメータはありませんが、ここでは有用なデバッグ情報を取得する方法について説明します。

注 –

パフォーマンスにマイナスの影響を与えるため、必要でない場合は、必ず、過度なログ記録および監視は無効にしてください。

22.1.1 ログレベルを上げる

次の表に示すパラメータを使用して、ログの詳細度を上げます。

パラメータ 

説明とデフォルト値 

logfile.loglevel

DEBUG に設定して、CRITICAL、ALERT、ERROR、WARNING、NOTICE、および INFORMATION を含む、すべてのレベルがログ記録されるようにします。この設定はすべてのログに適用されます。

22.1.2 LDAP キャッシュへのアクセスログの有効化

LDAP データキャッシュのすべてのアクセスをログに記録し、そのログ (レポート) を出力するには、次の表に示すics.conf パラメータを設定します。

パラメータ 

説明とデフォルト値 

local.ldap.cache.stat.enable

LDAP データキャッシュへのアクセスをログに記録し、ログファイルに統計情報を出力するかどうかを指定します。デフォルトは “no” です (統計情報はログ記録されない)。統計情報のログを有効にするには、“yes” に設定します。

パフォーマンス向上のために、このパラメータはデバッグモードでのみ使用してください。 

local.ldap.cache.stat.interval

統計情報レポートをログファイルに書き込む間隔を秒単位で指定します。デフォルトは “1800” 秒 (30 分) です。

これは、ログが有効になっている場合にのみアクティブになります。間隔を短くすると、問題を特定するのに役立ちます。間隔を長くすると、システムロードが減少します。 

22.1.3 LDAP キャッシュのクリア

現在、Calendar Server には LDAP キャッシュデータを失効させるためのロジックは存在しません。ldap_cache ディレクトリの内容を手動で削除し、Calendar Server を再起動する必要があります。

ProcedureLDAP キャッシュをクリアするには

  1. Calendar Server を停止します。

  2. /var/opt/SUNWics5/csdb/ldap_cache ディレクトリ内のファイルをすべて削除します。ただし、ldap_cache ディレクトリ自体は削除しないでください。

  3. Calendar Server を再起動します。

22.1.4 WCAP コマンドと HTTP アクセスログ

デバッグを簡便化する 2 つの構成パラメータにより、受信コマンドおよび HTTP アクセスのロギングが可能になります。ics.conf ファイルに、いずれかのパラメータ、または両方のパラメータを追加し、ロギングを有効にします。

注意 – 注意 –

ログファイルの容量はすぐに大きくなり、空きディスク領域が少なくなることがあります。問題を回避するため、ログファイルを注意深く監視する必要があります。これらのコマンドが有効になった状態で実行するには、システムの稼動レベルが低いときを選びます。ピーク時に実行すると、パフォーマンスが大幅に劣化します。トラブルシューティングが終了したら、これらのコマンドを必ず無効化してください。

22.1.5 Calendar Server 6.3 の csstats ユーティリティーを使用したシステム監視

counter.conf ファイルに定義されているカウンタオブジェクトからの統計情報を表示するには、csstats list コマンドを使用します。

cssats ユーティリティーについては、付録 D 「Calendar Server のコマンド行ユーティリティーのリファレンス」を参照してください。

22.2 LDAP の問題のトラブルシューティング

ここでは、LDAP の問題をトラブルシューティングするうえでの概念情報を提供します。

複数ドメイン環境を最初に作成する時に、ドメイン、コンテナ、ユーザー、グループ、リソースの適切なエントリを追加して、LDAP に DC ツリーを作成する必要があります。cscal などの Calendar Server のユーティリティーを使用するときに DC ツリーが存在しないと、次のようなエラーメッセージが表示される可能性があります。"Initialization failed .... exiting"

DC ツリーには、DC ツリーのルートに少なくとも 1 つの (デフォルト) ドメインが含まれていることを確認します。「13.2 新規の Calendar Server ドメインの作成」に記載されている方法を使用して DC ツリー構造を作成します。

22.3 移行ユーティリティーのトラブルシューティング

Calendar Server には、カレンダデータベースおよび LDAP ディレクトリを移行するためのいくつかのユーティリティーが用意されています。

ここでは、次の内容について説明します。

22.3.1 テクニカルサポートに問い合わせる前に必要なこと

一般的に、移行ユーティリティーの使用において問題が発生した場合は、テクニカルサポートに問い合わせてください。

問い合わせる前に、次の情報を集めます。

22.3.2 移行ユーティリティーの入手先

さまざまな移行ユーティリティーおよびそのマニュアルは、次の一覧に示す場所にあります。

スキーマ移行ユーティリティー (commdirmig)

このユーティリティーは、個別にインストール可能なコンポーネントである Delegated Administrator にバンドルされています。このユーティリティーは LDAP ディレクトリを Schema バージョン 1 から Schema バージョン 2 に移行します。このユーティリティーについては、『Sun Java Communications Suite 5 Schema Migration Guide 』を参照してください。

Calendar Server 6.2 から 6.3 への移行ユーティリティー csmigrate

このユーティリティーは、ソフトウェアのインストール後に sbin ディレクトリに格納されます。

Calendar Server 5 から Calendar Server 6.2 への移行ユーティリティー (cs5migrate)

このユーティリティーは、ソフトウェアのインストール後に sbin ディレクトリに格納されます。

Calendar Server の複数ドメインデータベースの準備ユーティリティー (csmig)

このユーティリティーは、ソフトウェアのインストール後に sbin ディレクトリに格納されます。

このユーティリティーのマニュアルは 第 3 章「Calendar Server 6.3 のデータベース移行ユーティリティー」にあります。これには、トラブルシューティングの節もあります。

Calendar Server の非ドメインから複数ドメインへの移行ユーティリティー (csvdmig)

このユーティリティーは、ソフトウェアのインストール後に sbin ディレクトリに格納されます。

このユーティリティーのマニュアルは、第 3 章「Calendar Server 6.3 のデータベース移行ユーティリティー」にあります。複数ドメイン用のカレンダデータベースおよび LDAP ディレクトリのエントリを準備するには、このユーティリティーを使用します。

注 –

csvdmig の前に csmig を実行してください。

Calendar Server 2 から Calendar Server 6 への移行ユーティリティー (ics2migrate)

このユーティリティーは Calendar Server にインストールされています。マニュアルは、第 3 章「Calendar Server 6.3 のデータベース移行ユーティリティー」にあります。Calendar Server 2 データベースを移行して Calendar Server 5 との互換性を持たせるには、このユーティリティーを使用します。

Netscape Calendar Server 4 から Calendar Server 5 への移行ユーティリティー (ncs4migrate)

このユーティリティーは、テクニカルサポートサイトからのみ入手できます。ユーティリティーパッケージにはマニュアルが含まれています。このユーティリティーは、Netscape Calendar Server 4 を Calendar Server 5 に移行します。移行元のデータベースが整合していないため、これらの移行には特に注意を要します。手動による多くの作業が必要になることも珍しくありません。このユーティリティーは、テクニカルサポートサイトからのみ入手できます。ユーティリティーパッケージにはマニュアルが含まれています。このユーティリティーは、Netscape Calendar Server 4 を Calendar Server 5 に移行します。これらの移行には特に注意を要します。ユーティリティーを実行できるようになるまでに、移行元のファイルに対して多くの作業が必要になることも珍しくありません。移行の計画をサポートする Professional Services を利用されることをお勧めします。

22.4 Calendar Server でのデータベース以外のトラブルシューティング

ここでは、データベース以外の問題のさまざまなトラブルシューティングについて説明します。

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

ヒント –

さらに、次の SSL の章にも、SSL に関するトラブルシューティングの節があります。

「7.2 Calendar Server 6.3 ソフトウェアの SSL のトラブルシューティング」

22.4.1 1 つの cshttpd プロセスが多数の接続を許可しており、CPU 時間を 100% 使用している

1 つの cshttpd プロセスが多数の接続を許可しており、CPU 時間を 100% 使用している場合は、負荷分散が無効になっていることがあります。負荷分散をふたたび有効にするには、ics.conf パラメータ service.http.loadbalancing の値を "yes" に変更します。

Procedurestart-cal の問題の解決

start-cal を実行したときに起動しないカレンダサービスがある場合は、再起動する前に起動したサービスを終了する必要があります。たとえば、enpd、csnotifyd、および csadmind が起動したが、cshttpd は起動していない場合、enpd、csnotifyd、および csadmind を停止する必要があります。

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

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

  2. stop-cal コマンドを実行します。

  3. stop-cal コマンドがすべての Calendar Server サービスを停止できなかった場合は、子プロセスのいくつかが実行中であることがあります。この場合の処理については、「22.4.2 stop-cal の問題の解決」を参照してください。

  4. すべての Calendar Server プロセスが確実に終了したあと、start-cal コマンドを実行してすべてのサービスを起動します。次に例を示します。

    cal-svr-base/SUNWics5/cal/sbin/start-cal

22.4.2 stop-cal の問題の解決

ここでは、stop-cal の問題を解決するうえでの概念情報を提供し、その手順について説明します。

Calendar Server のシャットダウン時には、考慮する必要がある 2 つの別個の問題があります。

Procedure子プロセスを停止するには

stop-cal を実行したあと、いくつかの子プロセスが停止していない場合があります。たとえば、stop-cal によって cshttpd 親プロセスは停止しているのに、一部の cshttpd 子プロセスが停止していないことがあります。このような場合は、次の手順で、残りの Calendar Server プロセスを個別に停止させる必要があります。

  1. Calendar Server が稼動しているシステムの管理権限を持つユーザーとしてログインします。

  2. サービスごとに ps コマンドを実行し、残っている Calendar Server プロセスのプロセス ID (PID) を特定します。

    ps -elf | grep cs-process

    ここで、cs-process は enpd、csnotifyd 、csdwpd、csadmind、または cshttpd です。次に例を示します。

    ps -elf | grep cshttpd

  3. kill -15 コマンドに終了していない各プロセスの PID を指定して、プロセスを終了します。次に例を示します。kill -15 9875

  4. それぞれの ps コマンドをもう一度実行し、すべての Calendar Server プロセスが終了していることを確認します。


    Calendar Server プロセスがまだ稼動しているときは、kill -9 コマンドを実行して終了します。例: kill -9 9875
    注 –

    Linux システムで Calendar Server を実行していて、ps コマンドを使用してカレンダプロセスを検索すると、結果がわかりにくく見えることがあります。Linux では、ps コマンドは、プロセスのリストではなく実行しているスレッドのリストを返します。プロセスだけが表示されるようにするための既知の解決策はありません。

Procedure不正シャットダウンしたあとで回復するには

Calendar Server が正しくシャットダウンしなかった場合は、次の手順を実行します。

  1. 前の手順 (「22.4.2 stop-cal の問題の解決」) を実行します。

  2. LDAP データキャッシュデータベースのディレクトリ内のすべてのファイルを手動で削除します。

    ファイルが残っていると、データベースが破損する可能性があります。ファイルを削除するには、次のように実行します。

    1. LDAP データキャッシュのディレクトリに移動します。

      デフォルトでは、/opt/SUNWics5/csdb/ldap_cache ですが、ics.conf ファイルの local.ldap.cache.homedir.path パラメータにより指定されるディレクトリを使用してください。

    2. ディレクトリ内のすべてのファイルを削除します。

      次に例を示します。rm *.*

    3. すべてのファイルが削除されたことを確認します。

      次に例を示します。ls

  3. Calendar Server を再起動します。

    cal-svr-base/SUNWics5/cal/sbin/start-cal

    LDAP データキャッシュの設定方法については、「4.8 Calendar Server バージョン 6.3 の LDAP の設定」を参照してください。LDAP データキャッシュについては、『Sun Java Communications Suite 5 配備計画ガイド』を参照してください。

22.4.3 バックエンドサーバーに接続できない

  1. 応答しているかどうか調べるには、バックエンドサーバーに対して ping を実行します。

    応答していない場合は、その原因を調べ、ふたたび動作するようになったら次の手順に進みます。

  2. CLD キャッシュをクリアします。「12.5 Calendar Server バージョン 6.3 での CLD キャッシュのクリア」を参照してください。

    CLD キャッシュオプションを使用していて、ics.conf パラメータのサーバー名を更新した場合は、CLD キャッシュをクリアしてサーバー名を消去するとよいでしょう。CLD キャッシュに古いエントリが残されていると、フロントエンドサーバーが正しいバックエンドサーバーに接続できなくなったり、Calendar Server が移動後のカレンダを見つけられなくなります。

  3. stop-cal コマンドでサーバーを停止します。

  4. start-cal を使用して Calendar Server を再起動します。

22.4.4 カレンダが見つからない

CLD キャッシュオプションを使用していて、1 つ以上のカレンダを別のバックエンドサーバーに移動した (または、バックエンドサーバーの名前を変更した) 場合は、新規サーバーのカレンダが表示されないことがあります。

    その場合は、次の手順を実行します。

  1. CLD キャッシュをクリアします。「12.5 Calendar Server バージョン 6.3 での CLD キャッシュのクリア」を参照してください。

    1 つ以上のカレンダを別のバックエンドサーバーに移動すると、CLD キャッシュは無効になります。再読み込みするには、キャッシュをクリアする必要があります。そうすると、キャッシュが再構築されます。

  2. これが失敗した場合は、正しい手順でカレンダを移動したかどうかを確認します。詳細は、

    「15.6 ユーザーカレンダの管理」を参照してください。

    その後、キャッシュをクリアします。

22.4.5 バックエンドマシンにカレンダを作成できない

指定したバックエンドマシンでカレンダを作成しようとすると、次のエラーメッセージが表示されます。Invalid DWP Host Server。この場合、原因は 2 つあります。サーバーが適切に設定されていないか、カレンダの所有者がすでに別のバックエンドサーバーに割り当てられています。

この節では、これら 2 つの問題の解決方法を説明します。

22.4.5.1 バックエンドマシンが適切に設定されていない

問題となっているバックエンドサーバーの ics.confファイルで、

次の設定があることを確認します。

service.dwp.enable = "yes"
caldb.cld.type = "directory"
local.hostname = "back-end hostname"

22.4.5.2 カレンダ所有者が別のバックエンドマシンに割り当てられている

ユーザーの LDAP エントリで、icsDWPHost 属性があることを確認します。icsDWPHost の値は、カレンダを作成しようとしているバックエンドサーバー名と一致する必要があります。このユーザーのカレンダを別のバックエンドサーバー上に作成することはできません。

22.4.6 プロキシ認証を使用してログインしようとすると「承認されていない」が表示される

この節では、失敗の原因として考えられるものについて説明します。示される手順を実行し、ログインを再試行します。

  1. この問題を解決するには、次のいずれかの手順を実行します。

    • service.http.allowadminproxy が “yes” に設定されていることを確認します。

    • admin-user に Calendar Server 管理者の権限があることを確認します。

    • admin-password が正しいことを確認します。

    • calendar-user が有効な Calendar Server ユーザーであることを確認します。

  2. ログインを再試行します。

22.4.7 正しく完了しない検索のトラブルシューティング

この節では、正しく完了しない検索のトラブルシューティングについての概念情報を提供し、その手順について説明します。

LDAP ディレクトリサーバー設定の nsslapd-sizelimit 属性と nsLookthroughLimit 属性は、検索が正しく終了するように十分なサイズに設定する必要があります。 nsSizeLimit が十分なサイズでない場合は、一部の結果が欠落したり、検索結果が表示されなくなることがあります。nsLookthroughLimit が十分なサイズでない場合、検索が完了しないことがあります。

この節の内容は、次のとおりです。

Procedure制限属性の値が適切かどうかを調べるには

  1. これらの属性に適切な値が設定されているかどうかを調べるには、次のコマンドを実行します。

    ldapsearch -b "base" "(&(icscalendarowned=*user*)(objectclass=icsCalendarUser))"

    ここで、base は、Calendar Server のユーザーとリソースのデータが格納されているディレクトリサーバーの LDAP ベース DN であり、user は、エンドユーザーがユーザーインタフェースの検索ダイアログで入力できる値です。

  2. LDAP サーバーがエラーを返す場合、nsSizeLimit または nsLookthroughLimit パラメータの値が十分でない可能性があります。

Procedure制限属性を適切な値に設定するには

これらの属性の DN は次のとおりです。

dn: cn=config,cn=ldbm databases,cn=plug ins,cn=config

  1. nsLookthroughLimit の値を動的に設定するには、ldapmodify を使用します。

    この属性を変更するために Directory Server を終了して再起動する必要はありません。

    デフォルト値は 5000 です。検索結果が表示されない場合、この値を大きくすることができます。ただし、そうすると LDAP サーバーのパフォーマンスが低下します。

    制限を -1 に設定して、制限の適用を解除することもできます。ただし、システムがハングすることが想定されるため、慎重に行なってください。

  2. nsslapd-sizelimit をより高い値に設定する場合は、次の手順を実行する必要があります。

    1. ディレクトリサーバーを停止します。

    2. dse.ldif ファイルを編集します。

    3. ディレクトリサーバーを再起動します。

      注 –

      ldapmodify の使用方法および dse.ldif ファイルの編集方法については、次の Web サイトで入手できる Directory Server のマニュアルを参照してください。

      http://docs.sun.com/coll/1316.1

22.5 Calendar Server のデータベースの問題への対処

この節では、Calendar Server (Berkeley データベース) データベースに伴うさまざまな問題について解説します。

ここでは、次の内容について説明します。

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

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

ここでは、次の内容について説明します。

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

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

cal-svr-base/SUNWics5/cal/tools/unsupported/bin/

22.5.1.2 使用可能なツールの一覧

次の表は、よく使用される 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 つ以上のファイルおよびファイル内に含まれるデータベースの構造を検証します。 

Procedureデータベースデッドロックの検出と解決

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

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

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

  2. stop-cal コマンドを発行して Calendar Server サービスを停止します。

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

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

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

    local.caldb.deadlock.autodetect=”yes”

    注 –

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

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

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

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

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

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

22.5.2.2 ログファイルの監視

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

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

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

注 –

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

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

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

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

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

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

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

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

  4. cal-svr-base/SUNWics5/cal/sbin ディレクトリに移動します。

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

    cd /opt/SUNWics5/cal/sbin

  5. カレンダデータベースのコピーに対して check コマンドを実行します。

    ./csdb check dbdir /tmp/check.out

    dbdir を指定しない場合、現在のディレクトリに格納されているデータベースに対して check が実行されます。

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

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

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

22.5.3 急激に巨大化し、数が増えたトランザクションログファイルへの対処

自動消去設定が、エンドユーザーが求めるクライアントユーザーインタフェースに適切に対応していない可能性があります。大容量のトランザクションログファイルが突然多数現れる原因は、Delete ログレコードの消去に非常に長い時間がかかっているだけの場合があります。この遅延が、Connector for Microsoft Outlook または Sync Tool のユーザーに対応するために意図的に設けられている場合は、多数の大容量のトランザクションログの出現は予期されているものです。これ以降の処置は必要ありません。システムは最終的には遅延を解消します。ただし、エンドユーザーが Communications Express クライアントを使用している場合、自動消去設定をデフォルトに戻すことで問題が解決します。

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

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

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

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

注 –

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

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

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

  2. stop-cal コマンドを発行して Calendar Server サービスを停止します。

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

    cd /etc/opt/SUNWics5/config

  4. 次のようにパラメータを設定し、カレンダに対して読み取り専用モードを指定します。

    caldb.berkeleydb.readonly=”yes”

  5. start-cal コマンドを使用して Calendar Server を再起動します。

    cal-svr-base/SUNWics5/cal/sbin/start-cal

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

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

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

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

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

対応策

  1. csadmindが実行されていない場合は、stop-cal コマンドを即座に実行します。

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

  2. すべての Calendar Server プロセスが終了していることを確認します。

    すべてのプロセスが終了していることを確認する方法については、「子プロセスを停止するには」を参照してください。

  3. start-cal -csadmind コマンドを実行し、csadmind を再起動してみます。

    正常に起動すると、次の手順を実行して 2 つのキューが機能していることを確認します。

    1. csschedule を使用して、GSE キューをチェックします。

    2. dbrig を使用して、アラームキューをチェックします。

      csschedule および dbrig の実行方法については、付録 D 「Calendar Server のコマンド行ユーティリティーのリファレンス」を参照してください。

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

    トレースに GSE に関連した機能がある場合は (中に GSE の文字がある)、GSE キューの最初のエントリおよび予定データベースの参照エントリを調べます。ほとんどの場合、GSE エントリで参照されている予定が、問題を起こしているエントリです。この問題を解決するには次を実行します。

    1. csschedule を使用して、GSE エントリを削除します。

    2. cscomponents を使用して、問題を起こしている予定をデータベースから削除します。

      csschedule および cscomponents の実行方法については、付録 D 「Calendar Server のコマンド行ユーティリティーのリファレンス」を参照してください。

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

    次の手順を実行します。

    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”

      • 「22.5.8 自動バックアップコピーの復元」にある手順を使用して、ホットバックアップコピーに戻ります。

        csstored を設定して有効にすると、ホットバックアップが使用可能になり、数分以内に最新のものになります。また、常にホットバックアップコピーを検証して、破損していないことを確認するとよいでしょう。その場合は、db_verify を実行します。

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

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

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

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

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

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

    cd cal-svr-base/SUNWics5/cal/sbin

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

    ./start-cal

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

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

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

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

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

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

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

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

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

22.5.6.1 rebuild の概要

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

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

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

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

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

  2. Calendar Server を停止します。

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

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

  4. cal-svr-base/SUNWics5/cal/sbin ディレクトリに移動します。

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

    cd /opt/SUNWics5/cal/sbin

    注 –

    sbin ディレクトリのディスク容量が問題となる場合は、別のディレクトリで rebuild コマンドを実行します。

  5. カレンダデータベースのコピーに対して 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 ディレクトリに書き込みます。

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

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


    Calendar database has been rebuilt

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

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

  9. Calendar Server を再起動します。

22.5.6.2 再構築出力のサンプル

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


# ./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 回走査されたことを示しています。これはエラーではありません。最初の走査ではカレンダプロパティーデータベース内の情報を確認し、次に再走査して、カレンダプロパティーデータベースがアクセス可能であることを確認します。

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

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

22.5.7.1 ダンプとロードの概要

ダンプとロードの手順を使用して破損したデータベースの復元を試みます。ダンプとロードの手順では、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 については、ご購入先のテクニカルサポートに問い合わせてください。

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

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

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

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

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

  4. 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

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

    次に例を示します。

    db_load new.ics50events.db < ics50events.db.txt

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

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

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

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

    rebuild の実行が完了したら、出力ファイルを確認します。再構築が正常に完了した場合、rebuild.out ファイルの最後の行は次のようになります。


    Calendar database has been rebuilt

    csdb rebuild コマンドが正常に終了しなかった場合は、次レベルの db_dump オプション (-r または -R) を使用してデータベースのダンプを行います。

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

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

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

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

22.5.8.1 復元する前に

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

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

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

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

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

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

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

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

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

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

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

    db_recover -c -h recoverydb

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

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

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

    1. 次のコマンドを実行し、Calendar Server を停止します。

      cd /opt/SUNWics5/cal/sbin

      ./stop-cal

    2. このコマンドを使用し、Calendar Server データベース (csdb) のコピーをもう 1 つ作成します。

      cp -Rp /var/opt/SUNWics5/csdb /var/opt/SUNWics5/csdb.db_verify

    3. csdb のコピーに対して db_verify を実行します。

      注 –

      db_verify を、元の csdb に対して実行しないでください。

      LD_LIBRARY_PATH=/opt/SUNWics5/cal/lib
export LD_LIBRARY_PATH
cd /opt/SUNWics5/cal/tools/unsupported/bin
./db_verify -h /var/opt/SUNWics5/csdb.db_verify ics50alarms.db
./db_verify -h /var/opt/SUNWics5/csdb.db_verify ics50calprops.db
./db_verify -h /var/opt/SUNWics5/csdb.db_verify ics50events.db
./db_verify -h /var/opt/SUNWics5/csdb.db_verify ics50gse.db
./db_verify -h /var/opt/SUNWics5/csdb.db_verify ics50journals.db
./db_verify -h /var/opt/SUNWics5/csdb.db_verify ics50recurring.db
./db_verify -h /var/opt/SUNWics5/csdb.db_verify ics50todos.db
./db_verify -o -h /var/opt/SUNWics5/csdb.db_verify ics50deletelog.db
      注 –

      ics50deletelog.db に対し、-o オプションを指定して db_verify を実行します。

      db_verify が正常に実行されると、エラーメッセージは表示されません。データベースファイルが破損していると、エラーメッセージがスローされます。次に例を示します。


      ./db_verify -h /var/opt/SUNWics5/csdb.db_verify ics50todos.db
db_verify:Page 612: last item on page sorted greater than parent entry
db_verify: Page 612: incorrect next_pgno 885 found in leaf chain (should be 501)
db_verify: Page 0: page 501 encountered a second time on free list
db_verify: DB->verify: ics50todos.db: DB_VERIFY_BAD: Database verification failed

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

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

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

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

  13. Calendar Server を起動します。

  14. 新規の復元ディレクトリでいずれかの手順に失敗した場合は、次のようにして破損していない古いホットバックアップを特定します。

    1. ホットバックアップを新しい順から逆にたどり、各ファイルに対して順番に db_verify および csdb -v list を実行して、破損していない最新のコピーを見つけます。

    2. パスする最初のホットバックアップコピーが、ライブデータベースのディレクトリに復元されます。

      「ホットバックアップを復元するには」で説明している手順に従い、破損したライブデータベースを新規のホットバックアップと置き換えます。最初に、必ず 「22.5.8.1 復元する前に」をお読みください。

    3. ホットバックアップがどれも動作せず、アーカイブバックアップがない場合は、テクニカルサポートに問い合わせてください。アーカイブバックアップがある場合は、「アーカイブバックアップを復元するには」にある手順を実行します。「22.5.8.1 復元する前に」も参照してください。

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

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

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

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

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

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

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

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

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

    db_recover -c -h recoverydb

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

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

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

    「ホットバックアップを復元するには」では、db_verify の実行手順について説明しています。

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

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

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

  12. Calendar Server を起動します。

  13. 新規の復元ディレクトリがいずれかの手順に失敗した場合は、次のようにして破損していない古いアーカイブバックアップを特定します。

    1. アーカイブバックアップのコピーを新しい順から逆に調べて、順に各ファイルに対して次の 3 つのリカバリプログラムを実行して、破損していない最新のコピーを見つけます。db_recover -c-h、db_verify、および csdb -v list。

    2. パスする最初のアーカイブアップコピーが、ライブデータベースのディレクトリに復元されます。

      「アーカイブバックアップを復元するには」で説明している手順に従い、破損したライブデータベースを新規のアーカイブバックアップと置き換えます。

    3. アーカイブバックアップがどれも動作しない場合は、テクニカルサポートに問い合わせてください。

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

ここでは、次の内容について説明します。

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

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

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

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

LD_LIBRARY_PATH=libdb-4.2.so