ジャーナリングの概要

ジャーナリングの概要

InterSystems IRIS® データ・プラットフォームの各インスタンスはジャーナルを保持します。ジャーナルとは、最後のバックアップ以後にデータベースに対して行われた更新を時間順で保持している一連のファイルです。その処理は冗長性があり、論理的で、InterSystems IRIS ライト・デーモンを使用しません。InterSystems IRIS のトランザクション処理は、障害の後にデータの論理的整合性を維持するために、ジャーナリングと共に機能します。

また、バックアップとジャーナリングにより、データベースを再作成することが可能になります。データベースが破損する、アクセスできない、または使用不可能になるような障害が発生した場合、最新のバックアップをリストアし、ジャーナル内の変更を適用して、障害発生時点のデータベースを再作成できます。物理的整合性の損失を回復するこの技術は、“ロール・フォワード” リカバリと呼びます。また、ジャーナルは不完全なトランザクションをロールバックするためにも使用されます。

ジャーナル状態は、個々のグローバルのプロパティではなく、データベースのプロパティです。データベースのグローバル・ジャーナル状態は、Yes または No のいずれかになります。既定では、作成するすべてのデータベースがジャーナリングされます ([グローバルジャーナル状態] が [Yes])。新規にインストールされた InterSystems IRIS インスタンスでは、IRISAUDIT、IRISSYS、および USER の各データベースはジャーナリングされます。IRISLIB、IRISTEMP、および IRISLOCALDATA の各データベースはジャーナリングされません。IRISTEMP 内のグローバルに対する操作は、ジャーナリングされません。InterSystems IRIS 一時データベースである IRISTEMP に一時グローバルをマッピングしてください。

InterSystems IRIS を起動すると、最後のライト・デーモン・パス以降のすべてのジャーナル・エントリが再適用されます。ユーザは、ライト・デーモンを使用せずにジャーナルの更新を同時に処理するので、この方法によりクラッシュ前の更新の保存を保証します。

ジャーナリングされるデータベースに対するすべての更新を記録するだけでなく、ジャーナルにはトランザクションの一部であるジャーナリングされないデータベースに対するすべての更新も含まれます (主 Set 操作と Kill 操作)。これによって、システムの信頼性が大きく向上します。つまり、回復後、グローバルの更新の中にジャーナルに記録されていないものがあったり、トランザクションの対象にならないものがあったりするために発生する矛盾を防止できます (ローカルでの Set および Kill の操作、およびプロセス・プライベート変数はジャーナルに記録されません)。

クラスタにマウントされたデータベースのグローバル処理をジャーナリングするかどうかは、データベース設定によって決まります。ローカル InterSystems IRIS インスタンスでは、リモート・ノードのグローバルのトランザクション処理はジャーナルしません。ネットワーク構成の場合、ジャーナリングは、グローバルが実際に格納されているノードをサポートしますが、Set または Kill コマンドを要求したノードはサポートしません。したがって、ノード B がノード A の要求で Set コマンドを実行する場合、ジャーナル・エントリは、ノード A ではなく、ノード B のジャーナルに表示されます。

ジャーナリングとライト・イメージ・ジャーナリングの違い

InterSystems IRIS ジャーナルとライト・イメージ・ジャーナル (WIJ) とを混同しないでください。WIJ の詳細は、"ライト・イメージ・ジャーナリングとリカバリ" を参照してください。ジャーナリングとライト・イメージ・ジャーナリングでは、以下のように機能が異なります。

• ジャーナリングでは、データベースに既に書き込まれているデータベースの変更がすべて記録されます。一部の変更が (例えば、リカバリされたデータベースの最新のバックアップ後に行われたために) 消失した場合は、ジャーナル・ファイルの内容をリストアすることで、データベースに変更をリストアします。

• ライト・イメージ・ジャーナリングでは、データベースにまだ書き込まれていないデータベースの変更がすべて記録されます。システム・クラッシュが発生すると、ライト・イメージ・ジャーナルの内容は、再起動時に自動的にデータベースに書き込まれます。

データベースの整合性の保護

インターシステムズのリカバリ・プロセスは、最大限の保護機能を提供するよう設計されています。

• これには、“ロール・フォワード” 技術が使用されています。システム障害が発生した場合、実行途中の更新はリカバリ機能によって最後まで実行されます。対照的に、他のシステムの中には、回復のために更新を元に戻す、“ロール・バック” 方法を採用するシステムもあります。どちらの方法も内部整合性を保護しますが、InterSystems IRIS は、ロール・フォワード技術を使用することで、データの損失を減少させます。

• 更新順序を保護します。リカバリ後のデータベースに更新が存在する場合、先行するすべての更新も実行されます。更新順序を適切に保護しない他のシステムは、内部的な一貫性を保っていますが、論理的には無効なデータベースになります。

• データベースだけでなく、インクリメンタル・バックアップ・ファイル構造を保護します。クラッシュ後のリカバリに続き、有効なインクリメンタル・バックアップを実行できます。

トランザクションの自動ジャーナリング

InterSystems IRIS アプリケーションでは、トランザクションと呼ばれる作業ユニットを定義できます。InterSystems IRIS のトランザクション処理では、ジャーナルを使用してトランザクションを格納します。InterSystems IRIS では、影響を受けるグローバルが含まれるデータベースのグローバル・ジャーナル状態設定に関係なく、トランザクションに含まれるグローバルの更新がすべてジャーナルされます。

以下の目的で、コマンドを使用します。

• トランザクションの開始を指示

• トランザクションが通常に終了した場合、トランザクションをコミット

• トランザクション中にエラーが発生した場合、トランザクションをロールバック

InterSystems IRIS は、多くの SQL トランザクション処理コマンドをサポートします。これらのコマンドの詳細は、"トランザクション処理" を参照してください。

不完全トランザクションのロールバック

トランザクションが完了していない場合、ジャーナル・エントリを使用してトランザクションはロールバックされ、関連するグローバルはトランザクション実行前の値に戻ります。InterSystems IRIS は、データベース更新の一環として、ジャーナルに変更を適用してジャーナル・リストアを実行し、不完全なトランザクションをロールバックします。これは以下の条件で発生します。

• システム・クラッシュ後の InterSystems IRIS 起動で発生するリカバリ中

• トランザクション進行中にプロセスを一時停止した場合

• 管理ポータルの [プロセス] ページ ([システム処理]→[プロセス]) から [終了] オプションを使用してプロセスを終了した場合。Job コマンドによって開始されたプロセスを終了した場合、その中の不完全なトランザクションは自動的にロールバックされます。ユーザ・プロセスを終了すると、システムはユーザにメッセージを送信し、不完全なトランザクションをコミットするかロールバックするかを尋ねます。

アプリケーションにロールバック・コードを記述できます。アプリケーションそのものが問題を検出し、ロールバックを要求します。普通、これはアプリケーション・エラーに続くエラー処理ルーチンで実行します。

詳細は、"アプリケーションでのトランザクション管理" を参照してください。

データベースをジャーナリングしない場合の影響

ジャーナリングされないデータベースは、InterSystems IRIS の起動時にジャーナル・リカバリおよびトランザクション・ロールバックに参加しません。結果として、障害、バックアップ・リストア、および再起動後に以下の条件が適用されます。

• ジャーナリングされないデータベースに対する最新の更新が失われる可能性があります。これらのデータベース内のデータは、ジャーナリングされたデータベース内のデータより前の時点を表します。

• ジャーナリングされないデータベース内のトランザクションまたはトランザクションの一部が、部分的にコミットされた状態になる可能性があります。同期コミット・トランザクションにより提供される持続性は、ジャーナリングされないデータベースには適用されません。

• トランザクションの一部であるジャーナリングされないデータベースに対する更新がジャーナリングされると、これらのジャーナル・レコードは通常の操作中にトランザクションをロールバックするためにのみ使用されます。これらのジャーナル・レコードは、起動時にトランザクションをロールバックする手段にはならず、起動時またはバックアップ・リストア後にデータを回復するために使用することもできません。

ジャーナル書き込みサイクル

ジャーナル・バッファの内容をジャーナル・ファイルに書き込む操作は、ジャーナル同期と呼ばれます。ジャーナル同期により、現在ジャーナル・バッファ内にあるすべての操作が現在のジャーナル・ファイルに確実に書き込まれます。

ジャーナルが同期される頻度は、関連する InterSystems IRIS インスタンスの動作状況によって異なります。ジャーナル同期は、次の場合にトリガされる可能性があります。

• システムがアイドルの場合 2 秒ごとに 1 回トリガされる。

• ECP ベースの分散キャッシュ・クラスタでは、アプリケーション・サーバからの特定の要求 (例えば、$Increment) に応答して ECP のセマンティックスを保証する場合にデータ・サーバによってトリガされる。

• InterSystems IRIS トランザクションを使用している場合、TCOMMIT によってトリガされる (同期コミット・モードであるため、このトランザクションに関連するデータがディスクにフラッシュされる)。

• 各データベース書き込みサイクルの一部として書き込みデーモンによってトリガされる。

• ジャーナル・バッファがフルの場合にトリガされる。

ジャーナル・ファイルとジャーナル履歴ログ

ジャーナル・ファイルは プライマリ・ジャーナル・ディレクトリ (既定では、install-dir\Mgr\journal) に格納され、ジャーナル履歴ログ・ファイルである install-dir\Mgr\journal.log に記録されます。このログ・ファイルには、インスタンスで管理されているすべてのジャーナル・ファイルのリストが含まれています。ジャーナルに関連するすべての機能、ユーティリティ、および API では、このログを使用してジャーナル・ファイルを探します。

ジャーナル履歴ログ・ファイルは以下のように更新されます。

• 新規のジャーナル・ファイルが作成されると、エントリがログに追加されます。

• エントリで識別されるジャーナル・ファイルが存在しなくなっていて、エントリの経過日数が 30 日以上の場合、エントリは定期的にファイルの先頭から順に削除されます。エントリがこの 2 つの条件に該当しない場合、削除は行われません。

バックアップからのリストアに続いて実行するジャーナルのリストアで必要になったときに必ず利用できるように、journal.log ファイルをバックアップ方針に取り入れることをお勧めします。バックアップとリストアの方針および手順に関する詳細は、"バックアップとリストア" を参照してください。

journal.log ファイルが存在しない場合 (例えば、破損によりファイル名を変更した場合)、システムでは新規ジャーナル・ファイル作成の際に新しいログ・ファイルが作成されますが、このログ・ファイルにはその作成時点以後に作成されたジャーナル・ファイルのみが記録されるので、以前のジャーナル・ファイルについての情報は失われます。journal.log ファイルを使用するジャーナル関連の機能、ユーティリティ、および API では、このログ・ファイルに記録されていないジャーナル・ファイルは利用できません。一方、ジャーナルをリストアするとき、journal.log ファイルが存在しない場合または既存のログ・ファイルを使用しない場合は、手動でジャーナル・ファイルを指定できます ("^JRNRESTO を使用したジャーナル・ファイルからのグローバルのリストア" を参照してください)。

また、journal.log ファイルを使用して、以下のように別の場所へのジャーナル・ファイルの移行やリストアも可能です。

1. ターゲットとしている InterSystems IRIS インスタンスで、install-dir\Mgr ディレクトリ以外の場所に、ジャーナル・ファイルおよび journal.log ファイルをコピーします。

2. ターゲット・システム上で ^JRNRESTO ルーチンを実行し、ジャーナル・ファイルの元のパスに関するプロンプトへの応答で「No」を入力します。

3. 表示されるプロンプトに従って、コピーしたジャーナル・ファイルおよび journal.log ファイルのターゲット・システム上での格納場所を指定します。^JRNRESTO では、このログ・ファイルを使用して、ターゲット・システムへ移行またはリストアするジャーナル・ファイルの範囲を検証します。

4. "^JRNRESTO を使用したジャーナル・ファイルからのグローバルのリストア" の説明に従って、プロセスを完了します。

一時グローバルと IRISTEMP の使用

IRISTEMP データベースにマップされているものはジャーナルされません。

ネームスペース内のグローバルはそれぞれ別々のデータベースにマッピングされている可能性もあるため、一部はジャーナルに記録され、他は記録されないということもあります。グローバルがマップされているデータベースのジャーナル・プロパティによって、InterSystems IRIS がそのグローバル処理をジャーナルするかどうかが決まります。IRISTEMP とジャーナル・プロパティが [No] に設定されているデータベースとの違いは、IRISTEMP では、トランザクションの更新も含めて何もジャーナルされないことです。

ジャーナリングから新規 z/Z* グローバルを除外する必要がある場合は、それらのグローバルを、ジャーナル・プロパティを [No] に設定してデータベースにマップします。ジャーナリングから z/Z* グローバルを常に除外するには、すべてのネームスペース内の z/Z* グローバルを IRISTEMP データベースにマップする必要があります。

"一時グローバルと IRISTEMP データベース" も参照してください。

ジャーナル管理のクラスとグローバル

ジャーナリングで使用できるメソッドとクエリの詳細は、"%SYS.Journal.SystemOpens in a new tab" クラスに関するドキュメントを参照してください。これは %SYS.Journal パッケージに収められています。

また、InterSystems IRIS では、^%SYS(“JOURNAL”) グローバル・ノードを使用してジャーナル・ファイルに関する情報を格納します。以下に例を示します。

• ^%SYS("JOURNAL","ALTDIR") は、代替ジャーナル・ディレクトリ名を格納します。

• ^%SYS("JOURNAL","CURDIR") は、現在のジャーナル・ディレクトリ名を格納します。

• ^%SYS("JOURNAL","CURRENT") は、ジャーナルの状態とジャーナル・ファイル名を格納します。

この情報は、管理ポータルの [グローバル] ページ ([システム・エクスプローラ]→[グローバル]) で表示できます。

関連項目

• ジャーナリングの構成

• 基本的なジャーナリング操作

• ジャーナリング・ユーティリティ

• ジャーナル入出力エラー

• ジャーナリングに関する特別な考慮事項