| Oracle® Fusion Middleware Oracle WebLogic Server JTAアプリケーションの開発 12c (12.2.1.3.0) E90356-04 |
|
 前 |
 次 |
統計およびモニターの機能を使用して、サーバー上のトランザクションをモニターできます。管理コンソールでは、それらの機能を構成したり、結果出力を表示したりできます。
管理コンソールを使用して、ドメイン内の各サーバーのトランザクションをモニターします。トランザクションの統計は、ドメイン全体ではなく、特定のサーバーについて表示されます。
手順については、Oracle WebLogic Server管理コンソール・オンライン・ヘルプにある次のページを参照してください。
ヒューリスティックな終了が発生すると、以下のヒューリスティックな結果例外のいずれかがスローされます。
HeuristicRollback - トランザクションに参加する1つのリソースが、準備してコミットの決定を待つことに同意しているにもかかわらず、処理のロールバックを自発的に決定した場合。トランザクション・マネージャがトランザクションのコミットを決定すると、そのリソースによるヒューリスティックなロールバックの決定は不正になり、トランザクションの他のブランチはコミットされるため、矛盾した結果を招きます。
HeuristicCommit - トランザクションに参加する1つのリソースが、準備してコミットの決定を待つことに同意しているにもかかわらず、処理のコミットを自発的に決定した場合。トランザクション・マネージャがトランザクションのロールバックを決定すると、そのリソースによるヒューリスティックなコミットの決定は不正になり、トランザクションの他のブランチはロールバックされるため、矛盾した結果を招きます。
HeuristicMixed - トランザクションで、参加リソースの一部がコミットし、一部がロールバックするという混合した結果になったことを、トランザクション・マネージャで認識している場合。主に、1つまたは複数の参加リソースが、ヒューリスティックなロールバックまたはヒューリスティックなコミットを決定したことが原因で発生します。
HeuristicHazard - トランザクションで、参加リソースの一部がコミットし、一部がロールバックするという混合した結果になった可能性があることを、トランザクション・マネージャで認識している場合。ただし、システムまたはリソースに障害があるため、HeuristicMixedの結果が確かに発生したかどうかを確認できません。主に、1つまたは複数の参加リソースが、ヒューリスティックなロールバックまたはヒューリスティックなコミットを決定したことが原因で発生します。
ヒューリスティックな終了が発生すると、サーバー・ログにメッセージが書き込まれます。ヒューリスティックな終了を解決する方法については、データベース・ベンダーが提供するドキュメントを参照してください。
一部のリソース・マネージャでは、ヒューリスティックな終了のコンテキスト情報が保存されます。この情報は、リソース・マネージャのデータの矛盾を解決するときに便利です。WebLogic Server管理コンソールの「JTA」パネルでForgetHeuristics属性が選択されている(trueに設定されている)場合、この情報はヒューリスティックな終了の後で削除されます。コンテキスト情報を保存するリソース・マネージャを使用するときには、ForgetHeuristics属性をfalseに設定することをお薦めします。
サーバー・インスタンスは、そのURL (IPアドレスまたはDNS名にリスニング・ポートの番号を付加したもの)によって特定されます。サーバーを新しいマシンに移動したり、同じマシン上でサーバーのリスニング・ポートを変更したりした結果URLが変わると、サーバーを移動したことになり、トランザクション・ログに保持されている情報ではサーバーを特定できなくなる場合があります。
新しいサーバーのURLが古いサーバーと同じである場合、トランザクション・リカバリ・サービスは、すべてのトランザクション・ログ・ファイルを解析して未完了のトランザクションを見つけ、そのトランザクションを終了させます。詳細については、「クラッシュ後のトランザクション・リカバリ・サービスのアクション」を参照してください。
コーディネータ・サーバーがサブコーディネータと同じドメイン内に存在し、サーバーURLが変更する場合、コーディネータは、サブコーディネータの新しいURLに関して管理サーバーに問合せを行います。新しいトランザクションおよびコミットまたはロールバック中のすべてのトランザクションの伝播では、新しいURLを使用します。URLの変更がリカバリ不能になる前に、トランザクションは、保留中のコミット・レコードがコーディネータのトランザクション・ログ・ファイルに格納されている状態でサブコーディネータに分岐します。コーディネータのトランザクション・ログ・ファイルは適宜削除できます。この手順により、AbandonTimeoutSecondsパラメータの値を超えるまで、トランザクション・リカバリ・サービスはこれらのトランザクションを解決できません。「トランザクションの破棄」および「トランザクション・レコードの削除方法」を参照してください。
トランザクションが複数のドメインにまたがり、リモート・トランザクションのサブコーディネータとして機能するサーバーに障害が発生してそのURLが変更になった場合は、コーディネータがリモート・ドメインの管理サーバーと通信できなくなるため、実行中のどのトランザクションも完了しません(コミットまたはロールバックされます)。コーディネータは、新しいURLを使用してサブコーディネータと通信できなくなり、実行中のトランザクションは失敗します。コーディネータは、AbandonTimeoutSecondsの値を超えるまでリクエストのコミットまたはロールバックを試行します。「トランザクションの破棄」を参照してください。新しいトランザクションは、コーディネータがサブコーディネータと通信できないため、失敗します。移行したサーバー・ドメインを除き、コーディネータおよびサブコーディネータのTLogは削除してください。「トランザクション・レコードの削除方法」を参照してください
移植性を向上させるため、サーバー・インスタンスにはIPアドレスではなくDNS名を使用することをお薦めします。
サーバーを新しいマシンに移動する必要がある場合は、「クラスタリングされていないサーバーで障害が発生した場合のトランザクションのリカバリ」を参照してください
指定した時間の経過後に未完了のトランザクションを破棄することもできます。
分散トランザクションの2フェーズ・コミット・プロセスでは、トランザクション・マネージャはトランザクションに参加するすべてのリソース・マネージャを調整します。すべてのリソース・マネージャがコミットまたはロールバックを支持すると、トランザクション・マネージャはリソース・マネージャに、変更に対してコミットまたはロールバックのいずれかの動作を行うよう通知します。2フェーズ・コミット・プロセスにおける、この第2フェーズでは、トランザクション・マネージャはすべてのリソース・マネージャでトランザクションの終了が示されるまで、トランザクションを終了しようとし続けます。AbandonTimeoutSeconds属性を使用すると、トランザクション・マネージャがコミット・プロトコルの第2フェーズでトランザクションの終了を試み続ける最長時間を秒単位で設定できます。デフォルト値は86400秒、つまり24時間です。この時間を過ぎると、利用できないリソースや、トランザクションの結果を承認できないリソースが関わるトランザクションでそれ以上の解決は行われません。破棄される前にトランザクションの準備が完了していた場合、トランザクション・マネージャは破棄されるトランザクションにかわってトランザクションをロールバックし、ロックを解放してから、サーバー・ログにヒューリスティック・エラーを書き込みます。
AbandonTimeoutSeconds属性の設定手順は、Oracle WebLogic Server管理コンソール・オンライン・ヘルプのJTAの構成に関する項を参照してください。
2フェーズ・コミット・プロトコルの最初のフェーズは準備フェーズと呼ばれます。要求される更新がトランザクション・ログ・ファイルに記録され、リソースは、リソース・マネージャを通じて変更の準備ができていることを表明する必要があります。リソースは、更新をコミットするのか、または前の状態にロールバックするのかを意思表示できます。第2フェーズまたはコミット・フェーズで何が行われるかは、リソースの意思表示によって決まります。すべてのリソースがコミットを支持すると、トランザクションに関わっているすべてのリソースが更新されます。1つまたは複数のリソースがロールバックを支持した場合は、トランザクションに関わっているすべてのリソースが前の状態にロールバックされます。WebLogic Serverには、トランザクションの処理にかかる時間を調整する次のパラメータがあります。
トランザクションの開始から、トランザクションの最初のフェーズの終わりまでの処理にかかる最大時間は、transaction-timeout属性の値を設定して制御します。
トランザクションの第2フェーズの処理にかかる最大時間は、completion-timeout-seconds属性の値を設定して制御します。
WebLogic Server 10.3.3以前では、第2フェーズの処理の最大所要時間は、デフォルトのtransaction-timeoutの値(最大値120秒、調整不可能)の約2倍でした。ほとんどの環境の場合、第2フェーズの完了に割り当てられる時間は十分なものです。ただし、システムの負荷が高い環境やネットワークの待機時間が長い環境では、コミット・フェーズの完了に使用可能な最大時間を超える可能性があり、トランザクション・マネージャはSystemExceptionをスローします。SystemExceptionは、トランザクションの結果に対して決定的ではないため、アプリケーション環境では、この場合の特別な例外処理を用意する必要があります。この例外処理には、トランザクション・アクティビティやトランザクションに関連するリソースの状態を手動で解析する処理も含まれる場合があります。アプリケーション・スタックは、より複雑になるため、トランザクションの結果の解決はさらに難しくなります。completion-timeout-seconds属性では、コミット・フェーズにより長い処理時間を割り当てることで、多くの場合、成功するか決定的な完了になります。
completion-timeout-secondsの値が、abandon-timeout-secondsに設定された値を超えると、abandon-timeout-secondsは、completion-timeout-secondsの値をオーバーライドします。トランザクションを破棄する場合、SystemExceptionがスローされます。一般に、transaction-completion-seconds属性に大きな値が必要なトランザクションは、システムのチューニングが必要になります。
注意:
abandon-timeout-seconds値が60秒未満に設定されている場合は、デフォルトのcompletion-timeout-seconds設定によって無効にされるので注意してください。また、トランザクション・サービスが起動してから最初の600秒(10分)以内に、abandon-timeout-seconds設定は完全に無効になります。
completionTimeoutSecondsの値を-1に指定でき、これにより、2PCの第2フェーズが長時間維持されます。時間サーバーが強制停止する前に待つように、ServerLifeCycleTimeoutValも指定できます。サービスの移行ポリシーがAuto-Migrate Failure-Recovery Servicesに設定されていて、管理者がユーザー優先サーバー(UPS)を停止した場合(正常停止または強制停止)、JTAトランザクション回復サービスはクラスタ内の別のサーバーに移行しません。Weblogic Server 12.2.1.1より前は、JTAトランザクション回復サービスはクラスタ内で別のサーバーに移行していました。この移行は、completionTimeoutSecondsが-1でServerLifeCycleTimeoutValが小さい値(デフォルトは120秒)に設定されているときにのみ発生していました。Weblogic Server 12.2.1.1以降、completionTimeoutSecondsが-1に設定され管理者がサーバーを強制的に停止した場合、2PCの第2フェーズを長時間維持しようとしなくなりました。かわりに、ServerLifeCycleTimeoutValの値に基づいて、2PCの第2フェーズの試行回数を決定します。
構成情報の詳細は次のトピックを参照してください。
Oracle WebLogic Serverの管理コンソール・オンライン・ヘルプの高度なドメインJTAオプションの構成に関する項
Oracle WebLogic Server MBeanリファレンスのCompletionTimeoutSecondsに関する項
注意:
completion-timeout-seconds属性は、JCAトランザクションなどのインポート済トランザクションや、リカバリ・トランザクションには適用されません。
システムまたはネットワークの障害が原因でトランザクションが正常に完了しない場合、保留中のトランザクションのためにロックが保持され、他のトランザクションの進捗を妨げている可能性があります。WebLogic Serverトランザクション・マネージャが内部データ構造からトランザクションを削除するのを待機したり、スタック・トランザクションを手動で解決できます。
「破棄タイムアウト」の期間が経過すると、WebLogic Serverトランザクション・マネージャが内部データ構造からトランザクションを削除し、サーバー・ログにヒューリスティック・エラーを書き込みます。ただし、トランザクションを手動で解決するには、「サーバー」→「モニタリング」→「JTA」タブで、現在(処理中)のトランザクションを確認します(Oracle WebLogic Server管理コンソール・オンライン・ヘルプの現在のトランザクションの表示に関する項を参照)。その後、トランザクションIDをクリックして特定のトランザクションの詳細を表示します。その後、トランザクションのステータスに応じてコミットまたはロールバックを強制できます。
注意:
トランザクションのステータスはサーバーごとに異なることがあります。たとえば、調整を行うサーバーではトランザクションがコミットされていても、リモートの参加者がコミットの指示を受け取っていない場合があります。
次の表は、トランザクションのステータスと解決のオプションに関する情報を示します。
表4-1 トランザクション・ステータスの定義と手動解決のオプション
| ステータス | 定義 | 強制コミット | 強制ロールバック |
|---|---|---|---|
アクティブ |
アプリケーションがトランザクションを処理しています。トランザクションは、まだ2フェーズ・コミット処理には到達していません。 |
Y |
|
準備中 |
トランザクション・マネージャが2PCプロトコルの最初のフェーズでjavax.transaction.Synchronization beforeCompletion()コールバック処理を開始してから、すべての参加者がコミット可能と応答するまでの間隔に対応します。 |
Y |
|
準備完了 |
すべての参加者がコミット・ポイント(コミット・ログ・レコードがディスクにフラッシュされる)に備えるように反応してから、ロールバック処理開始までの間隔です。 |
Y |
Y |
コミット中 |
コミットの決定が行われてから、すべての参加者に結果が通知されて、 |
Y |
|
コミット完了 |
トランザクションがコミットされました。ヒューリスティックが存在する可能性が高いです。あるいは、トランザクションが完了していて、現在のトランザクションのリストに表示されません。 |
Y |
|
ロールバック中 |
この状態になるのは、ロールバック処理が開始されてから、すべての参加者がロールバックを指示されて、 |
Y |
|
ロールバック済 |
トランザクションがロールバックされました。ヒューリスティックが存在する可能性が高いです。あるいは、トランザクションが破棄されていて、現在のトランザクションのリストに表示されません。 |
Y |
|
マーク済ロールバック |
トランザクションがロールバックに関してマークされました。おそらく、setRollbackOnly操作の結果です。 |
Y |
|
トランザクションなし |
|||
不明 |
現在のステータスを判別できません。 |
Y |
Y |
トランザクションを手動で解決するには、次のオプションを選択します。オプションには、表4-1で説明しているような制限があります。
ローカル・コミットの強制: サーバーに登録されている各参加リソースで、特定のトランザクションに対するコミット処理が発行され、トランザクションはローカル・トランザクション・マネージャのデータ構造から削除されます。ローカル・サーバーがトランザクションのコーディネータの場合、コミット・レコードがリリースされます。Oracle WebLogic Server管理コンソール・オンライン・ヘルプのローカル・コミットの強制に関する項を参照してください。
グローバル・コミットの強制: 特定のトランザクションに対するローカル・コミット処理が各参加サーバーで試行されます。このオプションが、調整を行うサーバー以外で起動された場合、コーディネータに処理を行うよう通知されます。調整を行うサーバーは、各参加サーバーに非同期リクエストを発行します。Oracle WebLogic Server管理コンソール・オンライン・ヘルプのグローバル・コミットの強制に関する項を参照してください。
ローカル・ロールバックの強制: ローカル・サーバーに登録されている各参加リソースで、特定のトランザクションに対するロールバック処理が発行されます。トランザクションはローカル・トランザクション・マネージャのデータ構造から削除されます。Oracle WebLogic Server管理コンソール・オンライン・ヘルプのローカル・ロールバックの強制に関する項を参照してください。
グローバル・ロールバックの強制: 特定のトランザクションに対するローカル・ロールバック処理が各参加サーバーで試行されます。このオプションが、調整を行うサーバー以外で起動された場合、コーディネータに処理を行うよう通知されます。調整を行うサーバーは、各参加サーバーに非同期リクエストを発行します。Oracle WebLogic Server管理コンソール・オンライン・ヘルプのグローバル・ロールバックの強制に関する項を参照してください。
注意:
これらのオプションからどれを選択しても、WebLogic Serverによってサーバー・ログにエントリが書き込まれます。
「ローカル」オプションと「グローバル」オプションの違いは、「ローカル」オプションは現在のサーバー・リソース(WebLogic Server管理コンソールの左ペインにあるナビゲーション・ツリーで選択したサーバー上のリソース)にしか作用しないが、「グローバル」オプションは参加しているすべてのサーバーに操作を試みるという点です。グローバル操作が、ローカル・サーバーによって調整されていないトランザクションに対して起動されると、そのトランザクションのコーディネータが操作を実行するように指示されます。コーディネータと通信できない場合、操作はjavax.transaction.SystemExceptionで失敗します。
このケースでは、調整を行うサーバーではトランザクションがコミットされている(コミット済ステータス)ときに、リモートの参加者がコミットの指示を受け取っていません(準備完了ステータス)。リモート参加者でローカル・コミットを強制すると、このトランザクションを完了できます。このケースでは、トランザクションの状態は準備完了のままであるため、リモート参加者でロールバックを強制することもできます。ただし、トランザクションはヒューリスティックに完了します。グローバル・ロールバックの強制を試行すると、コーディネータの状態がコミット中であるため、操作が失敗します。コミット中のステータスではトランザクションをロールバックできません。
WebLogic Serverのトランザクション・マネージャは、ユーザーによる最低限の介入でシステムのクラッシュからリカバリするように設計されています。WebLogic Serverが提供するトランザクション・リカバリ・サービスは、クラッシュが何度も発生した後や、クラッシュのリカバリ中であっても、リソース・マネージャによって準備されたトランザクション・ブランチをコミットまたはロールバックによって解決するために、あらゆる努力を払います。
クラッシュ後のリカバリを容易にするため、トランザクション・リカバリ・サービスでは、システムの起動時にトランザクションのリカバリが自動的に行われます。「クラッシュ後のトランザクション・リカバリ・サービスのアクション」で説明するように、トランザクション・リカバリ・サービスは、起動時にすべてのトランザクション・ログ・レコードを解析して未完了のトランザクションを見つけ、そのトランザクションを終了させます。
トランザクション・リカバリ・サービスは、クラッシュ後にトランザクションのリカバリを正常に処理するよう設計されているため、サーバーがクラッシュした場合は再起動し、トランザクション・リカバリ・サービスによって未完了のトランザクションを処理することをお薦めします。
サーバーがクラッシュして、適切な時間内に再起動できそうにない場合は、ユーザーによる処理が必要になることがあります。サーバーの障害発生後にトランザクションをリカバリする手順は、WebLogic Serverの環境によって異なります。クラスタリングされていないサーバーの場合は、手動でサーバー(およびデフォルト永続ストアのDATファイル)を別のシステム(マシン)に移動することでトランザクションをリカバリできます。「クラスタリングされていないサーバーで障害が発生した場合のトランザクションのリカバリ」を参照してください。クラスタ内のサーバーについては、同じクラスタ内の別のサーバーに、サーバー全体またはトランザクション・リカバリ・サービスを手動で移行できます。トランザクション・リカバリ・サービスの移行には、トランザクションをリカバリするためにトランザクション・ログにアクセスできるサーバーを選択してから、WebLogic Server管理コンソールまたはWebLogicコマンド行インタフェースを使用してサービスを移行するという作業が含まれます。
注意:
クラスタリングされていないサーバーの場合は、サーバー全体を新しいシステムに移動することしかできません。クラスタリングされたサーバーの場合は、サーバー全体を移行することも、トランザクション・リカバリ・サービスを一時的に移行することも可能です。
トランザクション・リカバリ・サービスの移行に関する詳細は、「クラスタリングされたサーバーで障害が発生した場合のトランザクションのリカバリ」を参照してください。クラスタの詳細は、『Oracle WebLogic Serverクラスタの管理』を参照してください。
次の項では、障害発生後にトランザクションをリカバリする方法について説明します。
クラッシュ後にサーバーを再起動したり、トランザクション・リカバリ・サービスを別の(バックアップ)サーバーに移行したりすると、トランザクション・リカバリ・サービスは以下の処理を行います。
2フェーズ・コミットの第2フェーズの準備が整っているトランザクションを終了します。
コミットの決定が行われたが2フェーズ・コミット・プロセスの第2フェーズが終了していないトランザクション(トランザクション・ログに記録されているトランザクション)については、トランザクション・リカバリ・サービスがコミット・プロセスを終了させます。
準備されたトランザクションを解決します。
トランザクション・マネージャによってリソース・マネージャとの準備が整っているトランザクション(2フェーズ・コミット・プロセスの第1フェーズのトランザクション)の場合、トランザクション・リカバリ・サービスはクラッシュ・リカバリ中に、各リソース・マネージャに対してXAResource.recover()を呼び出す必要があります。次に、commit()、rollback()、またはforget()メソッドを呼び出すことで、recover()によって返されたすべてのトランザクションIDを最終的に解決します。
ヒューリスティックな終了を報告します。
リソース・マネージャによってヒューリスティックな例外が報告されると、トランザクション・リカバリ・サービスはそのヒューリスティックな例外をサーバー・ログに記録し、「ヒューリスティックを無視」構成属性が有効になっている場合は、forget()を呼び出します。「ヒューリスティックを無視」構成属性が有効になっていない場合は、データベース・ベンダーのドキュメントでヒューリスティックな終了の解決に関する情報を参照してください。「ヒューリスティックな終了の処理」を参照してください。
注意:
WebLogic Server 12.2.1.3.0より前は、WebLogic JMSリソースが、ドメインにまたがるトランザクションの従属ドメインに登録され、WebLogic JMSリソースが後にトランザクションの完了前に別のサーバーに移行された場合、移行されたWebLogic JMSリソースおよびトランザクションの自動トランザクション・リカバリはWebLogic JMSリソースが元の場所に戻されるまで発生しません。このリカバリは今はサポートされるようになりましたが、このリカバリは既存の処理中のトランザクションの継続性をサポートしません。サーバー・クラッシュによる移行の場合、またはWebLogic JMSが正常に停止しなかった場合、いくつかの例外が発生して、トランザクションがロールバックされる可能性があります。トランザクション・リカバリ・サービスには、次のような利点があります。
複数のリソースにわたって一貫性を維持します。
トランザクション回復サービスは、一貫した予測しやすい方法でトランザクション回復処理を行います。クラッシュ前にコミットが決定されたがまだ行われておらず、XAResource.recover()からトランザクションIDが返されるトランザクションの場合、トランザクション回復サービスは一貫してXAResource.commit()を呼び出します。クラッシュ前にコミットが決定しておらず、XAResource.recover()からトランザクションIDが返されるトランザクションの場合、トランザクション回復サービスは一貫してXAResource.rollback()を呼び出します。トランザクションのリカバリが一貫性のある予測しやすいものであるため、トランザクション・マネージャがクラッシュしても、一部のブランチがコミットされ一部がロールバックされるという混合ヒューリスティックの終了は発生しません。
トランザクションの解決に固執します。
リソース・マネージャがクラッシュすると、トランザクション回復サービスでは準備されている各トランザクションについてcommit()またはrollback()を呼び出さなければなりません。commit()またはrollback()の呼出しは成功するまで続けられます。トランザクション解決の試行は、AbandonTimeoutSeconds構成属性を設定することで制限できます。「トランザクションの破棄」を参照してください。
WebLogicプロキシ・プラグインを備えたApacheをクラスタのフロントエンドとして使用する際、プラグインは複数の構成パラメータを使用して、WebLogic Serverホストへの接続を待機する時間や、接続の確立後は、プラグインがレスポンスを待機する時間を判断します。
Apacheのidempotentフラグの設定を検証します。idempotentがONに設定されているときに、指定したWLIOTimeoutSecs値内でサーバーが応答しない場合は、プラグインがフェイルオーバーします。idempotentがONに設定され、サーバーがREAD_ERROR_FROM_SERVERなどのエラーで応答する場合にもプラグインはフェイルオーバーします。OFFに設定されている場合、プラグインはフェイルオーバーしません。『Oracle WebLogic ServerにおけるWebサーバー1.1プラグインの使用』の「Webサーバー・プラグインのパラメータ」を参照してください。
WebLogicプロキシ・プラグインの再試行メカニズムの設定を確認します; たとえば、許可される再試行の最大回数が、ConnectTimeoutSecs値をConnectRetrySecs値で除算した値と等しいかどうかなどを確認します。『Oracle WebLogic ServerにおけるWebサーバー1.1プラグインの使用』のフェイルオーバー、CookieおよびHTTPセッションに関する項を参照してください。
障害が発生したサーバーでトランザクションをリカバリするには、次の手順に従います。
サーバーに障害が発生した後でトランザクション・ログ・レコードを移動する場合は、すべてのトランザクション・ログ・レコードを新しいマシンで使用可能にしてから、そのマシンでサーバーを起動します。そうしないと、クラッシュ時にコミット中だったトランザクションが適切に解決できず、その結果、アプリケーション・データに矛盾が発生する場合があります。このような移行は、両方のマシンで使用可能なデュアル・ポート・ディスクに永続ストアのデータ・ファイルを格納することで実現できます。計画的な移行の場合は、新しいマシンでパス名が異なるときに、デフォルトのファイル・ストアのdirectory属性を新しいパス名で更新してからサーバーを起動します。
注意:
トランザクション・リカバリ・サービスは、クラッシュ後にトランザクションのリカバリを正常に行うために設計されたものです。サーバーがクラッシュした場合は、新しいマシンにサーバーを移動するよりも、サーバーを再起動し、トランザクション・リカバリ・サービスによって未完了のトランザクションを処理することをお薦めします。
クラスタリングされたサーバーで障害が発生した場合、以下のいずれかの方法でトランザクションをリカバリできます。
クラスタリングされたサーバーの場合、WebLogic Serverでは、トランザクション・リカバリ・サービスを含めて、障害が発生したサーバーを新しいマシンに移行できます。サーバーを別のマシンに移行する場合、トランザクションを完了またはリカバリするには、サーバーがトランザクション・ログ・レコードを見つけられるようにする必要があります。トランザクション・ログ・レコードは、サーバーのデフォルト永続ストアに格納されています。障害が発生したときに、クラスタリングされたサーバーを移行する計画がある場合は、障害が発生した移行可能なサーバーの移行先となり得る任意のマシンにアクセスできる、共有ストレージ・システムにレコードを格納するよう、デフォルト永続ストアを設定する必要があります。高い信頼性を実現するために、ストレージ・エリア・ネットワーク(SAN)などの、高可用性の備わっている共有ストレージ・ソリューションを使用してください。
サーバーの移行に関する詳細は、『Oracle WebLogic Serverクラスタの管理』の「サーバー全体の移行」を参照してください。
デフォルト永続ストア・オプションの設定の詳細は、以下を参照してください。
サーバー・ヘルス監視サービスを使用することで、トランザクション・リカバリ・サービスを異常のあるサーバー・インスタンスから正常なサーバー・インスタンスに自動的に移行できます。これにより、障害が発生したサーバーのトランザクション処理をバックアップ・サーバーで完了できます。『Oracle WebLogic Serverクラスタの管理』のJTAトランザクション・リカバリ・サービスの自動移行を構成する手順に関する項を参照してください。
クラスタ化されたサーバーがクラッシュした場合は、WebLogic Server管理コンソールまたはコマンド行インタフェースを使用して、クラッシュしたサーバーから同一クラスタ内の別のサーバーへ手動でトランザクション・リカバリ・サービスを移行できます。WebLogic Server管理コンソールを使用してトランザクション・リカバリ・サービスを手動で移行する手順については、Oracle WebLogic Server管理コンソール・オンライン・ヘルプのトランザクション・リカバリ・サービスの手動での移行に関する項を参照してください。
シングルトン・サービスのWebLogic Serverヘルス監視を使用して、トランザクション・リカバリ・サービスが正常な候補サーバーに自動的に移行されるように構成することも可能です。「トランザクション・リカバリ・サービスの自動移行」を参照してください。
手動または自動のサービス移行が実施されると、以下のイベントが発生します。
トランザクション・ログの所有権がクラッシュしたサーバーからバックアップ・サーバーのトランザクション・リカバリ・サービスに移ります。
「クラッシュ後のトランザクション・リカバリ・サービスのアクション」で説明するように、トランザクション・リカバリ・サービスは、障害が発生したサーバーからのすべてのトランザクション・ログ・レコードを解析して未完了のトランザクションを見つけ、そのトランザクションを終了させます。
バックアップ・サーバーのトランザクション・リカバリ・サービスにより、障害が発生したサーバーで未完了のトランザクションがすべて正常に終了すると、サーバーでは障害が発生したサーバーのトランザクション・リカバリ・サービスに対する所有権が解放され、障害が発生したサーバーが再起動時にその所有権を再び要求できるようになります。
サーバーでは、障害が発生した複数のサーバーに対してトランザクション・リカバリを行うことができます。他のサーバーのトランザクションを回復している間に、バックアップ・サーバーは自身のトランザクションの処理および回復を続けます。リカバリ中にバックアップ・サーバーで障害が発生した場合は、さらに別のサーバーにトランザクション・リカバリ・サービスを移行できます。この別のサーバーで、トランザクション・リカバリは続行されます。また、WebLogic Server管理コンソールまたはコマンド行インタフェースを使用して、トランザクション・リカバリ・サービスを障害が発生した元のサーバーに手動で移行して戻すこともできます。「トランザクション・リカバリ・サービスの元のサーバーへの手動による移行」を参照してください。
サーバーのトランザクション・リカバリがバックアップ・サーバーで完了すると、バックアップ・サーバーではトランザクション・リカバリ・サービスの所有権が、障害が発生したサーバーに解放されます。障害が発生したサーバーを再起動すると、このサーバーはトランザクション・リカバリ・サービスの所有権を再び要求しようとします。障害が発生したサーバーを再起動したときに、バックアップ・サーバーがトランザクション・リカバリ処理中だった場合、バックアップ・サーバーはトランザクションのリカバリを中止し、内部クリーンアップを行い、トランザクション・リカバリ・サービスの所有権を解放して、障害が発生したサーバーがそれを再び要求して正しく起動できるようにします。その後、障害が発生したサーバーでは、自身のトランザクション・リカバリを完了します。
障害が発生したサーバーのトランザクション・リカバリ・サービスがまだバックアップ・サーバーで所有されており、障害が発生したサーバーを再起動しようとしたときにバックアップ・サーバーが非アクティブだった場合、バックアップ・サーバーがトランザクション・リカバリ・サービスの所有権を解放できないため、障害が発生したサーバーは起動しません。これは、フェイルバック・メカニズムが失敗した場合や、バックアップ・サーバーが管理サーバーと通信できない場合にも当てはまります。トランザクション・リカバリは、WebLogic Server管理コンソールまたはコマンド行インタフェースを使用して手動で移行可能です。
WebLogic Server 10.0より前のリリースでは、クラスタのプライマリ管理対象サーバーの起動時に管理サーバーにアクセスできない場合(ほとんどの場合は管理サーバーがまだ起動していないことが原因)、プライマリ管理対象サーバーは自動的に管理対象サーバー独立(MSI)モードに移行し、ローカルの構成情報を使用して起動を続行していました。このような状況では、手動でのトランザクション・リカバリ・サービスの移行時に、プライマリ管理対象サーバーのかわりにバックアップ・サーバーでまだTLogデータをリカバリ中である可能性があり、その場合にはこれらのサーバーがTLogに同時にアクセスしてTLogが破損するリスクがありました。
TLogの破損のリスクを回避するためのプロパティが、JTAMigratableTargetMBeanのstrictOwnershipCheckです。このプロパティを使用することで、プライマリ管理対象サーバーの起動中に管理サーバー(JTA手動移行ポリシーの場合)またはシングルトン・マスター(JTA自動移行ポリシーの場合)に接続できないことが判明すると、次に示すようにstrictOwnershipCheckの値に従って管理対象サーバーの独立性が検証されるようになりました。
True - これが推奨設定です。プライマリ管理対象サーバーは、例外をスローして起動に失敗します。
False - プライマリ管理対象サーバーは、トランザクション・リカバリ・サービスのフェイルバックをスキップして正常に起動します。この場合は、WebLogic Server 9.2以前と同じようにTLogが破損するリスクがあります。
トランザクション・リカバリ・サービスを自動または手動で移行する場合は、以下の制限があります。
トランザクション・リカバリ・サービスを、実行中のサーバーからバックアップ・サーバーへ移行することはできません。トランザクション・リカバリ・サービスを移行する前に、サーバーを停止する必要があります。
バックアップ・サーバーでは、障害が発生したサーバーに対する新しいトランザクション処理は受け付けません。終了していないトランザクションを処理するだけです。
バックアップ・サーバーでは、ヒューリスティック・ログ・ファイルは処理しません。
バックアップ・サーバーは、WebLogic Serverによって書き込まれたログ・レコードのみを処理します。WebLogic Tuxedoコネクタなどのゲートウェイ実装によって書き込まれたログ・レコードの処理は行いません。
以上の制限に加え、WebLogic Server 10.0以降でトランザクション・リカバリ・サービスが自動的に移行されるように構成する場合は以下のルールも適用されます。
以前のWebLogic Serverリリースのサーバーがクラスタに含まれている場合でも、プライマリ・サーバーとバックアップ・サーバーはWebLogic Server 10.0以降にする必要があります。自動移行が有効になっている場合にこのルールが強制的に適用されるように、WebLogic Server管理コンソールの「候補サーバー」の「使用可能」リストにはWebLogic Server 10.0以降のサーバーのみが表示されるようになっています。
リリース9.2以前のサーバーとリリース10.0以降のサーバーの間の手動サービス移行は、移行スクリプトを使用していない場合にのみサポートされます。
クラスタ内の障害が発生したサーバーから同じクラスタ内の別のサーバー(バックアップ・サーバー)にトランザクション・リカバリ・サービスを移行するには、障害が発生したサーバーのトランザクション・ログ・レコードにバックアップ・サーバーがアクセスできる必要があります。したがって、クラスタ内のすべての潜在的なバックアップ・サーバーにとって使用可能な永続ストレージ上に、デフォルト永続ストア・データ・ファイルを格納する必要があります。次の点を考慮してください。
ストレージ・エリア・ネットワーク(SAN)が推奨されます。
NFSファイル・システムを使用する場合、ディスク書込みがキャッシュされないようにNFSサーバーを構成します。
ストレージ・ソリューションにかかわらず、フェイルオーバーと移行をテストします。
一部のストレージ・ソリューション、特に一部のバージョンのNFSでは、ファイルのロックが問題になる可能性があります。ファイル・ロックを効率的に処理するようにストレージ・サーバーを構成するか、WebLogicファイル・ストアのファイル・ロックを停止する必要があります。
注意:
NFS記憶域は、同期書込みリクエストが揮発性メモリーに警告なしでバッファされるように構成されているので、トランザクション・データを完全に保護しない場合があります。ファイル・ストアのディレクトリがNFSマウントに存在して、ファイル・ストアの同期書込みポリシーがDisabled以外である場合、NFS実装と構成をチェックして、同期の書込みがサポートされるように構成されていることを確認します。Disabledの同期書込みポリシーを使用すると、同期書込みが行われていないので、一般的にはトランザクションで安全ではありません。記憶域デバイスの物理機能を超える最大数の永続メッセージまたはトランザクション・スループットを表示すると、同期書込みリクエストの不要なバッファリングが発生する可能性があります。NFSサーバーで、ファイル・ストアをホストするエクスポート済のNFSディレクトリの同期書込み設定をチェックします。SANベースのファイル・ストアまたはJDBCストアでは、安全な集中型の記憶域を提供する簡単な方法が用意されている場合があります。『Oracle WebLogic Serverのパフォーマンスのチューニング』のファイル・ロックとNFSに関する項を参照してください。
トランザクション・リカバリ・サービスを自動または手動で移行する際は、永続ストアに関する以下のルールが適用されます。
デフォルト永続ストアを、JTAを始めとする移行可能サービスの間で共有することはできません。移行可能ターゲットにターゲット指定されている他の移行可能サービス(たとえばJMSサービス)では、別途カスタム・ストアを使用する必要があります。
デフォルト・ストアのマウントやアンマウントを実行する移行前/移行後スクリプトを指定する場合は、候補マシンごとにノード・マネージャを構成して実行する必要があります。
プライマリ・サーバーが起動、フェイルオーバー、またはフェイルバックする際には、管理サーバーがアクセス可能な状態になっている必要があります。これは、トランザクション・リカバリ・サービスが、そのTLogの排他的な所有権を競合なく適切に取得できるようにするためです。プライマリ・サーバーの起動時には、トランザクション・リカバリ・サービスが管理サーバーに接続し、JTAに関する最新の情報を取得します。フェイルオーバーやフェイルバックが発生した場合は、トランザクション・リカバリ・サービスがその最新情報を管理サーバーに保存します。
トランザクション・リカバリ・サービスをサーバーから移行するときには、実際に移行を行う前に障害が発生している、または障害が発生したサーバーを停止する必要があります。元のサーバーがまだ実行中の場合は、そこからトランザクション・リカバリ・サービスを移行することはできません。
移行に参加するサーバーはすべて、構成においてリスニング・アドレスが指定されている必要があります。Oracle WebLogic Server管理コンソール・オンライン・ヘルプのリスニング・アドレスの構成に関する項を参照してください。
クラスタ内のサーバーに対してトランザクション・リカバリ・サービスのバックアップ・サーバーとして使用するサーバーの選択肢を制限することもできます。たとえば、クラスタ内のすべてのサーバーがサーバーのトランザクション・ログ・レコードにアクセスできるとは限りません。WebLogic Server管理コンソールの「サーバー」→「構成」→「移行」ページでは、利用可能な宛先サーバーのリストを制限できます。手順は、Oracle WebLogic Server管理コンソール・オンライン・ヘルプのトランザクション・リカバリ・サービスの移行先とする候補サーバーの構成に関する項を参照してください。
注意:
必要に応じてトランザクション・リカバリ・サービスを手動で移行して元のサーバーに戻せるように、「選択済み」リストに移行元のサーバーを含めておく必要があります。WebLogic Server管理コンソールでは、このルールが強制的に適用されます。
トランザクション・リカバリ・サービスをクラスタ内の別のサーバーに移行した場合、そのトランザクション・リカバリ・サービスの所有権は、未完了のトランザクションがすべて完了するまでバックアップ・サーバーに割り当てられます。トランザクションの完了後、バックアップ・サーバーはトランザクション・リカバリ・サービスの所有権を解放し、元のサーバーは所有権の返還を要求できます。現在のオーナーを確認するには、Oracle WebLogic Server管理コンソール・オンライン・ヘルプのサーバー: 制御: 移行に関するページにアクセスしてください。次の手順に従います。
バックアップ・サーバーは、障害が発生したサーバーのトランザクションのリカバリが完了すると、トランザクション・リカバリ・サービスの所有権を解放します。そのため、元のサーバーは再起動時にその所有権の返還を要求できます。トランザクションのリカバリが完了する前になんらかの理由でバックアップ・サーバーが停止(クラッシュ)すると、元のサーバーはトランザクション・リカバリ・サービスの所有権の返還を要求できなくなり、起動しません。
また、移行先サーバーとして元のサーバーを選択すると、トランザクション・リカバリ・サービスを手動で移行して元のサーバーに戻すことができます。元のサーバーにトランザクション・リカバリ・サービスを手動で移行して返還するときには、バックアップ・サーバーが稼動していてはいけません。次の手順に従います。
注意:
以下の点に注意してください。
トランザクション・リカバリ・アクションの完了前にバックアップ・サーバーで障害が発生した場合、プライマリ・サーバーは、トランザクション・リカバリ・サービスの所有権を要求できず、サーバーの再起動後にリカバリは再試行されません。そのため、トランザクション・リカバリ・サービスを別のバックアップ・サーバーに手動で再移行する必要があります。
バックアップ・サーバーによるトランザクションのリカバリ中に元のサーバーを再起動した場合は、バックアップ・サーバーが正常にトランザクション・リカバリ・サービスの所有権を解放します。バックアップ・サーバーを停止する必要はありません。「クラスタリングされたサーバーで障害が発生した場合のトランザクションのリカバリ」を参照してください。
WebLogic Server管理コンソールを使用してトランザクション・リカバリ・サービスを手動で移行する手順については、Oracle WebLogic Server管理コンソール・オンライン・ヘルプのトランザクション・リカバリ・サービスの手動での移行に関する項を参照してください。
TLogを削除する前に、できるだけ多くのトランザクションを完了できるようWebLogic Serverインスタンスを正常に停止する必要があります。
注意:
TLogの削除が必要になるのは、極端な場合のみです。TLogを削除するとトランザクション・レコードが削除されるため、ヒューリスティック障害が発生します。たとえば、「サーバーの移行」を参照してください
TLogの場所は、デフォルト・ストアとJDBC TLogストアのどちらを使用しているか、またLLRがトランザクションの参加リソースであるかどうかで異なります。
トランザクションに関与する1つのリソースがLLRの場合、TLogは2箇所に格納されます。
トランザクション・レコードは、データベース表に格納されます。「LLRデータベースでのTLogの削除方法」を参照してください
サーバーとリソースのチェックポイントは、デフォルト・ストアまたはJDBC TLogストアに格納されます。「デフォルト・ストアからのTLogファイルの削除方法」および「JDBC TLogストアからのTLogの削除方法」を参照してください
トランザクションに参加LLRがない場合、トランザクション・レコード、サーバー・チェックポイントおよびリソース・チェックポイントはすべて、デフォルト・ストアまたはJDBC TLogストア内のTLogファイルに保存されます。「デフォルト・ストアからのTLogファイルの削除方法」および「JDBC TLogストアからのTLogの削除方法」を参照してください
LLR表のデフォルト名はWL_LLR_SERVERNAMEで、SERVERNAMEは、サーバー・インスタンスの名前です。Oracle WebLogic Server管理コンソール・オンライン・ヘルプの「サーバー: 構成: 全般」の「JDBC LLR表名」を参照してください。データベースに保持されているLLR TLogを削除するには、drop table WL_LLR_SERVERNAMEを発行して、表からすべてのレコードを削除します。
デフォルト・ストア内のTLogを削除するには、次のパターンのファイルをすべて削除します。
$DOMAIN_HOME/servers/servername/data/store/default/_WLS_SERVERNAMExxxxxx.DAT
ここで、xxxxxxは、0から9の整数です。
注意:
構成済のJMSファイル・ストアがデフォルト・ストアに含まれる場合、TLogを削除するとJMSファイル・ストアも削除されます。この場合、TLogファイルを削除する前に、JMSメッセージを別の場所にエクスポートします。その後、TLogファイルを安全に削除し、JMSメッセージを元のストアにインポートできます。『Oracle WebLogic Server JMSリソースの管理』のJMSメッセージの管理に関する項を参照してください。
