Administration Console オンライン ヘルプ
|
 |
 |
|
[JTA に関する属性と Administration Console 画面のリファレンス]
以下の節では、WebLogic Server で Java Transaction API (JTA) 属性をコンフィグレーションする方法について説明します。
ドメイン間トランザクションに対するドメインのコンフィグレーション
Administration Console の JTA に関するページについては、JTA に関する属性と Administration Console 画面のリファレンスも参照してください。
JTA (トランザクション) のコンフィグレーション設定は、ドメイン レベルで適用できます。つまり、コンフィグレーション属性の設定はドメイン内のすべてのサーバに適用されることになります。JTA のモニタ タスクおよびロギング タスクは、サーバ レベルで実行されます。
サーバを起動する前にトランザクション属性をコンフィグレーションすることも (静的コンフィグレーション)、サーバの実行中にトランザクション属性をコンフィグレーションすることもできます (動的コンフィグレーション)。ただし、後者の場合、例外が 1 つあります。TransactionLogFilePrefix 属性は、サーバの起動前に設定する必要があります。
TransactionLogFilePrefix 属性が正しく設定されていることを確認します。ロギング属性の設定の詳細については、トランザクション ログ ファイルを参照してください。デフォルトでは、グローバル トランザクションに参加している XA リソースが WebLogic Server トランザクション マネージャからの XA 呼び出しに応答しないと、そのリソースに異常があって使用できないことを示すフラグが付加されます。また、リソースのスレッドを保持するため、このリソースに対する以降のすべての呼び出しがブロックされます。 応答に失敗する原因にはトランザクションの異常とリソースの異常がありますが、トランザクションの異常が原因で失敗してもリソースの異常としてマークされるため、どちらが原因で失敗したかを判別することはできません。
この制約を緩和するため、WebLogic Server には表 54-1 に示すコンフィグレーション属性が用意されています。
これらの属性は、ドメインが非アクティブのときに config.xml ファイルで設定します。 Administration Console では設定できません。 次の例は、これらの属性に関する部分をコンフィグレーション ファイルから抜粋したものです。
...
<JTA
MaxUniqueNameStatistics="5"
TimeoutSeconds="300"
RecoveryThresholdMillis="150000"/>
MaxResourceUnavailableMillis="900000"
MaxResourceRequestOnServer="60"
MaxXACallMillis="180000"
<JDBCConnectionPool
Name="XAPool"
Targets="myserver"
DriverName="weblogic.qa.tests.transaction.
testsupport.jdbc.XADataSource"
InitialCapacity="1"
MaxCapacity="10"
CapacityIncrement="2"
RefreshMinutes="5"
TestTableName="dual"
EnableResourceHealthMonitoring="true"Properties="user=scott;password=tiger;server=dbserver1"
/>
<JDBCTxDataSource
Name="XADataSource"
Targets="myserver"
JNDIName="weblogic.jdbc.XADS"
PoolName="XAPool"
/>
...
トランザクション マネージャで分散トランザクションを管理する場合、トランザクションを準備し、その後コミットまたはロールバックするために、トランザクション マネージャはすべての参加サーバと通信できる必要があります。これは、WebLogic ドメインが、分散トランザクションにおいて、トランザクション マネージャまたはトランザクション参加コンポーネント (リソース) として機能する場合に当てはまります。以下の節では、ドメイン間トランザクションが可能なようにドメインをコンフィグレーションする方法を説明します。WebLogic ドメイン間の相互運用性の詳細については、WebLogic ドメイン間の信頼関係の有効化を参照してください。
注意: グローバル トランザクションでは、[非 XA ドライバ用に 2 フェーズ コミットをエミュレート] を選択して 非 XA ドライバを使用する代わりに、XA ドライバを使用することをお勧めします。 グローバル トランザクションで非 XA ドライバを使用することにはリスクが伴います。 リスクの詳細については、グローバル トランザクションで非 XA ドライバを使用する場合の制限とリスクを参照してください。
複数の WebLogic Server 8.x および 7.x ドメインにまたがる (つまり、すべての参加ドメインが WebLogic Server 7.x または 8.x、あるいは 7.x と 8.x の組み合わせで実行される) トランザクションを管理する、またはそのようなトランザクションに参加するには、すべてのドメインのセキュリティ資格を同じ値に設定する必要があります。資格の値を設定するには、それぞれの参加ドメインについて次の手順に従ってください。
WebLogic Server 7.x または 8.x および WebLogic Server 6.x の両方のドメインのサーバを使用するトランザクションを管理するには、次の手順に従ってください。
参加するすべての WebLogic Server 6.x ドメインにおいて、次の手順を行います。
system ユーザのパスワードを同じ値に変更します。「システム パスワードの変更」を参照してください。WebLogic Server 7.x および 8.x のすべての参加ドメインで、次の手順を行います。
system パスワードに一致する必要があります。手順については、WebLogic Server 8.x および 7.x ドメインのドメイン間トランザクションを参照してください。WebLogic Server 8.1 SP4 以降のサービス パックでは、WebLogic Server の旧バージョンと相互運用する場合に、トランザクションを互換性モードで実行する必要があります。 互換性モードをコンフィグレーションするには、次のフラグを設定します。
-Dweblogic.transaction.SecurityInteropMode=compatibility
Administration Console で、ドメイン内の各サーバのトランザクションをモニタできます。トランザクション設定がドメイン全体に適用されている場合でも、ドメイン全体ではなく特定のサーバのトランザクション統計が表示されます。
サーバのトランザクション統計を表示するには、次の手順に従います。
サーバで調整されている指名されたトランザクションの統計を表示するには、次の手順に従います。
サーバでアクセスされる各トランザクション リソースの統計を表示するには、次の手順に従います。
サーバでアクセスされる各トランザクション リソースの統計を表示するには、次の手順に従います。
トランザクションは、システムやネットワークの障害により、正常に完了しない場合があります。その場合、保留中のトランザクションのためにロックがかかり、他のトランザクションの処理が禁止される場合があります。トランザクションを保持する時間が経過すると、WebLogic Server トランザクション マネージャは、内部データ構造からトランザクションを削除し、サーバ ログにヒューリスティック エラーを書き込みます。また、「停止」状態のトランザクションを手動で解決することもできます。
トランザクションを手動で解決するには、[サーバ｜モニタ｜JTA] タブからサーバの現在 (処理中) のトランザクションを表示し (サーバの現在の (処理中の) トランザクション統計の表示を参照)、トランザクション ID をクリックして特定のトランザクションの詳細を表示します。その後、トランザクション ステータスにより、コミットまたはロールバックを強制実行できます。表 54-2 には、トランザクション ステータスと、それぞれの手動解決オプションが表示されています。
トランザクションは異なるサーバで異なるステータスを持つ場合があります。たとえば、あるトランザクションが調整サーバでコミットされていても、リモートの参加コンポーネントはコミットの指示を受け取っていない場合があります。
トランザクションを手動で解決するには、以下のオプションから選択できます。オプションには、表 54-2 で示されているような制限があります。
これらのオプションのいずれかを選択すると、WebLogic Server はエントリをサーバ ログに書き込みます。
ローカル オプションとグローバル オプションの違いは、ローカル オプションの場合、現在のサーバ リソース (Administration Console の左ペインのナビゲーション ツリーで選択するサーバ上のリソース) にのみ作用するのに対し、グローバル オプションはすべての参加サーバに対して処理を実行しようとする点にあります。グローバル処理がローカル サーバによって調整されていないトランザクションに対して呼び出されると、処理を実行するために、トランザクションのコーディネータへのアクセスが試行されます。コーディネータにアクセスできない場合、javax.transaction.SystemException が発生し、処理は失敗します。
調整サーバでトランザクションがコミットされたが (コミット中のステータス)、リモート参加コンポーネントがコミットの指示を受け取らなかった場合 (準備済みのステータス)、トランザクションを完了するため、リモート参加コンポーネント上でローカル コミットを強制的に実行できます。この場合は、トランザクション ステータスが準備済みのままであっても、トランザクションはヒューリスティックに完了するため、リモート参加コンポーネント上でロールバックを強制できます。グローバル ロールバックを強制しようとした場合は、コーディネータのステータスがコミット中のため、処理は失敗します。トランザクションをコミット中のステータスでロールバックすることはできません。
手動によるトランザクション解決の詳細については、現在の (処理中の) トランザクションの手動による解決を参照してください。
各サーバでは、そのサーバで調整されてコミットされたが、未完了の可能性があるトランザクションの情報を格納するトランザクション ログを備えています。WebLogic Server では、システムのクラッシュやネットワーク障害からの回復時にトランザクション ログを使用します。トランザクション ログを直接表示することはできません。このファイルはバイナリ フォーマットです。
トランザクション ログは複数のファイルで構成されています。各ファイルは、トランザクション マネージャによるガベージ コレクションの対象です。つまり、トランザクション ログ ファイル内に必要な記録がなければ、ファイルは削除され、そのディスク領域はファイル システムに戻されます。また、以前のログ ファイルが大きくなり過ぎたり、チェックポイントが発生したりした場合には、新しいトランザクション ログ ファイルが作成されます。
警告: 手動でトランザクション ログ ファイルを削除しないでください。トランザクション ログ ファイルを削除すると、データに矛盾が発生するおそれがあります。
トランザクション ログ ファイルには、パス名プレフィックス、サーバ名、4 桁の数値サフィックス、およびファイル拡張子で構成されたユニークな名前が付けられます。パス名プレフィックスで、ファイルの格納場所が決まります。WebLogic Administration Console を使用して、TransactionLogFilePrefix サーバ属性の値を指定できます。TransactionLogFilePrefix のデフォルトは、サーバのルート ディレクトリです (『WebLogic Server のコンフィグレーションと管理』の「サーバのルート ディレクトリ」を参照してください)。
トランザクション ログ ファイルが RAID デバイスなどの高可用性ファイル システム上に作成されるように TransactionLogFilePrefix を設定する必要があります。クラスタ内のサーバに対するトランザクション回復サービスの移行機能を利用するには、トランザクション ログをサーバとそのバックアップ サーバが使用できる場所 (デュアルポート SCSI ディスクまたは SAN (Storage Area Network) を推奨) に格納する必要があります。詳細については、トランザクション回復サービスの移行準備を参照してください。
サーバ名が websvr で TransactionLogFilePrefix が /usr7/applog1/ に設定された UNIX システムでは、以下のようなログ ファイルが作成されます。
/usr7/applog1/websvr0000.tlog
/usr7/applog1/websvr0001.tlog
/usr7/applog1/websvr0002.tlog
同様に、TransactionLogFilePrefix が C:\weblogic\logA\ に設定された Windows システムでは、以下のようなログ ファイルが作成されます。
C:\weblogic\logA\websvr0000.tlog
C:\weblogic\logA\websvr0001.tlog
C:\weblogic\logA\websvr0002.tlog
システムで大量のトランザクション ログ ファイルが作成されている場合は、完了していない長時間のトランザクションが複数存在している可能性があります。その原因としては、リソース マネージャの障害や、トランザクションのタイムアウト値が著しく大きいことが考えられます。
トランザクション ログ ファイルが含まれたファイル システムで領域が不足したり、ファイル システムがアクセス不能になったりすると、commit() によって SystemException が送出され、トランザクション マネージャによってシステム エラー ログにメッセージが書き込まれます。使用できる領域が増えるまで、トランザクションはコミットされません。
注意: トランザクション ログ バッファは 250KB に制限されています。 使用しているアプリケーションに、この値を超えるトランザクション ログ書き込みを必要とする大規模なトランザクションが含まれている場合は、WebLogic Server によって例外が送出されます。 その場合は、アプリケーションを再コンフィグレーションしてこのバッファ サイズに対処する必要があります。
サーバを別のマシンに移行する場合は、トランザクション ログ ファイルも一緒に移動し、1 つのサーバに関するすべてのログ ファイルをまとめておきます。詳細については、別のマシンへのサーバの移動を参照してください。
トランザクション ログ ファイルの格納場所を決定するプレフィックスを設定するには、次の手順に従います。
トランザクション ログ ファイルの書き込みポリシーを選択して、WebLogic Server によるトランザクション ログ ファイル エントリの書き込み方法を変更できます。以下のいずれかのオプションを選択できます。
警告: Windows では [Direct-Write] トランザクション ログ ファイル書き込みポリシーが指定されていても、トランザクション データがディスクに直接書き込まれずにオンディスク キャッシュに残される場合があります。この場合、停電などによってオンディスク キャッシュのデータが失われるおそれがあり、トランザクションとしては安全とはいえません。Windows で [Direct-Write] トランザクション ログ ファイル書き込みポリシーを使用している場合にキャッシュ データの消失を回避するには、ディスクの書き込みキャッシュをすべて無効にするか (デフォルトでは有効)、またはシステムのバッテリー バックアップを使用してください。手順については、Windows 2000 におけるハード ディスクのオンディスク キャッシュの無効化を参照してください。
トランザクション ログ ファイルの書き込みポリシーは、トランザクションのパフォーマンスに影響を与えます。使用しているシステムでこれらのオプションをテストし、どちらがパフォーマンスの点で優れているかを調べる必要があります。通常は、[Direct-Write] のパフォーマンスは [Cache-Flush] と同等かそれ以上です (オペレーティング システムや OS のパラメータ設定によって異なります)。[Direct-Write] は Windows、HP-UX、および Solaris で使用できます。Windows システムは、ファイルへの最初の書き込み後はそのファイルへの以降の書き込みがより速くなるように、ディスクへの順次的な書き込みを最適化します。トランザクション ログ ファイル エントリは順番に書き込まれるので、この機能によりパフォーマンスが向上する可能性があります。一部の UNIX システムでは [Cache-Flush] オプションを指定している場合に、トランザクション ログ ファイルのキャッシュされたディスク書き込みだけでなく、すべてのキャッシュされたディスク書き込みがフラッシュされるため、トランザクションのパフォーマンスが低下する場合があります。
トランザクション ログ ファイルの書き込みポリシーを設定するには、次の手順に従います。
外部のトランザクション マネージャから WebLogic Server にトランザクションをインポートする場合、WebLogic Server トランザクション マネージャはその外部トランザクション マネージャによって調整される XA リソースとして機能します。トランザクションを保持する最長時間の経過後や、WebLogic Server にインポートされたトランザクションに参加している XA リソースがヒューリスティック例外を送出した場合など、滅多にないが破壊力の大きい状況下では、WebLogic Server トランザクション マネージャはヒューリスティックな決定を行います。つまり、WebLogic Server トランザクション マネージャは、外部トランザクション マネージャからの入力がない状態で、トランザクションをコミットするかロールバックするかを決定します。WebLogic Server トランザクション マネージャは、ヒューリスティックな決定を行うと、外部トランザクション マネージャからそのトランザクションの記録を破棄する指示があるまで、その決定の情報をヒューリスティック ログ ファイルに格納します。
ヒューリスティック ログ ファイルはトランザクション ログ ファイルと共に格納されます。.tlog 拡張子の前に .heur が付く、トランザクション ログ ファイルと似たファイル名になります。次のフォーマットを使用します。
<TLOG_file_prefix>\<server_name><4-digit number>.heur.tlog
サーバ名 websvr の UNIX システムでは、以下のような名前のヒューリスティック ログ ファイルになります。
/usr7/applog1/websvr0000.heur.tlog
/usr7/applog1/websvr0001.heur.tlog
/usr7/applog1/websvr0002.heur.tlog
同様に、Windows システムでは以下のような名前のヒューリスティック ログ ファイルになります。
C:\weblogic\logA\websvr0000.heur.tlog
C:\weblogic\logA\websvr0001.heur.tlog
C:\weblogic\logA\websvr0002.heur.tlog
ヒューリスティックな終了 (またはヒューリスティックな決定) は、更新をコミットするかロールバックする分散トランザクションの終了段階でリソースが一方だけの決定を行ったときに発生します。これにより、分散されたデータは不確定な状態のままになります。ヒューリスティックな終了の原因としては、ネットワークの障害またはリソースのタイムアウトが考えられます。ヒューリスティックな終了が発生すると、以下のヒューリスティックな結果例外のいずれかが送出されます。
HeuristicRollback—トランザクションに参加する 1 つのリソースが、準備してコミットの決定を待つことに同意しているにもかかわらず、処理のロールバックを自発的に決定した場合。トランザクション マネージャがトランザクションのコミットを決定すると、そのリソースによるヒューリスティックなロールバックの決定は不正になり、トランザクションの他のブランチはコミットされるため、矛盾した結果を招きます。 HeuristicCommit—トランザクションに参加する 1 つのリソースが、準備してコミットの決定を待つことに同意しているにもかかわらず、処理のコミットを自発的に決定した場合。トランザクション マネージャがトランザクションのロールバックを決定すると、そのリソースによるヒューリスティックなコミットの決定は不正になり、トランザクションの他のブランチはロールバックされるため、矛盾した結果を招きます。 HeuristicMixed—トランザクションで、参加リソースの一部がコミットし、一部がロールバックするという混合した結果になったことを、トランザクション マネージャで認識している場合。主に、1 つまたは複数の参加リソースが、ヒューリスティックなロールバックまたはヒューリスティックなコミットを決定したことが原因で発生します。 HeuristicHazard—トランザクションで、参加リソースの一部がコミットし、一部がロールバックするという混合した結果になった可能性があることを、トランザクション マネージャで認識している場合。ただし、システムまたはリソースに障害があるため、HeuristicMixed の結果が確かに発生したかどうかを確認できません。主に、1 つまたは複数の参加リソースが、ヒューリスティックなロールバックまたはヒューリスティックなコミットを決定したことが原因で発生します。ヒューリスティックな終了が発生すると、サーバ ログにメッセージが書き込まれます。ヒューリスティックな終了を解決する方法については、データベース ベンダが提供するドキュメントを参照してください。
一部のリソース マネージャでは、ヒューリスティックな終了のコンテキスト情報が保存されます。この情報は、リソース マネージャのデータの矛盾を解決するときに便利です。WebLogic Console の JTA ページで ForgetHeuristics 属性が選択されている (true に設定されている) 場合、この情報はヒューリスティックな終了の後で削除されます。コンテキスト情報を保存するリソース マネージャを使用するときには、ForgetHeuristics 属性を false に設定することをお勧めします。
指定した時間の経過後に未完了のトランザクションを破棄することもできます。分散トランザクションの 2 フェーズ コミット プロセスでは、トランザクション マネージャはトランザクションに参加するすべてのリソース マネージャを調整します。すべてのリソース マネージャがコミットまたはロールバックを支持すると、トランザクション マネージャはリソース マネージャに、変更に対してコミットまたはロールバックのいずれかの動作を行うよう通知します。2 フェーズ コミット プロセスにおける、この第 2 フェーズでは、トランザクション マネージャはすべてのリソース マネージャでトランザクションの終了が示されるまで、トランザクションを終了しようとし続けます。AbandonTimeoutSeconds 属性を使用すると、トランザクション マネージャがコミット プロトコルの第 2 フェーズでトランザクションの終了を試み続ける最長時間を秒単位で設定できます。デフォルト値は 86400 秒、つまり 24 時間です。この時間を過ぎると、利用できないリソースや、トランザクションの結果を承認できないリソースが関わるトランザクションでそれ以上の解決は行われません。破棄される前にトランザクションの準備が完了していた場合、トランザクション マネージャは破棄されるトランザクションに代わってトランザクションをロールバックし、ロックを解放してから、サーバ ログにヒューリスティック エラーを書き込みます。
AbandonTimeoutSeconds 属性の設定方法については、トランザクションのコンフィグレーションを参照してください。
アプリケーション サーバが別のマシンに移動された場合、サーバは新しいディスクにあるトランザクション ログ ファイルを見つけられなければなりません。このため、トランザクション ログ ファイルを新しいマシンに移動してから、そのマシン上でサーバを起動することをお勧めします。そうすることによって、確実に適切な回復処理を実行できます。新しいシステム上で WebLogic Server を起動すると、サーバはトランザクション ログ ファイルを読み取り、保留中のトランザクションがあれば、それを回復します。新しいマシンでパス名が異なる場合は、TransactionLogFilePrefix 属性を新しいパス名で更新してからサーバを起動します。TransactionLogFilePrefix 属性の変更方法については、トランザクション ログ ファイルの場所 (プレフィックス) の設定を参照してください。
WebLogic Server のトランザクション マネージャは、ユーザによる最低限の介入でシステムのクラッシュから回復するように設計されています。トランザクション マネージャは、クラッシュが何度も発生した後や、クラッシュの回復中であっても、リソース マネージャによって準備されたトランザクション ブランチをコミットまたはロールバックによって解決するために、あらゆる努力を払います。
クラッシュ後の回復を容易にするため、WebLogic Server ではトランザクション回復サービスを提供しています。このサービスでは、システムの起動時にトランザクションの回復が自動的に行われます。トランザクション回復サービスは、サーバのトランザクション ログを所有しています。クラッシュ後のトランザクション回復サービスのアクションで説明するように、トランザクション回復サービスは、起動時にすべてのログ ファイルを解析して未完了のトランザクションを見つけ、そのトランザクションを終了させます。
トランザクション回復サービスは、クラッシュ後にトランザクションの回復を正常に処理するよう設計されているため、サーバがクラッシュした場合は再起動し、トランザクション回復サービスによって未完了のトランザクションを処理することをお勧めします。
サーバがクラッシュして、適切な時間内に再起動できそうにない場合は、ユーザによる処理が必要になることがあります。サーバの障害発生後にトランザクションを回復する手順は、WebLogic Server の環境によって異なります。クラスタ化されていないサーバの場合は、手動でサーバ (およびトランザクション ログ ファイル) を別のシステム (マシン) に移動することでトランザクションを回復できます。詳細については、クラスタ化されていないサーバで障害が発生した場合のトランザクションの回復を参照してください。クラスタ内のサーバについては、同じクラスタ内の別のサーバにトランザクション回復サービスを手動で移行できます。トランザクション回復サービスの移行には、トランザクションを回復するためのトランザクション ログにアクセスできるサーバを選択し、次に Administration Console または WebLogic コマンドライン インタフェースを使用してサービスを移行することが必要です。
注意: クラスタ化されていないサーバの場合は、サーバ全体を新しいシステムに移動することしかできません。クラスタ化されたサーバでは、トランザクション回復サービスを一時的に移行できます。
トランザクション回復サービスの移行の詳細については、クラスタ化されたサーバで障害が発生した場合のトランザクションの回復を参照してください。クラスタの詳細については、『WebLogic Server クラスタ ユーザーズ ガイド』を参照してください。
クラッシュ後にサーバを再起動したり、トランザクション回復サービスを別の (バックアップ) サーバに移行したりすると、トランザクション回復サービスは以下の処理を行います。
コミットの決定が行われたが 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 コンフィグレーション属性を設定することで制限できます。詳細については、トランザクションの破棄を参照してください。
障害が発生したサーバでトランザクションを回復するには、次の手順に従います。
TransactionLogFilePrefix 属性に、トランザクション ログ ファイルへのパスを設定します。手順については、トランザクション ログ ファイルの場所 (プレフィックス) の設定を参照してください。サーバに障害が発生した後でトランザクション ログを移動する場合は、すべてのトランザクション ログ ファイルを新しいマシンで使用可能にしてから、マシンでサーバを起動します。このような移行は、両方のマシンで使用可能なデュアル ポート ディスクにトランザクション ログ ファイルを格納することで実行できます。計画的な移行の場合は、新しいマシンでパス名が異なるときに、TransactionLogFilePrefix 属性を新しいパス名で更新してからサーバを起動します。必ず、新しいマシンですべてのトランザクション ログ ファイルが使用可能になっていることを確認してから、サーバを起動してください。そうしないと、クラッシュ時にコミット中だったトランザクションが適切に解決できず、その結果、アプリケーション データに矛盾が発生する場合があります。
注意: トランザクション回復サービスは、クラッシュ後にトランザクションの回復を正常に行うために設計されたものです。サーバがクラッシュした場合は、新しいマシンにサーバを移動するよりも、サーバを再起動し、トランザクション回復サービスによって未完了のトランザクションを処理することをお勧めします。
クラスタ化されたサーバがクラッシュした場合は、Administration Console またはコマンドライン インタフェースを使用して、同じクラスタ内でクラッシュしたサーバから別のサーバへ、トランザクション回復サービスを手動で移行できます。次のイベントが発生します。
Administration Console を使用してトランザクション回復サービスを移行する手順については、トランザクション回復サービスの同一クラスタ内サーバへの移行を参照してください。
サーバでは、障害が発生した複数のサーバに対してトランザクション回復を行うことができます。他のサーバのトランザクションを回復している間に、バックアップ サーバは自身のトランザクションの処理および回復を続けます。回復中にバックアップ サーバで障害が発生した場合は、さらに別のサーバにトランザクション回復サービスを移行できます。この別のサーバで、トランザクション回復は続行されます。また、Administration Console またはコマンドライン インタフェースを使用して、トランザクション回復サービスを元の障害が発生したサーバに手動で移行して戻すこともできます。詳細については、トランザクション回復サービスの元のサーバへの手動による返還移行を参照してください。
サーバのトランザクション回復がバックアップ サーバで完了すると、バックアップ サーバはトランザクション回復サービス (およびトランザクション ログ) の所有権を、障害が発生したサーバに解放します。障害が発生したサーバを再起動すると、このサーバはトランザクション回復サービスの所有権を再び要求しようとします。障害が発生したサーバを再起動したときに、バックアップ サーバがトランザクション回復処理中だった場合、バックアップ サーバはトランザクションの回復を中止し、内部クリーンアップを行い、トランザクション回復サービスの所有権を解放して、障害が発生したサーバがそれを再び要求して正しく起動できるようにします。その後、障害が発生したサーバでは、自身のトランザクション回復を完了します。
障害が発生したサーバのトランザクション回復サービスがまだバックアップ サーバで所有されており、障害が発生したサーバを再起動しようとしたときにバックアップ サーバが非アクティブだった場合、バックアップ サーバがトランザクション回復サービスの所有権を解放できないため、障害が発生したサーバは起動しません。これは、フェイルバック メカニズムが失敗した場合や、バックアップ サーバが管理サーバと通信できない場合にも当てはまります。トランザクション回復の移行は、Administration Console またはコマンドライン インタフェースを使用して手動で行えます。
トランザクション回復サービスを移行する場合は、以下の制限があります。
クラスタ内の障害が発生したサーバから同じクラスタ内の別のサーバ (バックアップ サーバ) へトランザクション回復サービスを移行するには、バックアップ サーバに、障害が発生したサーバのトランザクション ログ ファイルへのアクセス権が必要です。したがってトランザクション ログ ファイルは、両方の (またはさらに他の) サーバで使用できる永続ストレージに格納する必要があります。ストレージ エリア ネットワーク (SAN) デバイスまたはデュアル ポート ディスクに、トランザクション ログ ファイルを格納することをお勧めします。NFS ファイル システムを使ってトランザクション ログ ファイルを保存しないでください。NFS のキャッシング方式により、ディスク上のトランザクション ログ ファイルは常に現在のものとは限りません。NFS デバイスに保存されたトランザクション ログ ファイルを使用して回復を行うと、データが破損するおそれがあります。
トランザクション回復サービスをサーバから移行するときには、実際に移行を行う前に障害が発生している、または障害が発生したサーバを停止する必要があります。元のサーバがまだ実行中の場合は、そこからトランザクション回復サービスを移行することはできません。
トランザクション回復サービスを移行する手順の詳細については、Administration Console オンライン ヘルプの「トランザクション回復サービスの同一クラスタ内サーバへの移行」を参照してください。
クラスタ内の障害が発生したサーバからトランザクション回復サービスを移行するには、次の手順に従います。
注意: トランザクション回復サービスは、クラッシュ後にトランザクションの回復を正常に行うために設計されたものです。トランザクション回復サービスを別のサーバに移行するよりも、クラッシュしたサーバを再起動し、トランザクション回復サービスを使用して未完了のトランザクションを処理することをお勧めします。
クラスタ内のサーバに対してトランザクション回復サービスのバックアップ サーバとして使用するサーバの選択肢を制限することもできます。たとえば、クラスタ内のすべてのサーバがサーバのトランザクション ログ ファイルにアクセスできるとは限りません。Administration Console の [サーバ｜制御｜JTA 移行] タブで使用できる移行先サーバのリストを制限するには、次の手順に従います。
注意: 必要な場合には、元のサーバにトランザクション回復サービスを手動で移行して返還できるように、[選択済み] リストには移行元のサーバを含めておく必要があります。Administration Console では、この規則に従わなくてはなりません。
トランザクション回復サービスをクラスタ内の別のサーバに移行した場合、そのトランザクション回復サービスの所有権は、未完了のトランザクションがすべて完了するまでバックアップ サーバに割り当てられます。トランザクションの完了後、バックアップ サーバはトランザクション回復サービスの所有権を解放し、元のサーバは所有権の返還を要求できます。Administration Console の [サーバ｜制御｜JTA 移行] タブで、現在のオーナを参照できます。次の手順に従います。
バックアップ サーバは、障害が発生したサーバのトランザクションの回復が完了すると、トランザクション回復サービスの所有権を解放します。そのため、元のサーバは再起動時にその所有権の返還を要求できます。トランザクションの回復が完了する前に何らかの理由でバックアップ サーバが停止 (クラッシュ) すると、元のサーバはトランザクション回復サービスの所有権の返還を要求できなくなり、起動しません。[送り先サーバ] で元のサーバを選択することで、元のサーバにトランザクション回復サービスを手動で移行して返還できます。元のサーバにトランザクション回復サービスを手動で移行して返還するときには、バックアップ サーバが稼動していてはいけません。次の手順に従います。
Administration Console を使用すると、Java Transaction API (JTA) などの WebLogic Server 機能をコンフィグレーションするためのツールを利用できます。トランザクションのコンフィグレーション プロセスでは、属性の値を指定する必要があります。指定した属性によって、以下のような、トランザクション環境のさまざまな側面を定義できます。
Administration Console で行う設定は、JTA のコンフィグレーション設定も含め、そのドメインの config.xml ファイルに保持されます。このファイル内のエントリについては、『コンフィグレーション リファレンス』の以下の節を参照してください。
トランザクション環境をコンフィグレーションする前に、EJB、JDBC、JMS など、トランザクションに参加可能な J2EE コンポーネントについてよく理解しておく必要があります。
|
|
|