|
|
以下の節では、トランザクションの管理に使用される管理タスクに関する情報を提供します。
統計およびモニタの機能を使用して、サーバ上のトランザクションをモニタできます。Administration Console では、それらの機能をコンフィグレーションしたり、結果出力を表示したりできます。
Administration Console で、ドメイン内の各サーバのトランザクションをモニタできます。トランザクションの統計は、ドメイン全体ではなく、特定のサーバについて表示されます。
手順については、Administration Console オンライン ヘルプの以下のページを参照してください。
ヒューリスティックな終了 (ヒューリスティックな決定) は、更新をコミットまたはロールバックする分散トランザクションの終了段階で、リソースが一方だけの決定を行ったときに発生します。これにより、分散されたデータは不確定な状態のままになります。ヒューリスティックな終了の原因としては、ネットワークの障害またはリソースのタイムアウトが考えられます。ヒューリスティックな終了が発生すると、以下のヒューリスティックな結果例外のいずれかが送出されます。
HeuristicRollback - トランザクションに参加する 1 つのリソースが、準備してコミットの決定を待つことに同意しているにもかかわらず、処理のロールバックを自発的に決定した場合。トランザクション マネージャがトランザクションのコミットを決定すると、そのリソースによるヒューリスティックなロールバックの決定は不正になり、トランザクションの他のブランチはコミットされるため、矛盾した結果を招きます。 HeuristicCommit - トランザクションに参加する 1 つのリソースが、準備してコミットの決定を待つことに同意しているにもかかわらず、処理のコミットを自発的に決定した場合。トランザクション マネージャがトランザクションのロールバックを決定すると、そのリソースによるヒューリスティックなコミットの決定は不正になり、トランザクションの他のブランチはロールバックされるため、矛盾した結果を招きます。 HeuristicMixed - トランザクションで、参加リソースの一部がコミットし、一部がロールバックするという混合した結果になったことを、トランザクション マネージャで認識している場合。主に、1 つまたは複数の参加リソースが、ヒューリスティックなロールバックまたはヒューリスティックなコミットを決定したことが原因で発生します。 HeuristicHazard - トランザクションで、参加リソースの一部がコミットし、一部がロールバックするという混合した結果になった可能性があることを、トランザクション マネージャで認識している場合。ただし、システムまたはリソースに障害があるため、HeuristicMixed の結果が確かに発生したかどうかを確認できません。主に、1 つまたは複数の参加リソースが、ヒューリスティックなロールバックまたはヒューリスティックなコミットを決定したことが原因で発生します。
ヒューリスティックな終了が発生すると、サーバ ログにメッセージが書き込まれます。ヒューリスティックな終了を解決する方法については、データベース ベンダが提供するドキュメントを参照してください。
一部のリソース マネージャでは、ヒューリスティックな終了のコンテキスト情報が保存されます。この情報は、リソース マネージャのデータの矛盾を解決するときに便利です。WebLogic Console の JTA パネルで ForgetHeuristics 属性が選択されている (true に設定されている) 場合、この情報はヒューリスティックな終了の後で削除されます。コンテキスト情報を保存するリソース マネージャを使用するときには、ForgetHeuristics 属性を false に設定することをお勧めします。
サーバ インスタンスは、その URL (IP アドレスまたは DNS 名にリスン ポートの番号を付加したもの) によって特定されます。サーバを新しいマシンに移動したり、同じマシン上でサーバのリスン ポートを変更したりした結果 URL が変わると、サーバを移動したことになり、トランザクション ログに保持されている情報ではサーバを特定できなくなる場合があります。
AbandonTimeoutSeconds パラメータの値を超えるまでの間延期できます。詳細については、「トランザクションの破棄」を参照してください。AbandonTimeoutSeconds の値を超えるまでの間、コミットまたはロールバックのリクエストを試行します。詳細については、「トランザクションの破棄」を参照してください。
移植性を向上させるため、サーバ インスタンスには IP アドレスではなく DNS 名を使用することをお勧めします。
サーバを新しいマシンに移動する必要がある場合は、「クラスタ化されていないサーバで障害が発生した場合のトランザクションの回復」を参照してください。
指定した時間の経過後に未完了のトランザクションを破棄することもできます。分散トランザクションの 2 フェーズ コミット プロセスでは、トランザクション マネージャはトランザクションに参加するすべてのリソース マネージャを調整します。すべてのリソース マネージャがコミットまたはロールバックを支持すると、トランザクション マネージャはリソース マネージャに、変更に対してコミットまたはロールバックのいずれかの動作を行うよう通知します。2 フェーズ コミット プロセスにおける、この第 2 フェーズでは、トランザクション マネージャはすべてのリソース マネージャでトランザクションの終了が示されるまで、トランザクションを終了しようとし続けます。AbandonTimeoutSeconds 属性を使用すると、トランザクション マネージャがコミット プロトコルの第 2 フェーズでトランザクションの終了を試み続ける最長時間を秒単位で設定できます。デフォルト値は 86400 秒、つまり 24 時間です。この時間を過ぎると、利用できないリソースや、トランザクションの結果を承認できないリソースが関わるトランザクションでそれ以上の解決は行われません。破棄される前にトランザクションの準備が完了していた場合、トランザクション マネージャは破棄されるトランザクションに代わってトランザクションをロールバックし、ロックを解放してから、サーバ ログにヒューリスティック エラーを書き込みます。
AbandonTimeoutSeconds 属性の設定手順については、Administration Console オンライン ヘルプの「JTA のコンフィグレーション」を参照。
WebLogic Server のトランザクション マネージャは、ユーザによる最低限の介入でシステムのクラッシュから回復するように設計されています。トランザクション マネージャは、クラッシュが何度も発生した後や、クラッシュの回復中であっても、リソース マネージャによって準備されたトランザクション ブランチをコミットまたはロールバックによって解決するために、あらゆる努力を払います。
クラッシュ後の回復を容易にするため、WebLogic Server ではトランザクション回復サービスを提供しています。このサービスでは、システムの起動時にトランザクションの回復が自動的に行われます。「クラッシュ後のトランザクション回復サービスのアクション」で説明するように、トランザクション回復サービスは、起動時にすべてのトランザクション ログ レコードを解析して未完了のトランザクションを見つけ、そのトランザクションを終了させます。
トランザクション回復サービスは、クラッシュ後にトランザクションの回復を正常に処理するよう設計されているため、サーバがクラッシュした場合は再起動し、トランザクション回復サービスによって未完了のトランザクションを処理することをお勧めします。
サーバがクラッシュして、適切な時間内に再起動できそうにない場合は、ユーザによる処理が必要になることがあります。サーバの障害発生後にトランザクションを回復する手順は、WebLogic Server の環境によって異なります。クラスタ化されていないサーバの場合は、手動でサーバ (およびデフォルト永続ストアの DAT ファイル) を別のシステム (マシン) に移動することでトランザクションを回復できます。詳細については、「クラスタ化されていないサーバで障害が発生した場合のトランザクションの回復」を参照してください。クラスタ内のサーバについては、同じクラスタ内の別のサーバに、サーバ全体またはトランザクション回復サービスを手動で移行できます。トランザクション回復サービスの移行には、トランザクションを回復するためのトランザクション ログにアクセスできるサーバを選択し、次に Administration Console または WebLogic コマンドライン インタフェースを使用してサービスを移行することが必要です。
| 注意 : | クラスタ化されていないサーバの場合は、サーバ全体を新しいシステムに移動することしかできません。クラスタ化されたサーバの場合は、サーバ全体を移行することも、トランザクション回復サービスを一時的に移行することも可能です。 |
トランザクション回復サービスの移行の詳細については、「クラスタ化されたサーバで障害が発生した場合のトランザクションの回復」を参照してください。クラスタの詳細については、『クラスタの使用』を参照してください。
以下の節では、障害発生後にトランザクションを回復する方法についての情報を提供します。
クラッシュ後にサーバを再起動したり、トランザクション回復サービスを別の (バックアップ) サーバに移行したりすると、トランザクション回復サービスは以下の処理を行います。
コミットの決定が行われたが 2 フェーズ コミット プロセスの第 2 フェーズが終了していないトランザクション (トランザクション ログに記録されているトランザクション) については、トランザクション回復サービスがコミット プロセスを終了させます。
トランザクション マネージャによってリソース マネージャとの準備が整っているトランザクション (2 フェーズ コミット プロセスの第 1 フェーズのトランザクション) の場合、トランザクション回復サービスはクラッシュ回復中に、各リソース マネージャに対して XAResource.recover() を呼び出す必要があります。次に、commit()、rollback()、または forget() メソッドを呼び出すことで、recover() によって返されたすべてのトランザクション ID を最終的に解決します。
リソース マネージャによってヒューリスティックな例外が報告されると、トランザクション回復サービスはそのヒューリスティックな例外をサーバ ログに記録し、[ヒューリスティックを無視] コンフィグレーション属性が有効になっている場合は、forget() を呼び出します。[ヒューリスティックを無視] コンフィグレーション属性が有効になっていない場合は、データベース ベンダのマニュアルでヒューリスティックな終了の解決に関する情報を参照してください。詳細については、「ヒューリスティックな終了の処理」を参照してください。
トランザクション回復サービスには、次のような利点があります。
トランザクション回復サービスは、一貫した予測しやすい方法でトランザクション回復処理を行います。クラッシュ前にコミットが決定されたがまだ行われておらず、XAResource.recover() からトランザクション ID が返されるトランザクションの場合、トランザクション回復サービスは一貫して XAResource.commit() を呼び出します。クラッシュ前にコミットが決定しておらず、XAResource.recover() からトランザクション ID が返されるトランザクションの場合、トランザクション回復サービスは一貫して XAResource.rollback() を呼び出します。トランザクションの回復が一貫性のある予測しやすいものであるため、トランザクション マネージャがクラッシュしても、一部のブランチがコミットされ一部がロールバックされるという混合ヒューリスティックの終了は発生しません。
リソース マネージャがクラッシュすると、トランザクション回復サービスでは準備されている各トランザクションについて commit() または rollback() を呼び出さなければなりません。commit() または rollback() の呼び出しは成功するまで続けられます。トランザクション解決の試行は、AbandonTimeoutSeconds コンフィグレーション属性を設定することで制限できます。詳細については、「トランザクションの破棄」を参照してください。
障害が発生したサーバでトランザクションを回復するには、次の手順に従います。
サーバに障害が発生した後でトランザクション ログ レコードを移動する場合は、すべてのトランザクション ログ レコードを新しいマシンで使用可能にしてから、そのマシンでサーバを起動します。そうしないと、クラッシュ時にコミット中だったトランザクションが適切に解決できず、その結果、アプリケーション データに矛盾が発生する場合があります。このような移行は、両方のマシンで使用可能なデュアル ポート ディスクに永続ストアのデータ ファイルを格納することで実現できます。計画的な移行の場合は、新しいマシンでパス名が異なるときに、デフォルトのファイル ストアの directory 属性を新しいパス名で更新してからサーバを起動します。
| 注意 : | トランザクション回復サービスは、クラッシュ後にトランザクションの回復を正常に行うために設計されたものです。サーバがクラッシュした場合は、新しいマシンにサーバを移動するよりも、サーバを再起動し、トランザクション回復サービスによって未完了のトランザクションを処理することをお勧めします。 |
クラスタ化されたサーバで障害が発生した場合、以下のいずれかの方法でトランザクションを回復できます。
クラスタ化されたサーバの場合、WebLogic Server では、トランザクション回復サービスを含めて、障害が発生したサーバを新しいマシンに移行できます。サーバを別のマシンに移行する場合、トランザクションを完了または回復するには、サーバがトランザクション ログ レコードを見つけられるようにする必要があります。トランザクション ログ レコードは、サーバのデフォルト永続ストアに格納されています。障害が発生したときに、クラスタ化されたサーバを移行する計画がある場合は、障害が発生した移行可能なサーバの移行先となり得る任意のマシンにアクセスできる、共有ストレージ システムにレコードを格納するよう、デフォルト永続ストアを設定する必要があります。高い信頼性を実現するために、ストレージ エリア ネットワーク (SAN) などの、高可用性の備わっている共有ストレージ ソリューションを使用してください。
サーバの移行については、『クラスタの使用』の「サーバ全体の移行」を参照してください。
デフォルト永続ストア オプションの設定の詳細については、以下を参照してください。
クラスタ化されたサーバがクラッシュした場合は、Administration Console またはコマンドライン インタフェースを使用して、同じクラスタ内でクラッシュしたサーバから別のサーバへ、トランザクション回復サービスを手動で移行できます。Administration Console を使用してトランザクション回復サービスを手動で移行する手順については、Administration Console オンライン ヘルプの「トランザクション回復サービスの手動移行」を参照してください。
シングルトン サービスの WebLogic Server ヘルス モニタを使用して、トランザクション回復サービスが正常な候補サーバに自動的に移行されるようにコンフィグレーションすることも可能です。「トランザクション回復サービスの自動移行」を参照してください。
手動または自動のサービス移行が実施されると、以下のイベントが発生します。
サーバでは、障害が発生した複数のサーバに対してトランザクション回復を行うことができます。他のサーバのトランザクションを回復している間に、バックアップ サーバは自身のトランザクションの処理および回復を続けます。回復中にバックアップ サーバで障害が発生した場合は、さらに別のサーバにトランザクション回復サービスを移行できます。この別のサーバで、トランザクション回復は続行されます。また、Administration Console またはコマンドライン インタフェースを使用して、トランザクション回復サービスを元の障害が発生したサーバに手動で移行して戻すこともできます。詳細については、「トランザクション回復サービスの元のサーバへの手動による返還移行」を参照してください。
サーバのトランザクション回復がバックアップ サーバで完了すると、バックアップ サーバではトランザクション回復サービスの所有権が、障害が発生したサーバに解放されます。障害が発生したサーバを再起動すると、このサーバはトランザクション回復サービスの所有権を再び要求しようとします。障害が発生したサーバを再起動したときに、バックアップ サーバがトランザクション回復処理中だった場合、バックアップ サーバはトランザクションの回復を中止し、内部クリーンアップを行い、トランザクション回復サービスの所有権を解放して、障害が発生したサーバがそれを再び要求して正しく起動できるようにします。その後、障害が発生したサーバでは、自身のトランザクション回復を完了します。
障害が発生したサーバのトランザクション回復サービスがまだバックアップ サーバで所有されており、障害が発生したサーバを再起動しようとしたときにバックアップ サーバが非アクティブだった場合、バックアップ サーバがトランザクション回復サービスの所有権を解放できないため、障害が発生したサーバは起動しません。これは、フェイルバック メカニズムが失敗した場合や、バックアップ サーバが管理サーバと通信できない場合にも当てはまります。トランザクション回復の移行は、Administration Console またはコマンドライン インタフェースを使用して手動で行えます。
サーバ ヘルス モニタ サービスを使用することで、トランザクション回復サービスを異常のあるサーバ インスタンスから正常なサーバ インスタンスに自動的に移行できます。これにより、障害が発生したサーバのトランザクション処理をバックアップ サーバで完了できます。『クラスタの使用』の「JTA トランザクション回復サービスの自動移行をコンフィグレーションする手順」を参照してください。
WebLogic Server 10.0 より前のリリースでは、クラスタのプライマリ管理対象サーバの起動時に管理サーバにアクセスできない場合 (ほとんどの場合は管理サーバがまだ起動していないことが原因)、プライマリ管理対象サーバは自動的に管理対象サーバ独立 (MSI) モードに移行し、ローカルのコンフィグレーション情報を使用して起動を続行していました。この状況では、トランザクション回復サービスを手動で移行している間、プライマリ管理対象サーバの代わりにバックアップ サーバでまだ TLOG データを回復中である可能性があり、これらのサーバが TLOG に同時にアクセスして TLOG が破損するリスクがありました。
このリスクを回避するためのプロパティが、JTAMigratableTargetMBean の strictOwnershipCheck です。このプロパティを使用することで、プライマリ管理対象サーバの起動中に管理サーバ (JTA 手動移行ポリシーの場合) またはシングルトン マスター (JTA 自動移行ポリシーの場合) に接続できないことが判明すると、以下に示すように strictOwnershipCheck の値に従って管理対象サーバの独立性が検証されるようになりました。
トランザクション回復サービスを自動または手動で移行する場合は、以下の制限があります。
以上の制限に加え、WebLogic Server 10.0 でトランザクション回復サービスが自動的に移行されるようにコンフィグレーションする場合は以下のルールも適用されます。
クラスタ内の障害が発生したサーバから同じクラスタ内の別のサーバ (バックアップ サーバ) へトランザクション回復サービスを移行するには、バックアップ サーバに、障害が発生したサーバのトランザクション ログ レコードへのアクセス権が必要です。したがって、デフォルト永続ストアのデータ ファイルを、クラスタ内でバックアップ サーバとなり得るすべてのサーバが利用可能な永続ストレージに格納する必要があります。ストレージ エリア ネットワーク (SAN) デバイスまたはデュアル ポート ディスクに、トランザクション ログ レコードを格納することをお勧めします。NFS ファイル システムを使ってトランザクション ログ レコードを保存しないでください。NFS のキャッシング方式により、ディスク上のファイルが常に最新ではないことがあるためです。NFS デバイス上に格納されたトランザクション ログ レコードを回復のために使用すると、データが破損するおそれがあります。
トランザクション回復サービスを自動または手動で移行する際は、永続ストアに関する以下のルールが適用されます。
プライマリ サーバが起動、フェイルオーバ、またはフェイルバックする際には、管理サーバがアクセス可能な状態になっている必要があります。これは、トランザクション回復サービスが、その TLOG の排他的な所有権を衝突なく適切に取得できるようにするためです。プライマリ サーバの起動時には、トランザクション回復サービスが管理サーバに接続し、JTA に関する最新の情報を取得します。フェイルオーバやフェイルバックが発生した場合は、トランザクション回復サービスがその最新情報を管理サーバに保存します。
トランザクション回復サービスをサーバから移行するときには、実際に移行を行う前に障害が発生している、または障害が発生したサーバを停止する必要があります。元のサーバがまだ実行中の場合は、そこからトランザクション回復サービスを移行することはできません。
移行に参加するサーバはすべて、コンフィグレーションにおいてリスン アドレスが指定されている必要があります。Administration Console オンライン ヘルプの「リスン アドレスのコンフィグレーション」を参照してください。
クラスタ内のサーバに対してトランザクション回復サービスのバックアップ サーバとして使用するサーバの選択肢を制限することもできます。たとえば、クラスタ内のすべてのサーバがサーバのトランザクション ログ レコードにアクセスできるとは限りません。Administration Console の [サーバ : コンフィグレーション : 移行] ページで、使用可能な送り先サーバを制限できます。手順については、「トランザクション回復サービスの移行先とする候補サーバのコンフィグレーション」を参照してください。
| 注意 : | 必要に応じてトランザクション回復サービスを手動で移行して元のサーバに戻せるように、[選択済み] リストに移行元のサーバを含めておく必要があります。Administration Console では、この規則に従わなくてはなりません。 |
トランザクション回復サービスをクラスタ内の別のサーバに移行した場合、そのトランザクション回復サービスの所有権は、未完了のトランザクションがすべて完了するまでバックアップ サーバに割り当てられます。トランザクションの完了後、バックアップ サーバはトランザクション回復サービスの所有権を解放し、元のサーバは所有権の返還を要求できます。Administration Console の [サーバ : 制御 : 移行] ページで、現在のオーナーを参照できます。次の手順に従います。
バックアップ サーバは、障害が発生したサーバのトランザクションの回復が完了すると、トランザクション回復サービスの所有権を解放します。そのため、元のサーバは再起動時にその所有権の返還を要求できます。トランザクションの回復が完了する前に何らかの理由でバックアップ サーバが停止 (クラッシュ) すると、元のサーバはトランザクション回復サービスの所有権の返還を要求できなくなり、起動しません。
また、移行先サーバとして元のサーバを選択すると、トランザクション回復サービスを手動で移行して元のサーバに戻すことができます。元のサーバにトランザクション回復サービスを手動で移行して返還するときには、バックアップ サーバが稼動していてはいけません。次の手順に従います。
| 注意 : | 以下の点に注意してください。 |
Administration Console を使用してトランザクション回復サービスを手動で移行する手順については、Administration Console オンライン ヘルプの「トランザクション回復サービスの移行」を参照してください。
  
|