Skip to main content

This is documentation for Caché & Ensemble. See the InterSystems IRIS version of this content.Opens in a new tab

For information on migrating to InterSystems IRISOpens in a new tab, see Why Migrate to InterSystems IRIS?

ライト・イメージ・ジャーナリングとリカバリ

Caché は、ライト・イメージ・ジャーナリングを使用して、Caché データベースの内部の整合性を維持します。これは、データベース・リカバリ処理の基本です。

以下の項目について説明します。

ライト・イメージ・ジャーナリング

Caché は、2 フェーズ技術のライト・イメージ・ジャーナリングを使用してデータベースの更新を保護します。最初はメモリから転送ジャーナル CACHE.WIJ に、その後、データベースに更新を書き込みます。システムが第 2 フェーズ中にクラッシュした場合、更新処理はリカバリを再度適用します。以下の項目の詳細を説明しています。

ライト・イメージ・ジャーナル (WIJ)

Caché の起動時にライト・デーモンがアクティブになり、ライト・イメージ・ジャーナル (WIJ) ファイルが生成されます。Caché データベースに更新情報を書き込む前に、ライト・デーモンは WIJ にデータベースの更新を記録します。

WIJ ファイルは、既定では CACHE.WIJ という名前になり、システム管理者ディレクトリ (通常は install-dir/Mgr) に格納されます。install-dir は、インストール・ディレクトリです。このファイルに別の場所を指定する場合は、管理ポータルを使用します。

  1. システム管理, 構成, システム構成, ジャーナル設定 ページに移動します。

  2. WIJ の新しい格納場所を [ライトイメージジャーナルディレクトリ] ボックスに入力し、[保存] をクリックします。この名前にはシステム上の既存のディレクトリを指定する必要があり、最長で 63 文字です。クラスタ化されたインスタンスでこの設定を編集した場合、変更内容を適用するには、Caché を再起動してください。スタンドアロン・インスタンスの場合、再起動は必要ありません。

2 フェーズ・ライト・プロトコル

Caché は、データベースが高速に効率よく検索、更新できるような構造で、アプリケーション・データを維持します。一般的に、アプリケーションがデータを更新する際、Caché は、データベース構造で複数のブロックを更新し、変更を反映する必要があります。

連続したディスク・アクセスの結果、ディスクやコンピュータ処理が、突然、予期せずに中断されることがあります。これにより、最初のブロックが書き込まれた後、最後のブロックが更新されるまでの間に、複数のデータベース・ブロックの更新が停止します。2 つのフェーズで構成されるライト・プロトコルは、このように不完全な更新によってデータベース構造に矛盾が生じるのを防ぐためのものですが、これにより問題が発生することがあります。このため、データベースは通常の方法では回復できず、すべてのデータが使用できなくなってしまう可能性があります。

Caché ライト・イメージ・ジャーナリング・テクノロジは、以下のような 2 フェーズでデータベースへの書き込みを行い、そのような状況から保護します。

  • 第 1 フェーズでは、Caché は WIJ に、更新されたブロックを記録します。WIJ のすべての更新を入力した後、ファイル内にフラグを設定し、第 2 フェーズを開始します。

  • 第 2 フェーズでは、WIJ 内に記録されたものと同じブロック・セットを、ライト・デーモンがディスク上のデータベースに記述します。この第 2 フェーズが完了したら、ライト・デーモンは WIJ 内にフラグを設定し、これが削除済みであることを示します。

Caché を起動すると、WIJ が自動的にチェックされ、異常なシャットダウンが検出された場合はリカバリ・プロシージャが実行されます。このプロシージャが正常に完了すれば、データベースの内部整合性はリストアされています。シャットダウンに続き、Caché は WIJ のリカバリも実行します。これはデータベースが確実にバックアップされるようにするための安全対策です。

リカバリ

システム・クラッシュなどの重大なシステム障害が発生した場合には、WIJ のリカバリが必要となります。Caché を起動すると、WIJ が自動的にチェックされます。異常なシャットダウンが検出された場合はリカバリ・プロシージャが実行されます。2 つのフェーズで構成されるライト・プロトコル・プロセスのどちらに WIJ があるかに応じて、リカバリは以下のように実行されます。

  • WIJ の最終更新が完了した後、対応するデータベースの更新が完了する前 (つまり、プロセスの第 2 フェーズ中) にクラッシュが発生した場合は、"WIJ のリストア" の説明に従って WIJ がリストアされます。

  • WIJ の最終更新が確実にデータベースに書き込まれた後 (つまり、両方のフェーズが完了した後) にクラッシュが発生した場合は、"WIJ ブロック比較" の説明に従って最新の WIJ 更新と影響を受けたデータベースの間のブロック比較が行われます (Windows および UNIX®/Linux のみ)。

WIJ のリストア

WIJ が “アクティブ” とマークされている場合、ライト・デーモンは WIJ への変更されたディスク・ブロックの書き込みを完了していますが、それぞれのデータベースへの書き込みは完了していません。この場合、WIJ のリストアが必要です。リカバリ・プログラム cwdimj は、以下を実行します。

  • コンソール・ログ (cconsole.log) ファイルによってシステム管理者に通知します。詳細は、"Caché 監視ガイド" の “管理ポータルを使用した Caché の監視” の章にある "ログ・ファイルの監視" を参照してください。

  • データセット・リカバリを実行します。

通常すべてのリカバリは、cwdimj プログラムの 1 回の実行で処理されます。

データセット・リカバリ

データセットは、特定の Caché システム上の特定のデータベース・ディレクトリです。cwdimj プログラムは、異常なシャットダウン後に再起動する Caché インスタンスで構成されたすべてのデータセットをリストアします。

cwdimj プログラムは、対話式または非対話式で実行できます。実行方法は、以下のようにプラットフォームによって異なります。

  • Windows — 常に非対話式で実行されます。

  • UNIX®/Linux — エラーが発生するまでは非対話式で実行され、その後プロンプトに応答するオペレータがいる場合には対話式で実行されます。

Note:

UNIX/Linux システムで ccontrol start quietly コマンドを使用すると、このコマンドは常に非対話式で実行されます。

リカバリ・プロシージャが完了すると、cwdimj は WIJ の内容に “削除済み” とマークし、起動が継続されます。

書き込み中にエラーが発生した場合は、WIJ がアクティブ状態のままとなり、Caché は起動しません。このオプションが (対話モードで) 上書きされない限り、次回の Caché 起動時にリカバリが繰り返されます。

Caution:

オプションを上書きして WIJ をリストアすると、データベースが破損するか、またはデータが消失します。

以下の項目を詳細に説明します。

対話式のデータセット・リカバリ

リカバリ手順により、データセットごとにリカバリするかどうかを確認できます。通常は、すべてのデータセットを指定します。それぞれのデータセットのプロンプトの後、以下を入力します。

  • Y — データセットをリストアする

  • N — データセットをリストアしない

また、データセットへのパスが失われても、そのデータセットにアクセスできる場合は、そのデータセットの新しい場所を指定できます。データセットがリカバリされると、リカバリを要求するデータセットのリストからそのデータセットは削除されます。また、cwdimj プログラムが引き続き実行されている間は、リカバリする必要が発生してもリカバリされません。

非対話式のデータセット・リカバリ

リカバリ手順が非対話式で実行される場合、Caché は、すべてのデータセットをリストアし、WIJ を削除済みとマークしようとします。Unix プラットフォームおよび Windows プラットフォームでは、Caché は、最初にすべてのデータセットの高速並行リストアを試行します。高速リストア中に 1 つまたは複数のエラーが発生すると、データセットは一度に 1 つずつリストアされ、完全にリカバリされたデータベースを識別できるようにします。少なくとも 1 つのデータセットをリストアできない場合、以下のようになります。

  • cwdimj プログラムが中止され、システムは起動しません。

  • 正常にリカバリされなかったデータセットは、WIJ に、リカバリが必要だと記録されたままになります。

WIJ ブロック比較

通常、実行中の Caché インスタンスがデータベースへのアクティブな書き込みを行うのはわずかな時間のみです。したがって、ほとんどのクラッシュでは、WIJ に最後に書き込まれたブロックは、クラッシュの前にデータベースに確実に書き込まれたことが確認されます。WIJ はアクティブとマークされず、実行される WIJ のリストアはありません。しかし、このようなクラッシュの後に Caché が起動すると、最新の WIJ 更新が行われたブロックは、影響を受けたデータベースの対応するブロックと高速整合性チェックの形式で比較され、ストレージ・サブシステムの障害を伴ったクラッシュの後に不明な状態でインスタンスを開始しないようにします。この比較は、可用性への影響を回避するために短時間で実行され、スループットを最大化するために非同期入出力が利用されます。すべてのブロックが一致するまたは 10 秒以内に不一致が検出されない場合、通常どおりに起動が続行されます。この時間内に不一致が見つかった場合、以下のようになります。

  • 使用可能なすべての WIJ ブロックの比較が完了するまで比較動作が継続されます。

  • 一致しなかった WIJ ブロックは、WIJ ディレクトリにある MISMATCH.WIJ というファイルに書き込まれます。

  • 通常の起動が中止され、Caché はシングル・ユーザ・モードで起動し、以下のようなメッセージが表示されます。

    There exists a MISMATCH.WIJ file.
            Startup aborted, entering single user mode.
            Enter Cache' with
                 csession [instancename] -B
            and D ^STURECOV for help recovering from this error.
    

この状況は早急な対応が必要です。後に続く情報を利用して、適切な処置を判断してください。リカバリ手順が完了したら、Caché の起動を続行する前に、STURECOV ルーチンを使用するかまたは外部から、MISMATCH.WIJ ファイルを削除する必要があります。このファイルは永続的で、インスタンスが通常起動しなくなります。

指示されたコマンドを実行し、システム管理者として緊急ログインを行います ("Caché システム管理ガイド" の “Caché 複数インスタンスの使用法” の章にある "Caché インスタンスの接続" を参照してください)。

これで管理者のネームスペースに入ることができたので、Do ^STURECOV コマンドを使用してスタートアップ・リカバリ・ルーチンを実行できます。UNIX®/Linux システムでは、次の WIJ 不一致リカバリ・メッセージおよびメニューが表示されます。

The system crashed and some database blocks do not match what was
expected based on the contents of write image journal (the WIJ).
The WIJ blocks have been placed in the MISMATCH.WIJ file.  If any
database files, or the WIJ, were modified or replaced since the crash,
you should delete the MISMATCH.WIJ. Otherwise, MISMATCH.WIJ probably
contains blocks that were lost due to a disk problem.  You can view 
those blocks and apply them if necessary.  When finished, delete the 
MISMATCH.WIJ in order to continue startup.
 
1) List Affected Databases and View Blocks
2) Apply mismatched blocks from WIJ to databases
3) Delete MISMATCH.WIJ
4) Dismount a database
5) Mount a database
6) Database Repair Utility
7) Check Database Integrity
8) Bring up the system in multi-user mode
9) Display instructions on how to shut down the system

--------------------------------------------------------------
H) Display Help
E) Exit this utility
--------------------------------------------------------------

Windows システムでは、オプション 8 および 98) Bring down the system prior to a normal startup に置き換えられます。

WIJ 不一致発生時の適切なアクションは、企業のニーズおよびポリシーに基づいて異なりますが、データ整合性の問題を示唆するイベントに対応する際にユーザのサイトにおいて行う既存の慣行とほぼ同じです。考慮事項には、リスクに対する許容範囲、影響を受けるデータベースの重要度、稼働時間の要件、疑われる原因などがあります。

次に、WIJ ブロック比較プロセスに固有の考慮事項および推奨事項を示します。

  • クラッシュの後かつリカバリの前にデータベースまたは WIJ ファイルを置換、リストア、または変更すると、不一致が発生する可能性があります。この不一致は、WIJ 比較時に見つかり、MISMATCH.WIJ ファイルに記録されます。 これが発生した場合は、MISMATCH.WIJ を削除してください。

    Note:

    クラッシュの後にデータベースをリストアする場合、このリストアを実行する前に必ず WIJ およびジャーナルのリカバリを行わない状態でインスタンスを開始してください (このドキュメントの “バックアップとリストア” の章の "自動 WIJ およびジャーナル・リカバリを使用しない Caché の起動" を参照)。こうすることによって、WIJ 比較で検出されることになる不一致の作成と WIJ ブロックまたはジャーナル・データ (このドキュメントの “ジャーナリング” の章を参照) の意図しないデータベースのバージョンへの誤った適用の両方が回避されます。

  • 一部のストレージ・サブシステム (特に、ラップトップおよびワークステーションのローカル・ドライブ) は、バッテリまたは非揮発性のメモリでバックアップされていない安全でない形式のライトバック・キャッシュを使用しています。これは、Caché が実行する 2 フェーズ・ライト・プロトコルを無効にし、ハードウェアのクラッシュまたは電源の喪失の後の破損 (WIJ 比較時に検出される) をもたらす可能性があります。このことがユーザのシステムに当てはまる場合、MISMATCH.WIJ にはより新しいデータが格納されている可能性が高く、したがって、データベースに安全に適用できます (多くの注意を必要としないシステムであることが前提)。

  • WIJ 比較の後にデータベースを変更した場合、MISMATCH.WIJ は有効ではなくなり、WIJ ブロックの適用は安全ではなくなります。

  • 全社クラスのストレージ、または安全でない形式のライトバック・キャッシュを使用していないストレージ・サブシステムを備えたサーバの場合、WIJ 比較時に見つかった不一致は常に予期しないものであり、より深刻で広範囲に及ぶ問題の兆候である場合があるため、重視する必要があります。

  • 問題の原因によっては、データベースには問題がなく、破損しているのは WIJ である場合があります。 影響を受けたデータベースの整合性チェックによってこの可能性を判断できます。

  • WIJ 比較は最後に書き込まれたブロックのみを対象とするため、追加のブロックに影響する問題がある可能性があり、これは完全な整合性チェックで検出できます (このガイドの “データ整合性の概要” の章にある "構造的な整合性の検証" を参照してください)。

  • データベースが小さく、時間が許すのであれば、次のような手順に従うことによって最大限の安全性を確保できます。

    1. データベースの完全な整合性チェックを実行します。

    2. 破損がない場合、 MISMATCH.WIJ を削除して起動します。

    3. 1 つまたは複数のデータベースが破損している場合、すべてのデータベースの CACHE.DAT ファイルをコピーし、MISMATCH.WIJ からすべてのブロックを適用し、完全な整合性チェックを再実行します。

    4. MISMATCH.WIJ を適用した後に破損しているデータベースがある場合、そのデータベースを前のコピーに戻すか、以前のバックアップからリストアできます。

WIJ の不一致が検出されたときの処理方法について不明な点がある場合は、インターシステムズのサポート窓口Opens in a new tabまでご相談ください。

ライト・イメージ・ジャーナリングの限界

2 フェーズ・ライト・プロトコルは、構造的なデータベースの整合性を保護しますが、データの損失は保護しません。WIJ に完全な更新を書き込む前にシステム障害が発生した場合、Caché は、ディスクを完全に更新するために必要な情報が不足している状態になるため、そのデータは失われます。ただし、ジャーナル・ファイルに書き込まれたデータは、この章の "リカバリ" の説明に従ってリカバリされます。

また、以下の場合、ライト・イメージ・ジャーナリングは、データベースの劣化を防ぐことはできません。

  • メモリまたはストレージの破損によるハードウェア障害。

  • メモリ、ファイル・システム、またはストレージの破損によるオペレーティング・システム障害。

  • WIJ が削除された状態。

  • ライト・バック・キャッシュの内容の消失。停電の場合には、ライト・バック・キャッシュが消失し、データベースの劣化が生じる可能性があります。このような劣化を防ぐには、ストレージアレイでライト・バック・キャッシュに非揮発性のメモリを使用するか、または揮発性のライト・バック・キャッシュにバッテリ・バックアップを使用するようにしてください。

上記のいずれかの状況が発生したと思われる場合には、インターシステムズのサポート窓口Opens in a new tabまでお問い合わせください。

FeedbackOpens in a new tab