| Oracle® Fusion Middleware Oracle WebLogic Server JTAのプログラミング 11g リリース1(10.3.4) B61631-02 |
|
 前 |
 次 |
| Oracle® Fusion Middleware Oracle WebLogic Server JTAのプログラミング 11g リリース1(10.3.4) B61631-02 |
|
前 |
次 |
以下の節では、トランザクションの管理に使用される管理タスクに関する情報を提供します。
統計およびモニターの機能を使用して、サーバー上のトランザクションをモニターできます。管理コンソールでは、それらの機能を構成したり、結果出力を表示したりできます。
管理コンソールで、ドメイン内の各サーバーのトランザクションをモニターできます。トランザクションの統計は、ドメイン全体ではなく、特定のサーバーについて表示されます。
手順については、Oracle WebLogic Server管理コンソール・オンライン・ヘルプにある次のページを参照してください。
ヒューリスティックな終了 (ヒューリスティックな決定)は、更新をコミットまたはロールバックする分散トランザクションの終了段階で、リソースが一方だけの決定を行ったときに発生します。これにより、分散されたデータは不確定な状態のままになります。ヒューリスティックな終了の原因としては、ネットワークの障害またはリソースのタイムアウトが考えられます。ヒューリスティックな終了が発生すると、以下のヒューリスティックな結果例外のいずれかがスローされます。
HeuristicRollback - トランザクションに参加する1つのリソースが、準備してコミットの決定を待つことに同意しているにもかかわらず、処理のロールバックを自発的に決定した場合。トランザクション・マネージャがトランザクションのコミットを決定すると、そのリソースによるヒューリスティックなロールバックの決定は不正になり、トランザクションの他のブランチはコミットされるため、矛盾した結果を招きます。
HeuristicCommit - トランザクションに参加する1つのリソースが、準備してコミットの決定を待つことに同意しているにもかかわらず、処理のコミットを自発的に決定した場合。トランザクション・マネージャがトランザクションのロールバックを決定すると、そのリソースによるヒューリスティックなコミットの決定は不正になり、トランザクションの他のブランチはロールバックされるため、矛盾した結果を招きます。
HeuristicMixed - トランザクションで、参加リソースの一部がコミットし、一部がロールバックするという混合した結果になったことを、トランザクション・マネージャで認識している場合。主に、1つまたは複数の参加リソースが、ヒューリスティックなロールバックまたはヒューリスティックなコミットを決定したことが原因で発生します。
HeuristicHazard - トランザクションで、参加リソースの一部がコミットし、一部がロールバックするという混合した結果になった可能性があることを、トランザクション・マネージャで認識している場合。ただし、システムまたはリソースに障害があるため、HeuristicMixedの結果が確かに発生したかどうかを確認できません。主に、1つまたは複数の参加リソースが、ヒューリスティックなロールバックまたはヒューリスティックなコミットを決定したことが原因で発生します。
ヒューリスティックな終了が発生すると、サーバー・ログにメッセージが書き込まれます。ヒューリスティックな終了を解決する方法については、データベース・ベンダーが提供するドキュメントを参照してください。
一部のリソース・マネージャでは、ヒューリスティックな終了のコンテキスト情報が保存されます。この情報は、リソース・マネージャのデータの矛盾を解決するときに便利です。WebLogic Consoleの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時間です。この時間を過ぎると、利用できないリソースや、トランザクションの結果を承認できないリソースが関わるトランザクションでそれ以上の解決は行われません。破棄される前にトランザクションの準備が完了していた場合、トランザクション・マネージャは破棄されるトランザクションにかわってトランザクションをロールバックし、ロックを解放してから、サーバー・ログにヒューリスティック・エラーを書き込みます。
以下の関連情報を参考にできます。
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設定は完全に無効になります。 |
構成情報の詳細は次のトピックを参照してください。
Oracle Fusion Middleware Oracle WebLogic Serverの管理コンソール・オンライン・ヘルプの高度なドメインJTAオプションの構成に関する項
Oracle Fusion Middleware Oracle WebLogic Server MBeanリファレンスのCompletionTimeoutSecondsに関する項
|
注意: completion-timeout-seconds属性は、JCAトランザクションなどのインポート済トランザクションや、リカバリ・トランザクションには適用されません。 |
WebLogic Serverのトランザクション・マネージャは、ユーザーによる最低限の介入でシステムのクラッシュからリカバリするように設計されています。トランザクション・マネージャは、クラッシュが何度も発生した後や、クラッシュのリカバリ中であっても、リソース・マネージャによって準備されたトランザクション・ブランチをコミットまたはロールバックによって解決するために、あらゆる努力を払います。
クラッシュ後のリカバリを容易にするため、WebLogic Serverではトランザクション・リカバリ・サービスを提供しています。このサービスでは、システムの起動時にトランザクションのリカバリが自動的に行われます。「クラッシュ後のトランザクション・リカバリ・サービスのアクション」で説明するように、トランザクション・リカバリ・サービスは、起動時にすべてのトランザクション・ログ・レコードを解析して未完了のトランザクションを見つけ、そのトランザクションを終了させます。
トランザクション・リカバリ・サービスは、クラッシュ後にトランザクションのリカバリを正常に処理するよう設計されているため、サーバーがクラッシュした場合は再起動し、トランザクション・リカバリ・サービスによって未完了のトランザクションを処理することをお薦めします。
サーバーがクラッシュして、適切な時間内に再起動できそうにない場合は、ユーザーによる処理が必要になることがあります。サーバーの障害発生後にトランザクションをリカバリする手順は、WebLogic Serverの環境によって異なります。クラスタ化されていないサーバーの場合は、手動でサーバー(およびデフォルト永続ストアのDATファイル)を別のシステム(マシン)に移動することでトランザクションをリカバリできます。詳細は、「クラスタ化されていないサーバーで障害が発生した場合のトランザクションのリカバリ」を参照してください。クラスタ内のサーバーについては、同じクラスタ内の別のサーバーに、サーバー全体またはトランザクション・リカバリ・サービスを手動で移行できます。トランザクション・リカバリ・サービスの移行には、トランザクションをリカバリするためのトランザクション・ログにアクセスできるサーバーを選択し、次に管理コンソールまたはWebLogicコマンドライン・インタフェースを使用してサービスを移行することが必要です。
|
注意: クラスタリングされていないサーバーの場合は、サーバー全体を新しいシステムに移動することしかできません。クラスタリングされたサーバーの場合は、サーバー全体を移行することも、トランザクション・リカバリ・サービスを一時的に移行することも可能です。 |
トランザクション・リカバリ・サービスの移行に関する詳細は、「クラスタ化されたサーバーで障害が発生した場合のトランザクションのリカバリ」を参照してください。クラスタの詳細は、『Oracle Fusion Middleware Oracle WebLogic Serverクラスタの使い方』を参照してください。
次の項では、障害発生後にトランザクションをリカバリする方法について説明します。
クラッシュ後にサーバーを再起動したり、トランザクション・リカバリ・サービスを別の(バックアップ)サーバーに移行したりすると、トランザクション・リカバリ・サービスは以下の処理を行います。
2フェーズ・コミットの第2フェーズの準備が整っているトランザクションを終了します。
コミットの決定が行われたが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構成属性を設定することで制限できます。詳細については、「トランザクションの破棄」を参照してください。
WebLogicプロキシ・プラグインを備えたApacheをクラスタのフロントエンドとして使用する際、プラグインは複数の構成パラメータを使用して、WebLogic Serverホストへの接続を待機する時間や、接続の確立後は、プラグインが応答を待機する時間を判断します。
Apacheのidempotentフラグの設定を検証します。idempotentがONに設定されているときに、指定したWLIOTimeoutSecs値内でサーバーが応答しない場合は、プラグインがフェイルオーバーします。idempotentがONに設定され、サーバーがREAD_ERROR_FROM_SERVERなどのエラーで応答する場合にもプラグインはフェイルオーバーします。OFFに設定されている場合、プラグインはフェイルオーバーしません。詳細は、『Oracle Fusion Middleware Oracle WebLogic ServerにおけるWebサーバー1.1プラグインの使い方』のWebサーバー・プラグインのパラメータに関する項を参照してください。
WebLogicプロキシ・プラグインの再試行メカニズムの設定を検証します。たとえば、許可されている再試行の最大数が、ConnectTimeoutSecs値をConnectRetrySecs値で割ったものと同じかどうか、などです。詳細は、『Oracle Fusion Middleware Oracle WebLogic ServerにおけるWebサーバー1.1プラグインの使い方』のフェイルオーバー、クッキーおよびHTTPセッションに関する項を参照してください。
障害が発生したサーバーでトランザクションをリカバリするには、次の手順に従います。
すべてのトランザクション・ログ・レコードが含まれる永続ストアDATファイルを、障害が発生したサーバーから新しいサーバーへ移動します(新しいサーバーで利用できるようにします)。
デフォルト永続ストアへのパスを、データ・ファイルへのパスと共に設定します。「デフォルト永続ストアへのパスの設定」を参照してください。
新しいサーバーを起動します。「クラッシュ後のトランザクション・リカバリ・サービスのアクション」で説明するように、トランザクション・リカバリ・サービスは、すべてのトランザクション・ログ・ファイルを解析して未完了のトランザクションを見つけ、そのトランザクションを終了させます。
サーバーに障害が発生した後でトランザクション・ログ・レコードを移動する場合は、すべてのトランザクション・ログ・レコードを新しいマシンで使用可能にしてから、そのマシンでサーバーを起動します。そうしないと、クラッシュ時にコミット中だったトランザクションが適切に解決できず、その結果、アプリケーション・データに矛盾が発生する場合があります。このような移行は、両方のマシンで使用可能なデュアル・ポート・ディスクに永続ストアのデータ・ファイルを格納することで実現できます。計画的な移行の場合は、新しいマシンでパス名が異なるときに、デフォルトのファイル・ストアのdirectory属性を新しいパス名で更新してからサーバーを起動します。
|
注意: トランザクション・リカバリ・サービスは、クラッシュ後にトランザクションのリカバリを正常に行うために設計されたものです。サーバーがクラッシュした場合は、新しいマシンにサーバーを移動するよりも、サーバーを再起動し、トランザクション・リカバリ・サービスによって未完了のトランザクションを処理することをお薦めします。 |
クラスタリングされたサーバーで障害が発生した場合、以下のいずれかの方法でトランザクションをリカバリできます。
クラスタリングされたサーバーの場合、WebLogic Serverでは、トランザクション・リカバリ・サービスを含めて、障害が発生したサーバーを新しいマシンに移行できます。サーバーを別のマシンに移行する場合、トランザクションを完了またはリカバリするには、サーバーがトランザクション・ログ・レコードを見つけられるようにする必要があります。トランザクション・ログ・レコードは、サーバーのデフォルト永続ストアに格納されています。障害が発生したときに、クラスタリングされたサーバーを移行する計画がある場合は、障害が発生した移行可能なサーバーの移行先となり得る任意のマシンにアクセスできる、共有ストレージ・システムにレコードを格納するよう、デフォルト永続ストアを設定する必要があります。高い信頼性を実現するために、ストレージ・エリア・ネットワーク(SAN)などの、高可用性の備わっている共有ストレージ・ソリューションを使用してください。
サーバーの移行に関する詳細は、『Oracle Fusion Middleware Oracle WebLogic Serverクラスタの使い方』の「サーバー全体の移行」を参照してください。
デフォルト永続ストア・オプションの設定の詳細は、以下を参照してください。
クラスタ化されたサーバーがクラッシュした場合は、管理コンソールまたはコマンドライン・インタフェースを使用して、同じクラスタ内でクラッシュしたサーバーから別のサーバーへ、トランザクション・リカバリ・サービスを手動で移行できます。管理コンソールを使用してトランザクション・リカバリ・サービスを手動で移行する手順については、Oracle WebLogic Server管理コンソール・オンライン・ヘルプのトランザクション・リカバリ・サービスの手動移行に関する項を参照してください。
シングルトン・サービスのWebLogic Serverヘルス監視を使用して、トランザクション・リカバリ・サービスが正常な候補サーバーに自動的に移行されるように構成することも可能です。「トランザクション・リカバリ・サービスの自動移行」を参照してください。
手動または自動のサービス移行が実施されると、以下のイベントが発生します。
トランザクション・ログの所有権がクラッシュしたサーバーからバックアップ・サーバーのトランザクション・リカバリ・サービスに移ります。
「クラッシュ後のトランザクション・リカバリ・サービスのアクション」で説明するように、トランザクション・リカバリ・サービスは、障害が発生したサーバーからのすべてのトランザクション・ログ・レコードを解析して未完了のトランザクションを見つけ、そのトランザクションを終了させます。
バックアップ・サーバーのトランザクション・リカバリ・サービスにより、障害が発生したサーバーで未完了のトランザクションがすべて正常に終了すると、サーバーでは障害が発生したサーバーのトランザクション・リカバリ・サービスに対する所有権が解放され、障害が発生したサーバーが再起動時にその所有権を再び要求できるようになります。
サーバーでは、障害が発生した複数のサーバーに対してトランザクション・リカバリを行うことができます。他のサーバーのトランザクションをリカバリしている間に、バックアップ・サーバーは自身のトランザクションの処理およびリカバリを続けます。リカバリ中にバックアップ・サーバーで障害が発生した場合は、さらに別のサーバーにトランザクション・リカバリ・サービスを移行できます。この別のサーバーで、トランザクション・リカバリは続行されます。また、管理コンソールまたはコマンドライン・インタフェースを使用して、トランザクション・リカバリ・サービスを元の障害が発生したサーバーに手動で移行して戻すこともできます。詳細は、「トランザクション・リカバリ・サービスの元のサーバーへの手動による移行」を参照してください。
サーバーのトランザクション・リカバリがバックアップ・サーバーで完了すると、バックアップ・サーバーではトランザクション・リカバリ・サービスの所有権が、障害が発生したサーバーに解放されます。障害が発生したサーバーを再起動すると、このサーバーはトランザクション・リカバリ・サービスの所有権を再び要求しようとします。障害が発生したサーバーを再起動したときに、バックアップ・サーバーがトランザクション・リカバリ処理中だった場合、バックアップ・サーバーはトランザクションのリカバリを中止し、内部クリーンアップを行い、トランザクション・リカバリ・サービスの所有権を解放して、障害が発生したサーバーがそれを再び要求して正しく起動できるようにします。その後、障害が発生したサーバーでは、自身のトランザクション・リカバリを完了します。
障害が発生したサーバーのトランザクション・リカバリ・サービスがまだバックアップ・サーバーで所有されており、障害が発生したサーバーを再起動しようとしたときにバックアップ・サーバーが非アクティブだった場合、バックアップ・サーバーがトランザクション・リカバリ・サービスの所有権を解放できないため、障害が発生したサーバーは起動しません。これは、フェイルバック・メカニズムが失敗した場合や、バックアップ・サーバーが管理サーバーと通信できない場合にも当てはまります。トランザクション・リカバリの移行は、管理コンソールまたはコマンドライン・インタフェースを使用して手動で行えます。
サーバー・ヘルス監視サービスを使用することで、トランザクション・リカバリ・サービスを異常のあるサーバー・インスタンスから正常なサーバー・インスタンスに自動的に移行できます。これにより、障害が発生したサーバーのトランザクション処理をバックアップ・サーバーで完了できます。『Oracle Fusion Middleware Oracle WebLogic Serverクラスタの使い方』の「JTAトランザクション・リカバリ・サービスの自動移行を構成するロードマップ」を参照してください。
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 10.0以降のサーバーのみが表示されるようになっています。
リリース9.2以前のサーバーとリリース10.0以降のサーバーの間の手動サービス移行は、移行スクリプトを使用していない場合にのみサポートされます。
クラスタ内の障害が発生したサーバーから同じクラスタ内の別のサーバー(バックアップ・サーバー)にJTAトランザクション回復サービスを移行するには、障害が発生したサーバーのトランザクション・ログ(TLOG)レコードにバックアップ・サーバーからアクセスできる必要があります。したがって、クラスタ内のすべての潜在的なバックアップ・サーバーにとって使用可能な永続ストレージ上に、デフォルト永続ストア・データ・ファイルを格納する必要があります。次の点を考慮してください。
ストレージ・エリア・ネットワーク(SAN)が推奨されます。
NFSファイル・システムを使用する場合、ディスク書込みがキャッシュされないようにNFSサーバーを構成します。
ストレージ・ソリューションにかかわらず、フェイルオーバーと移行をテストします。
一部のストレージ・ソリューション、特に一部のバージョンのNFSでは、ファイルのロックが問題になる可能性があります。ファイル・ロックを効率的に処理するようにストレージ・サーバーを構成するか、WebLogicファイル・ストアのファイル・ロックを停止する必要があります。
|
重要: NFS記憶域は、同期書込みリクエストが揮発性メモリーに警告なしでバッファされるように構成されているので、トランザクション・データを完全に保護しない場合があります。ファイル・ストアのディレクトリがNFSマウントに存在して、ファイル・ストアの同期書込みポリシーがDisabled以外である場合、NFS実装と構成をチェックして、同期の書込みがサポートされるように構成されていることを確認します。Disabledの同期書込みポリシーを使用すると、同期書込みが行われていないので、一般的にはトランザクションで安全ではありません。記憶域デバイスの物理機能を超える最大数の永続メッセージまたはトランザクション・スループットを表示すると、同期書込みリクエストの不要なバッファリングが発生する可能性があります。NFSサーバーで、ファイル・ストアをホストするエクスポート済のNFSディレクトリの同期書込み設定をチェックします。SANベースのファイル・ストアまたはJDBCストアでは、安全な集中型の記憶域を提供する簡単な方法が用意されている場合があります。『Oracle Fusion Middleware Oracle WebLogic Serverパフォーマンスおよびチューニング』のファイル・ロックとNFSに関する項を参照してください。 |
トランザクション・リカバリ・サービスを自動または手動で移行する際は、永続ストアに関する以下のルールが適用されます。
デフォルト永続ストアを、JTAを始めとする移行可能サービスの間で共有することはできません。移行可能ターゲットにターゲット指定されている他の移行可能サービス(たとえばJMSサービス)では、別途カスタム・ストアを使用する必要があります。
デフォルト・ストアのマウントやアンマウントを実行する移行前/移行後スクリプトを指定する場合は、候補マシンごとにノード・マネージャを構成して実行する必要があります。
プライマリ・サーバーが起動、フェイルオーバー、またはフェイルバックする際には、管理サーバーがアクセス可能な状態になっている必要があります。これは、トランザクション・リカバリ・サービスが、そのTLOGの排他的な所有権を競合なく適切に取得できるようにするためです。プライマリ・サーバーの起動時には、トランザクション・リカバリ・サービスが管理サーバーに接続し、JTAに関する最新の情報を取得します。フェイルオーバーやフェイルバックが発生した場合は、トランザクション・リカバリ・サービスがその最新情報を管理サーバーに保存します。
トランザクション・リカバリ・サービスをサーバーから移行するときには、実際に移行を行う前に障害が発生している、または障害が発生したサーバーを停止する必要があります。元のサーバーがまだ実行中の場合は、そこからトランザクション・リカバリ・サービスを移行することはできません。
移行に参加するサーバーはすべて、構成においてリスニング・アドレスが指定されている必要があります。Oracle WebLogic Server管理コンソール・オンライン・ヘルプのリスニング・アドレスの構成に関する項を参照してください。
クラスタ内のサーバーに対してトランザクション・リカバリ・サービスのバックアップ・サーバーとして使用するサーバーの選択肢を制限することもできます。たとえば、クラスタ内のすべてのサーバーがサーバーのトランザクション・ログ・レコードにアクセスできるとは限りません。管理コンソールの「サーバー」→「構成」→「移行」ページでは、使用可能な宛先サーバーを制限できます。手順については、Oracle WebLogic Server管理コンソール・オンライン・ヘルプのトランザクション・リカバリ・サービスの移行先とする候補サーバーの構成に関する項を参照してください。
|
注意: 必要に応じてトランザクション・リカバリ・サービスを手動で移行して元のサーバーに戻せるように、「選択済み」リストに移行元のサーバーを含めておく必要があります。管理コンソールでは、この規則に従わなくてはなりません。 |
トランザクション・リカバリ・サービスをクラスタ内の別のサーバーに移行した場合、そのトランザクション・リカバリ・サービスの所有権は、未完了のトランザクションがすべて完了するまでバックアップ・サーバーに割り当てられます。トランザクションの完了後、バックアップ・サーバーはトランザクション・リカバリ・サービスの所有権を解放し、元のサーバーは所有権の返還を要求できます。現在のオーナーは、Oracle WebLogic Server管理コンソール・オンライン・ヘルプの「サーバー」→「制御」→「移行」ページで確認できます。次の手順に従います。
管理コンソールの「ドメイン構造」ツリーで、「環境」を展開して「サーバー」をクリックします。
トランザクション・リカバリ・サービスの移行元のサーバーを選択し、さらに「制御」>「移行」タブを選択します。
「詳細設定」をクリックします。「JTA移行」オプションの下の「ホスト・サーバー」に、トランザクション・リカバリ・サービスの現在のオーナーが表示されます。
バックアップ・サーバーは、障害が発生したサーバーのトランザクションのリカバリが完了すると、トランザクション・リカバリ・サービスの所有権を解放します。そのため、元のサーバーは再起動時にその所有権の返還を要求できます。トランザクションのリカバリが完了する前になんらかの理由でバックアップ・サーバーが停止(クラッシュ)すると、元のサーバーはトランザクション・リカバリ・サービスの所有権の返還を要求できなくなり、起動しません。
また、移行先サーバーとして元のサーバーを選択すると、トランザクション・リカバリ・サービスを手動で移行して元のサーバーに戻すことができます。元のサーバーにトランザクション・リカバリ・サービスを手動で移行して返還するときには、バックアップ・サーバーが稼動していてはいけません。次の手順に従います。
|
注意: 以下の点に注意してください。
|
管理コンソールを使用してトランザクション・リカバリ・サービスを手動で移行する手順については、Oracle WebLogic Server管理コンソール・オンライン・ヘルプのトランザクション・リカバリ・サービスの手動移行に関する項を参照してください。
TLOGを削除する前に、できるだけ多くのトランザクションを完了できるようにWebLogic Serverインスタンスを正常に停止する必要があります。
|
注意: TLOGを削除する必要があるのは極端な場合のみです。TLOGを削除すると、トランザクション・レコードが削除されるため、ヒューリスティック障害が発生します。たとえば、「サーバーの移行」を参照してください。 |
TLOGの場所は、LLRがトランザクションの参加リソースであるかどうかによって異なります。
トランザクションに関連する1つのリソースがLLRの場合、TLOGは2箇所に格納されます。
トランザクション・レコードは、データベース表に格納されます。「LLRデータベースでのTLOGの削除方法」を参照してください。
サーバーとリソースのチェックポイントは、デフォルトのストアに格納されます。「デフォルト・ストアからのTLOGファイルの削除方法」を参照してください。
トランザクションに参加LLRがない場合、トランザクション・レコード、サーバー・チェックポイント、リソース・チェックポイントはすべて、デフォルト・ストアの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 Fusion Middleware Oracle WebLogic Server JMSの構成と管理』の「JMSメッセージの管理」を参照してください。 |
