第 22 章 トラブルシューティング
この章では、システムに問題があるかどうか、またその原因を調べるためのトラブルシューティングの方法について説明します。この章で説明する内容は次のとおりです。
デバッグ情報の有効化
システム全体を「デバッグモード」にする ics.conf パラメータはありませんが、ここでは有用なデバッグ情報を取得する方法について説明します。
注 –
パフォーマンスにマイナスの影響を与えるため、必要でない場合は、必ず、過度なログ記録および監視は無効にしてください。
ログレベルを上げる
次の表に示すパラメータを使用して、ログの詳細度を上げます。
|
パラメータ |
説明とデフォルト値 |
|---|---|
|
logfile.loglevel |
DEBUG に設定して、CRITICAL、ALERT、ERROR、WARNING、NOTICE、および INFORMATION を含む、すべてのレベルがログ記録されるようにします。この設定はすべてのログに適用されます。 |
使用可能な別のログについては、「Calendar Server ログファイルの使用」を参照してください。
LDAP キャッシュへのアクセスログの有効化
LDAP データキャッシュのすべてのアクセスをログに記録し、そのログ (レポート) を出力するには、次の表に示す ics.conf パラメータを設定します。
|
パラメータ |
説明とデフォルト値 |
|---|---|
|
local.ldap.cache.stat.enable |
LDAP データキャッシュへのアクセスをログに記録し、ログファイルに統計情報を出力するかどうかを指定します。デフォルトは “no” です (統計情報はログ記録されない)。統計情報のログを有効にするには、“yes” に設定します。 パフォーマンス向上のために、このパラメータはデバッグモードでのみ使用してください。 |
|
local.ldap.cache.stat.interval |
統計情報レポートをログファイルに書き込む間隔を秒単位で指定します。デフォルトは “1800” 秒 (30 分) です。 これは、ログが有効になっている場合にのみアクティブになります。間隔を短くすると、問題を特定するのに役立ちます。間隔を長くすると、システムロードが減少します。 |
LDAP キャッシュのクリア
現在、Calendar Server には LDAP キャッシュデータを失効させるためのロジックは存在しません。ldap_cache ディレクトリの内容を手動で削除し、Calendar Server を再起動する必要があります。
LDAP キャッシュをクリアするには
手順
-
Calendar Server を停止します。
-
/var/opt/SUNWics5/csdb/ldap_cache ディレクトリ内のファイルをすべて削除します。ただし、ldap_cache ディレクトリ自体は削除しないでください。
-
Calendar Server を再起動します。
Calendar Server ユーティリティーによるシステムの監視
システムを監視するには、次の Calendar Server ユーティリティーを使用します。
-
csmonitor: 必要なデバッグレベルを指定します。数字が大きいほど、メッセージがより詳細になります。
-
csstats: counter.conf ファイルに定義されているカウンタオブジェクトからの統計情報を表示するには、list コマンドを使用します。
-
cstool: cshttpd、csadmind、enpd の各サービスに対して ping を実行するには、このユーティリティーを使用します。
Calendar Server のユーティリティーについては、付録 D 「Calendar Server のコマンド行ユーティリティーのリファレンス」 を参照してください。
LDAP の問題のトラブルシューティング
ホストされた環境を最初に作成するときに、ドメイン、コンテナ、ユーザー、リソースの適切なエントリを追加して、LDAP に DC ツリーを作成する必要があります。cscal などの Calendar Server のユーティリティーを使用するときに DC ツリーが存在しないと、次のようなエラーメッセージが表示される可能性があります。"Initialization failed .... exiting"
DC ツリーには、DC ツリーのルートに少なくとも 1 つの (デフォルト) ドメインが含まれていることを確認します。「新規のホストされたドメインの作成」に記載されている方法を使用して DC ツリー構造を作成します。
移行ユーティリティーのトラブルシューティング
Calendar Server には、カレンダデータベースおよび LDAP ディレクトリを移行するためのいくつかのユーティリティーが用意されています。ここで説明する内容は次のとおりです。
テクニカルサポートに問い合わせる前に必要なこと
一般に、移行ユーティリティーを使用して問題が生じた場合、次の情報を収集してから、テクニカルサポートにお問い合わせください。
-
問題のデータベースのバックアップコピー。
-
すべての関連ログのコピー。
-
コアを含むすべてのエラー出力メッセージ。
移行ユーティリティーの入手先
さまざまな移行ユーティリティーおよびそのマニュアルは、次の一覧に示す場所にあります。
- スキーマ移行ユーティリティー (commdirmig)
-
このユーティリティーは、個別にインストール可能なコンポーネントである Delegated Administrator にバンドルされています。このユーティリティーは LDAP ディレクトリを Schema 1 から Schema 2 に移行します。このユーティリティーについては、『Sun Java System Communications Services 6 2005Q4 Schema Migration Guide』を参照してください。
- Calendar Server 5 から Calendar Server 6 への移行ユーティリティー ( cs5migrate)
-
テクニカルサポートサイトにはユーティリティーとそのマニュアルを含む移行バンドルが用意されています。
- Calendar Server 移行ユーティリティー (csmig)
-
このユーティリティーは Calendar Server にインストールされています。マニュアルは 第 4 章「データベース移行ユーティリティー」に記載されており、トラブルシューティングの節が含まれています。ホストされたドメインおよび LDAP カレンダ検索データベース (CLD) プラグインを使用している場合は、このユーティリティーを実行する必要があります。
- Calendar Server 仮想ドメイン移行ユーティリティー (csvdmig)
-
このユーティリティーは Calendar Server にインストールされています。マニュアルは、第 4 章「データベース移行ユーティリティー」に記載されています。ホストされたドメイン用のカレンダデータベースおよび LDAP ディレクトリのエントリを準備するには、このユーティリティーを使用します。
- Calendar Server 2 から Calendar Server 6 への移行ユーティリティー ( ics2migrate)
-
このユーティリティーは Calendar Server にインストールされています。マニュアルは、第 4 章「データベース移行ユーティリティー」に記載されています。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 を利用されることをお勧めします。
Calendar Server のトラブルシューティング
ここでは、データベース以外の問題のさまざまなトラブルシューティングについて説明します。ここで説明する内容は次のとおりです。
ヒント –
さらに、次の SSL の章にも、SSL に関するトラブルシューティングの節があります。
カレンダサービスに対する ping の実行
サービスが特定のポート番号で待機していることを確認するには、「cstool」 ユーティリティーの ping コマンドを実行します。サービスに対して ping を実行しても、サービスが実際に稼動しているかどうかは検証されません。ソケット接続が受け付けられるかどうかが検証されます。
cstool のサービスオプション
Calendar Server サービスには次のオプションがあります。
- http
-
HTTP サービス (cshttpd)
- admin
-
管理サービス (csadmind)
- ens
-
ENS (予定通知サービス) (enpd)
注 –
DWP サービス (csdwpd) や通知サービス (csnotifyd) に対して ping を実行することはできません。
cstool の例
たとえば、calserver というホスト名のマシンに対して ping を実行し、cshttpd サービスがポート 80 で待機しているかどうかを確認するには、次のように実行します。
cstool -p 80 -h calserver ping http
デフォルトでは、cstool は 120 秒間応答を待ちますが、-t timeout オプションを使用してこの値を変更することができます。
ユーティリティーの詳細な参考資料については、付録 D 「Calendar Server のコマンド行ユーティリティーのリファレンス」 を参照してください。
注 –
cstool を実行するには、Calendar Server が稼動している必要があります。
start-cal の問題の解決
start-cal を実行したときに起動しないカレンダサービスがある場合は、再起動する前に起動したサービスを終了する必要があります。たとえば、enpd、csnotifyd、および csadmind が起動しても cshttpd が起動しなかった場合は、enpd、csnotifyd、および csadmind を終了する必要があります。
カレンダサービスを起動するには、次のように実行します。
手順
-
Calendar Server が稼動しているシステムの管理権限を持つユーザーとしてログインします。
-
サービスを終了して、再起動するには、start-cal を使用します。次に例を示します。
cal_svr_base/SUNWics5/cal/sbin/start-cal
start-cal は、さまざまなカレンダサービスを起動する前に、まず stop-cal コマンドを実行します。
-
stop-cal が終了に失敗した場合は、いくつかの子プロセスが終了に失敗した可能性があります。この場合の処理については、「stop-cal の問題の解決」を参照してください。
stop-cal の問題の解決
Calendar Server のシャットダウン時には、考慮する必要がある 2 つの別個の問題があります。
子プロセスを停止するには
stop-cal を実行したあと、いくつかの子プロセスが停止していない場合があります。たとえば、stop-cal によって cshttpd 親プロセスは停止しているのに、一部の cshttpd 子プロセスが停止していないことがあります。このような場合は、次の手順で、残りの Calendar Server プロセスを個別に停止させる必要があります。
手順
-
Calendar Server が稼動しているシステムの管理権限を持つユーザーとしてログインします。
-
サービスごとに ps コマンドを実行し、残っている Calendar Server プロセスのプロセス ID (PID) を特定します。
ps -elf | grep cs-process
ここで、cs-process は enpd、csnotifyd、csdwpd、csadmind、または cshttpd です。次に例を示します。
ps -elf | grep cshttpd
-
kill -15 コマンドに終了していない各プロセスの PID を指定して、プロセスを終了します。例: kill -15 9875
-
それぞれの ps コマンドをもう一度実行し、すべての Calendar Server プロセスが終了していることを確認します。
Calendar Server プロセスがまだ稼動しているときは、kill -9 コマンドを実行して終了します。例: kill -9 9875
注 –Linux システムで Calendar Server を実行していて、ps コマンドを使用してカレンダプロセスを検索すると、結果がわかりにくく見えることがあります。Linux では、ps コマンドは、プロセスのリストではなく実行しているスレッドのリストを返します。プロセスだけが表示されるようにするための既知の解決策はありません。
不正シャットダウンしたあとで回復するには
Calendar Server が正しくシャットダウンしなかった場合は、次の手順を実行します。
手順
-
前の手順 (「stop-cal の問題の解決」) を実行します。
-
LDAP データキャッシュデータベースのディレクトリ内のすべてのファイルを手動で削除します。
ファイルが残っていると、データベースが破損する可能性があります。ファイルを削除するには、次のように実行します。
-
Calendar Server を再起動します。
cal_svr_base /SUNWics5/cal/sbin/start-cal
LDAP データキャッシュの設定方法については、「Calendar Server の LDAP の設定」を参照してください。LDAP データキャッシュについては、『Sun Java System Communications Services 6 2005Q4 Deployment Planning Guide』を参照してください。
バックエンドサーバーに接続できない
-
応答しているかどうか調べるには、バックエンドサーバーに対して ping を実行します。
応答している場合は、手順 3 に進みます。応答していない場合は、その原因を調べ、ふたたび動作するようになったら手順 3 に進みます。
-
CLD キャッシュをクリアします。「CLD キャッシュのクリア」を参照してください。
CLD キャッシュオプションを使用していて、ics.conf パラメータのサーバー名を更新した場合は、CLD キャッシュをクリアしてサーバー名を消去するとよいでしょう。CLD キャッシュに古いエントリが残されていると、フロントエンドサーバーが正しいバックエンドサーバーに接続できなくなったり、Calendar Server が移動後のカレンダを見つけられなくなります。
-
Calendar Server を再起動します。
カレンダが見つからない
CLD キャッシュオプションを使用していて、1 つ以上のカレンダを別のバックエンドサーバーに移動した (または、バックエンドサーバーの名前を変更した) 場合は、次の手順を実行します。
-
次に記載されている手順に従ってカレンダを移動していることを確認します。
「ユーザーカレンダの管理」を参照してください。
-
CLD キャッシュをクリアします。「CLD キャッシュのクリア」を参照してください。
1 つ以上のカレンダを別のバックエンドサーバーに移動すると、CLD キャッシュは無効になります。再読み込みするには、キャッシュをクリアする必要があります。そうすると、キャッシュが再構築されます。
プロキシ認証を使用してログインしようとすると「承認されていない」が表示される
-
service.http.allowadminproxy が “yes” に設定されていることを確認します。
-
admin-user に Calendar Server 管理者の権限があることを確認します。
-
admin-password が正しいことを確認します。
-
calendar-user が有効な Calendar Server ユーザーであることを確認します。
正しく完了しない検索のトラブルシューティング
LDAP ディレクトリサーバー設定の nsslapd-sizelimit 属性と nsLookthroughLimit 属性は、検索が正しく終了するように十分なサイズに設定する必要があります。nsSizeLimit が十分なサイズでない場合は、一部の結果が欠落したり、検索結果が表示されなくなることがあります。nsLookthroughLimit が十分なサイズでない場合は、検索が完了しないことがあります。
ここで説明する内容は次のとおりです。
制限属性の値が適切かどうかを調べるには
手順
-
これらの属性に適切な値が設定されているかどうかを調べるには、次のコマンドを実行します。
ldapsearch -b "base " "(&(icscalendarowned=*user*)(objectclass=icsCalendarUser))"
ここで、base は、Calendar Server のユーザーとリソースのデータが格納されているディレクトリサーバーの LDAP ベース DN であり、user は、エンドユーザーがユーザーインタフェースの検索ダイアログで入力できる値です。
-
LDAP サーバーがエラーを返す場合、nsSizeLimit または nsLookthroughLimit パラメータの値が十分でない可能性があります。
制限属性を適切な値に設定するには
これらの属性の DN は次のとおりです。
dn: cn=config,cn=ldbm databases,cn=plug ins,cn=config
手順
-
nsLookthroughLimit の値を動的に設定するには、ldapmodify を使用します。
この属性を変更するために Directory Server を終了して再起動する必要はありません。
デフォルト値は 5000 です。検索結果が表示されない場合、この値を大きくすることができます。ただし、そうすると LDAP サーバーのパフォーマンスが低下します。
制限を -1 に設定して、制限の適用を解除することもできます。ただし、システムがハングすることが想定されるため、慎重に行ってください。
-
nsslapd-sizelimit をより大きい値に設定する場合は、次の手順を実行する必要があります。
-
Directory Server を停止します。
-
dse.ldif ファイルを編集します。
-
Directory Server を再起動します。
注 –ldapmodify の使用方法および dse.ldif ファイルの編集方法については、次の Web サイトで入手できる Directory Server のマニュアルを参照してください。
http://docs.sun.com/coll/1316.1
-
csstored のわずらわしい日常的なメッセージを無効にする
start-cal コマンドは、csstored プロセスが設定されていない場合でも、デフォルトで csstored プロセスを起動します。設定されていない csstored プロセスは、csstored を実行しているすべてのマシンで 24 時間ごとに設定されていないことを伝えるメッセージを出力します。
csstored を未設定の状態で実行しないようにすることによって、メッセージを無効にできます。csstored プロセスの実行を無効にするには、メッセージが生成されるすべてのマシンで、次の ics.conf パラメータを設定します。
service.store.enable=”no”
自動バックアップ作成のために csstored を設定しているマシンでは、プロセスを無効にしないでください。
データベース問題の処理
ここでは、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 つのキューが機能していることを確認します。
-
csschedule を使用して、GSE キューをチェックします。
-
dbrig を使用して、アラームキューをチェックします。
csschedule および dbrig の実行方法については、付録 D 「Calendar Server のコマンド行ユーティリティーのリファレンス」 を参照してください。
-
-
csadmind がダンプでクラッシュした場合は、pstack を分析します。
トレースに GSE に関連した機能がある場合は (中に GSE の文字がある)、GSE キューの最初のエントリおよび予定データベースの参照エントリを調べます。ほとんどの場合、GSE エントリで参照されている予定が、問題を起こしているエントリです。この問題を解決するには次を実行します。
-
csschedule を使用して、GSE エントリを削除します。
-
cscomponents を使用して、問題を起こしている予定をデータベースから削除します。
csschedule および cscomponents の実行方法については、付録 D 「Calendar Server のコマンド行ユーティリティーのリファレンス」 を参照してください。
-
-
エントリが破損していない場合は、カレンダサーバーでは処理できない特殊な例の可能性があります。
次の手順を実行します。
-
破損したデータベースのカレンダ環境のスナップショットを取り、カスタマサポートに問い合わせます。
環境のバックアップを作成するには、次のように実行します。
-
サービスの停止を避けるには、カレンダデータベースを一時的に読み取り専用の状態にして、ホットバックアップのコピーに戻ります。
-
カレンダデータベースを一時的に読み取り専用の状態にすると、トランザクションの追加、変更、または削除はできなくなります。エンドユーザーがカレンダデータを追加、変更、または削除しようとすると、エラーメッセージが表示されます。カレンダの予定および仕事を追加、変更、または削除する管理者ツールも、データベースが読み取り専用モードの間は機能しません。
カレンダデータベースを読み取り専用モードにするには、ics.conf ファイルを編集して、次のパラメータを “yes” に設定します。
caldb.berkeleydb.readonly=”yes”
-
「自動バックアップコピーの復元」にある手順を使用して、ホットバックアップコピーに戻ります。
csstored を設定して有効にすると、ホットバックアップが使用可能になり、数分以内に最新の状態になります。また、常にホットバックアップコピーを検証して、破損していないことを確認するとよいでしょう。その場合は、db_verify を実行します。
-
-
-
ほかの方法がすべて失敗した場合、ダンプと再ロードの手順を実行して、データベースを修復できるかどうか確認します。
この手順は、「ダンプとロードによるカレンダデータベースの復元」で説明しています。
サービスがハングし、エンドユーザーが接続できない: 親のないロック
この状態は、制御スレッドが原因で発生する場合があります。これは Berkeley DB データベースのページをロックし、ロックを解除しないで終了します。この問題を確認するには、cshttpd プロセスおよび csadmind 上で pstack を実行します。pstack は標準 UNIX ユーティリティーで、次の場所に格納されています。/usr/bin/pstack。このユーティリティーにより、ロックを獲得するために待機しているスレッドが表示されます。
問題を解決するには、次のようにして Calendar Server を再起動します。
手順
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 BackupTM ソフトウェア、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 を起動します。
-
新規の復元ディレクトリでいずれかの手順に失敗した場合は、次のようにして破損していない古いホットバックアップを特定します。
-
ホットバックアップを新しい順から逆にたどり、各ファイルに対して順番に db_verify および csdb -v list を実行して、破損していない最新のコピーを見つけます。
-
パスする最初のホットバックアップコピーが、ライブデータベースのディレクトリに復元されます。
「ホットバックアップを復元するには」で説明している手順に従い、破損したライブデータベースを新規のホットバックアップと置き換えます。最初に、必ず 「復元する前に」をお読みください。
-
ホットバックアップがどれも動作せず、アーカイブバックアップがない場合は、テクニカルサポートに問い合わせてください。アーカイブバックアップがある場合は、「アーカイブバックアップを復元するには」にある手順を実行します。「復元する前に」も参照してください。
-
アーカイブバックアップを復元するには
破損したホットバックアップはないが、アーカイブバックアップとトランザクションログがある場合は、次の手順を実行して、アーカイブしたデータベースの最新の破損していないデータベースを復元できます。
手順
-
破損したライブデータベースのディレクトリで、適用されていない、または書き込み可能な状態のログファイルを識別します。
-
書き込み可能なログを閉じます。このログには、最新のトランザクションが含まれています。
-
新規の (復元) ディレクトリを作成します。
-
最新のアーカイブコピーとそのログファイルを、新規の復元データベースのディレクトリにコピーします。
-
適用されていない 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 を起動します。
-
新規の復元ディレクトリがいずれかの手順に失敗した場合は、次のようにして破損していない古いアーカイブバックアップを特定します。
-
アーカイブバックアップのコピーを新しい順から逆に調べて、順に各ファイルに対して次の 3 つのリカバリプログラムを実行して、破損していない最新のコピーを見つけます。db_recover -c-h、db_verify、および csdb -v list。
-
パスする最初のアーカイブアップコピーが、ライブデータベースのディレクトリに復元されます。
「アーカイブバックアップを復元するには」で説明している手順に従い、破損したライブデータベースを新規のアーカイブバックアップと置き換えます。
-
アーカイブバックアップがどれも動作しない場合は、テクニカルサポートに問い合わせてください。
-
カスタムのバックアップスクリプトの修復
ここで説明する内容は次のとおりです。
現在、動的ライブラリでコンパイルされている Berkeley ツール
カスタムバックアップスクリプトが Berkeley データベースのツール (db_recover など) を使用して作成されている場合は、Calendar Server にアップグレードすると、機能しなくなる可能性があります。これは、Calendar Server の以前のバージョンでは、ツールを静的ライブラリでコンパイルしていたためです。現在では、ツールは動的ライブラリの libdb-4.2.so でコンパイルされています。
カスタムのバックアップスクリプトを修復するには
既存のカスタムスクリプトで新しい動的ライブラリを使用するには、次に示す大域変数を設定します。
LD_LIBRARY_PATH=libdb-4.2.so
- © 2010, Oracle Corporation and/or its affiliates