WebLogic JDBC のコンフィグレーションと管理
|
 |
 |
|
マルチ データ ソースは、マルチ データ ソースと関連付けられたデータ ソース間のロード バランシングまたはフェイルオーバ処理を提供する、データ ソースのグループ周辺を抽象化したものです。マルチ データ ソースは、データ ソースが JNDI ツリーにバインドされるのと同じように、JNDI ツリーまたはローカル アプリケーション コンテキストにバインドされます。アプリケーションは、データ ソースの場合と同じように JNDI ツリー上のマルチ データ ソースまたはローカル アプリケーション コンテキスト (java:comp/env) 内のマルチ データ ソースをルックアップし、その後データベース接続を要求します。マルチ データ ソースは、そのマルチ データ ソースのコンフィグレーション内で選択されるアルゴリズムに応じて、要求を満たすためにロード バランシングとフェイルオーバのうちどちらのデータ ソースを使用するかを決定します。
マルチ データ ソースは、データ ソースのプールであると捉えることができます。マルチ データ ソースは、冗長なデータベースや Oracle Real Application Clusters (RAC) など、可用性の高いデータベース システムのノード間でのフェイルオーバまたはロード バランシングに最適です。WebLogic Server での Oracle RAC の使い方の詳細については、「WebLogic Server での Oracle RAC の使い方」を参照してください。
マルチ データ ソースは、データベース同士を同期させるものではありません。データベースの同期は、データの整合性が保たれるよう、WebLogic Server の外部で適切に処理されることが前提となっています。
マルチ データ ソースを作成するには、まずデータ ソースを作成し、次に Administration Console または WebLogic Scripting Tool でマルチ データ ソースを作成して、その後データ ソースをマルチ データ ソースに割り当てます。
マルチ データ ソースを作成する手順については、Administration Console オンライン ヘルプの「JDBC マルチ データ ソースのコンフィグレーション」を参照してください。
マルチ データ ソースのコンフィグレーション時に作成されるコンフィグレーション ファイルについては、「WebLogic Server における JDBC リソースについて」を参照してください。また、「JDBC マルチ データ ソース モジュールの作成」も参照してください。
マルチ データ ソースからのデータベース接続がグローバル トランザクションに参加できるようにするには、マルチ データ ソースで使用されているすべてのデータ ソースが、次の条件に合致している必要があります。
これらのオプションの詳細については、Administration Console の [JDBC データ ソース : コンフィグレーション : 接続プール] ページを参照してください。また、『WebLogic Server MBean リファレンス』の「JDBCXAParamsBean」も参照してください。
グローバル トランザクションをサポートするマルチ データ ソース コンフィグレーションの例については、「グローバル トランザクションを利用する場合のマルチ データ ソースの使用」を参照してください。
マルチ データ ソースからの接続が、グローバル トランザクションの進行中に失敗した場合、トランザクションの結果は接続障害が発生した時点でトランザクションが置かれていた段階によって決まります。
最初に障害が発生する可能性のある段階は、アプリケーションでトランザクションをコミットする呼び出しを行う前です。データベース接続にこの段階で障害が発生すると、アプリケーションは例外を受け取ります。アプリケーションでは新しい接続を取得して、新たにトランザクションの処理を試行する必要があります。WebLogic Server では透過的なフェイルオーバはサポートされていません。
アプリケーションでトランザクションをコミットする呼び出しを行った後で障害が発生した場合、処理中の任意のトランザクション処理は PREPARE 操作が完了しているかどうかによって変わります。PREPARE 操作が完了していない場合、トランザクション マネージャによってトランザクションはロールバックされ、アプリケーションにトランザクション障害の例外が送出されます。PREPARE 操作が完了している場合、トランザクション マネージャでは別の接続を使用して処理中のトランザクションを完了しようとします。
COMMIT 操作の間に障害が発生した場合、トランザクション マネージャでは COMMIT 操作を複数回、再試行します。この複数回の試行中、接続はブロックされます。COMMIT 操作が再試行の最初のセットで成功しない場合、アプリケーションは例外を受け取ります。トランザクション マネージャでは、成功するか、コンフィグレーション ファイルに定義された JTA の破棄タイムアウト期間に達するまで、定期的に COMMIT 操作の再試行が続けられ、その後トランザクションが中止されます。
マルチ データ ソースを設定する前に、その主要な目的、つまりフェイルオーバまたはロード バランシングのいずれかを指定する必要があります。アルゴリズムは、各自のニーズに合わせて選択できます。
フェイルオーバ アルゴリズムは、接続リクエストに応じるために使用するデータ ソースの順序付けされたリストを提供します。通常、このタイプのマルチ データ ソースへのすべての接続リクエストは、リストの最初のデータ ソースによって処理されます。データベース接続テストが失敗し、かつその接続を置き換えられない場合、またはデータ ソースが中断されている場合、そのリストの次のデータ ソースから順番に接続が選択されます。
注意 : このアルゴリズムは、データ ソースの状態が正常かどうかを確認するために最初のデータ ソースの接続をテストする、データ ソースに対する [Test Reserved Connections] (TestConnectionsOnReserve) に依存しています。接続がテストに失敗した場合、マルチ データ ソースでは、リストの次のデータ ソースからの接続を使用します。TestConnectionsOnReserve のコンフィグレーションについては、「データソースの接続テスト オプション」を参照してください。
JDBC は、クライアントと DBMS 間の高度にステートフルなプロトコルです。JDBC では、DBMS 接続とトランザクションのステートが、DBMS プロセスとクライアント (ドライバ) の間のソケットに直接関連付けられます。このため、使用中の接続のフェイルオーバはサポートされません。
ロード バランシング マルチ データ ソースへの接続リクエストは、リスト内の任意のデータ ソースから処理されます。マルチ データ ソースは、ラウンドロビン方式で接続リクエストに応じるためのデータ ソースを選択します。マルチ データ ソースは接続を提供する際、最後に使用されたデータ ソースの直後にリストされているデータ ソースからの接続を選択します。ロード バランシング アルゴリズムを使用するマルチ データ ソースも、データベース接続テストが失敗して接続を置き換えられない場合、またはデータ ソースが中断されている場合、リスト内の次のデータ ソースにフェイルオーバされます。
WebLogic Server はマルチ データ ソース用のフェイルオーバ アルゴリズムを備えており、データ ソースで障害 (データベース管理システムのクラッシュなど) が発生しても、システムをそのまま稼働させることができます。ただし、システムをコンフィグレーションする際は、以下の制限と要件を考慮する必要があります。
データ ソースでは、いつデータベース接続が失われたかを識別するために [Test Reserved Connections] (TestConnectionsOnReserve) 機能を使用します。マルチ データ ソース内のデータ ソースに対する予約済みの接続のテストは、有効化されている必要があります (デフォルト)。WebLogic Server は、各接続をアプリケーションに渡す前に、接続テストを行います。フェイルオーバ アルゴリズムにより、マルチ データ ソースでは接続テスト結果を使用して、いつマルチ データ ソース内で次のデータ ソースにフェイルオーバするかを判断します。テストが失敗すると、データ ソースは接続を再作成しようとします。それが失敗すると、マルチ データ ソースは次のデータ ソースにフェイルオーバします。
予約後に接続が失敗する可能性もありますが、これについてはアプリケーションで処理する必要があります。WebLogic Server では、アプリケーションで使用中に失敗した接続をフェイルオーバさせることはできません。接続の使用中に障害が発生した場合は、トランザクションをやり直す必要があり、こうした障害が処理できるようにコーディングしておく必要があります。
WebLogic Server 9.0 では、マルチ データ ソースのフェイルオーバ処理に対して、以下の拡張が行われています。
マルチ データ ソース内のデータ ソースで障害が発生したときのパフォーマンスを向上させるため、WebLogic Server はプールされた接続が接続テストで失敗すると、データ ソースを自動的に無効化します。データ ソースが無効化されると、アプリケーションからそのデータ ソースに接続リクエストがルーティングされなくなります。その代わり、マルチ データ ソース内にリストされた次の利用可能なデータ ソースに接続リクエストがルーティングされます。
この機能を使うには、データ ソース テスト オプション (特に [テスト対象のテーブル名] および [Test Reserved Connections]) がマルチ データ ソース内のすべてのデータ ソースに対してコンフィグレーションされていることが必要です。「データソースの接続テスト オプション」を参照してください。
マルチ データ ソースに対してコールバック ハンドラが登録されている場合、コールバック ハンドラが呼び出されてから、リスト内の次のデータ ソースにフェイルオーバされます。詳細については、「コールバックによるマルチ データ ソース フェイルオーバの制御」を参照してください。
接続が接続テストに失敗したためにデータ ソースが自動的に無効化されると、マルチ データ ソースでは、無効化されたデータ ソースからの接続が定期的にテストされ、データ ソース (または基底のデータベース) が再び利用可能になっているかどうかの確認が行われます。データ ソースが利用可能ならば、マルチ データ ソースはデータ ソースを自動的に再有効化し、マルチ データ ソースのアルゴリズムおよび含まれるデータ ソースのリストにおけるデータ ソースの位置に応じて、データ ソースへの接続リクエストのルーティングを再開します。これらのテストの頻度は、マルチ データ ソースの [テスト間隔 (秒)] 属性によって制御されます。テスト頻度オプションは、現在 Administration Console では使用できませんが、マルチ データ ソースの JDBCConnectionPoolParamsBean では使用可能です。テスト間隔のデフォルト値は 120 秒なので、このオプションに特定の値を設定しなければ、マルチ データ ソースは無効化されたデータ ソースを 120 秒ごとにテストします。
手動で無効化したデータ ソースに対してはテストも自動的な再有効化も行われません。自動的に無効化されたデータ ソースだけがテストされます。
マルチ データ ソースに対してコールバック ハンドラが登録されている場合、コールバック ハンドラが呼び出されてから、データ ソースの再有効化が行われます。詳細については、「コールバックによるマルチ データ ソース フェイルバックの制御」を参照してください。
デフォルトでは、フェイルオーバ アルゴリズムを使用するマルチ データ ソースの場合、データベース接続に対するリクエスト数が、マルチ データ ソース内の現在のデータ ソースにある利用可能な接続数を超過すると、以降の接続リクエストが失敗します。
現在のデータ ソース内のすべての接続が使用中の場合にマルチ データ ソースのフェイルオーバを有効化するには、Administration Console の [JDBC マルチ データ ソース : コンフィグレーション : 全般] ページで [ビジー時は要求をフェイルオーバ] オプション (JDBCDataSourceParamsBean の FailoverRequestIfBusy 属性としても利用可能) を有効化します。これを有効化 (true に設定) すると、現在のデータ ソースにあるすべての接続が使用中の場合に、マルチ データ ソース内の次の利用可能なデータ ソースにアプリケーションの接続リクエストがルーティングされます。無効化 (false に設定。デフォルト) すると、接続リクエストのフェイルオーバは行われません。
マルチ データ ソースのコンフィグレーションに ConnectionPoolFailoverCallbackHandler が含まれている場合、コールバック ハンドラが呼び出されてから、フェイルオーバが行われます。詳細については、「コールバックによるマルチ データ ソース フェイルオーバの制御」を参照してください。
WebLogic Server には、フェイルオーバ アルゴリズムが設定されたマルチ データ ソースが、どのタイミングでマルチ データ ソース内の、ある JDBC データ ソースからの接続リクエストを、リスト内の次のデータ ソースにフェイルオーバするかを制御する、コールバック ハンドラを登録することができます。
コールバック ハンドラを使用すると、フェイルオーバを行うかどうか、またはフェイルオーバを行う時期を制御できるので、フェイルオーバの前にデータベースの準備、高可用性フレームワークとの通信などのその他のシステム準備を行うことができます。
コールバック ハンドラは、マルチ データ ソースの [フェイルオーバのコールバック ハンドラ] 属性を介して、マルチ データ ソースごとに登録されます。コールバック ハンドラを適用する各マルチ データ ソースに、コールバック ハンドラを登録する必要があります。また、ドメイン内の各マルチ データ ソースについて、別々のコールバック ハンドラを登録することができます。
マルチ データ ソース内のフェイルオーバおよびフェイルバックの制御に使用されるコールバック ハンドラには、weblogic.jdbc.extensions.ConnectionPoolFailoverCallback インタフェースの実装が含まれていなければなりません。マルチ データ ソースでリスト内の次のデータ ソースにフェイルオーバする必要がある場合や、以前に無効化されたデータ ソースが利用可能になった場合、ConnectionPoolFailoverCallback インタフェースの allowPoolFailover() メソッドが呼び出され、以下に定義されている 3 つのパラメータ (currPool、nextPool、および opcode) の値が渡されます。コールバック ハンドラからの戻り値を待機してからタスクが完了されます。
アプリケーションは、以下に定義されている OK、RETRY_CURRENT、または DONOT_FAILOVER を返す必要があります。アプリケーションはフェイルオーバおよびフェイルバックの個々の状況を処理しなければなりません。
詳細については、weblogic.jdbc.extensions.ConnectionPoolFailoverCallback インタフェースの Javadoc を参照してください。
注意 : フェイルオーバのコールバック ハンドラは、任意指定です。マルチ データ ソースのコンフィグレーションにコールバック ハンドラが指定されていなければ、WebLogic Server は操作 (フェイルオーバまたは無効化されたデータ ソースの再有効化) を続行します。
フェイルオーバおよびフェイルバック機能に関連付けられたマルチ データ ソースのコンフィグレーション属性には、以下の 2 つがあります。
ConnectionPoolFailoverCallbackHandler) - マルチ データ ソースのフェイルオーバのコールバック ハンドラを登録するには、マルチ データ ソースのコンフィグレーションにこの属性の値を追加します。値はcom.bea.samples.wls.jdbc.MultiDataSourceFailoverCallbackApplication などの絶対名でなければなりません。フェイルオーバのコールバック ハンドラは、Administration Console を使用して (「フェイルオーバのコールバック ハンドラの登録」を参照)、または WLST を使用するマルチ データ ソースの JDBCDataSourceParamsBean で設定できます。TestFrequencySeconds) - マルチ データ ソースによる、無効化された (応答のない) データ ソースが利用可能になったかどうかのチェック頻度を制御します。詳細については、「マルチ データ ソース内の障害が発生したデータ ソースが回復した場合の自動的な再有効化」を参照してください。WebLogic Server は、現在のデータ ソースで接続テストが失敗した場合や、FailoverRequestIfBusy が有効化されているときに現在のデータ ソース内のすべての接続が使用中である場合に、接続リクエストをリスト内の次のデータ ソースにフェイルオーバしようとします。
コールバック機能を有効化するには、マルチ データ ソースのコンフィグレーションで [フェイルオーバのコールバック ハンドラ] を使用して、コールバック ハンドラを WebLogic Server に登録します。
フェイルオーバ アルゴリズムを使用する場合、接続リクエストはリスト内の最初のデータ ソースから処理されます。データ ソースからの接続が接続テストに失敗すると、WebLogic Server はそのデータ ソースを「応答なし」としてマーク付けし、無効にします。コールバック ハンドラが登録されている場合、WebLogic Server は以下の情報を渡してコールバック ハンドラを呼び出し、戻り値を待機します。
currPool － フェイルオーバの場合、データベース接続の提供に現在使用されているデータ ソースの名前。「フェイルオーバ元」のデータ ソースになります。nextPool － マルチ データ ソース内にリストされた次の利用可能なデータ ソースの名前。フェイルオーバの場合、「フェイルオーバ先」のデータ ソースになります。opcode － 呼び出しの理由を示すコード。 OPCODE_CURR_POOL_DEAD － WebLogic Server によって、現在のデータ ソースが応答しないと判断され、無効化されたことを示す。 OPCODE_CURR_POOL_BUSY － データ ソース内のすべてのデータベース接続が使用中であることを示す (マルチ データ ソースのコンフィグレーションに FailoverIfBusy=true が必要。「マルチ データ ソース内のビジー状態のデータ ソースのフェイルオーバの有効化」を参照してください)。フェイルオーバは接続リクエストと同期します。フェイルオーバは、WebLogic Server が接続リクエストに応じようとする場合にのみ発生します。
コールバック ハンドラからの戻り値は、以下の 3 種類のオプションのいずれかを示します。
OK － 処理を続行する。この場合、リスト内の次のデータ ソースにフェイルオーバすることを意味します。RETRY_CURRENT － 接続リクエストを現在のデータ ソースで再試行する。DONOT_FAILOVER － 現在の接続リクエストを再試行せず、かつ、フェイルオーバも行わない。WebLogic Server によって weblogic.jdbc.extensions.PoolUnavailableSQLException が送出されます。 WebLogic Server はコールバック ハンドラによって返された値に従って処理を行います。
2 番目のデータ ソースで障害が発生すると、先のフェイルオーバと同様、マルチ データ ソース内の次の利用可能なデータ ソースにフェイルオーバしようと再びコールバック ハンドラが呼び出されます (データ ソースが存在している場合)。
注意 : データ ソースを手動で無効化した場合、WebLogic Server はコールバック ハンドラを呼び出しません。
ロード バランシング アルゴリズムを使用するマルチ データ ソースの場合、WebLogic Server ではデータ ソースが無効化されても、コールバック ハンドラは呼び出されません。ただし、無効化されたデータ ソースを再有効化しようとする場合にはコールバック ハンドラが呼び出されます。詳細については、次の節を参照してください。
マルチ データ ソースに対してフェイルオーバのコールバック ハンドラが登録されている場合、WebLogic Server では、自動的に無効化されたデータ ソースを再有効化するときに同じコールバック ハンドラが呼び出されます。コールバックを使用すると、無効化されたデータ ソースを再有効化するかどうか、または再有効化を行う時期を制御できるので、データ ソースを再有効化する前にデータベースの準備、高可用性フレームワークとの通信などのその他のシステム準備を行うことができます。
コールバック ハンドラの詳細については、以下の節を参照してください。
WebLogic Server では、マルチ データ ソース内の自動的に無効化されたデータ ソースのステータスが定期的にチェックされます (「マルチ データ ソース内の障害が発生したデータ ソースが回復した場合の自動的な再有効化」を参照してください)。無効化されたデータ ソースが利用可能になった場合、およびフェイルオーバのコールバック ハンドラが登録されている場合、WebLogic Server は以下の情報を持つコールバック ハンドラを呼び出して、戻り値を待機します。
currPool － フェイルバックの場合、以前に無効化されたものの現在利用可能になっており、再有効化予定のデータ ソースの名前。 nextPool － フェイルバックの場合、null。opcode － 呼び出しの理由を示すコード。フェイルバックの場合、コードは常に OPCODE_REENABLE_CURR_POOL であり、currPool に名前のあるデータ ソースが現在利用可能であることを示します。フェイルバック (つまり、無効化されたデータ ソースを自動的に再有効化すること) は、フェイルオーバが接続リクエストと同期しているものの、フェイルバックは接続リクエストと同期していないという点でフェイルオーバとは異なります。
コールバック ハンドラは、以下の値のいずれかを返すことができます。
OK － 処理を続行する。この場合、示されたデータ ソースを再有効化することを意味します。マルチ データ ソースのアルゴリズムとリスト内のデータ ソースの位置に応じてそのデータ ソースに対する接続リクエストのルーティングが再開されます。DONOT_FAILOVER －currPool データ ソースを再有効化しない。使用中のデータ ソースで接続リクエストを処理し続けます。WebLogic Server はコールバック ハンドラによって返された値に従って処理を行います。
コールバック ハンドラが DONOT_FAILOVER を返した場合、WebLogic Server はマルチ データ ソースのコンフィグレーションの TestFrequencySeconds 属性で決められている設定に従って次のテスト サイクル中にデータ ソースを再有効化しようとし、そのプロセスの一部としてコールバック ハンドラを呼び出します。
マルチ データ ソース内でのデータ ソースのリスト順は、非常に重要です。フェイルオーバ アルゴリズムを使用するマルチ データ ソースは常に、マルチ データ ソース内のデータ ソース リストで最初に利用可能なデータ ソースからの接続リクエストを処理しようとします。以下のシナリオを検討してください。
フェイルオーバ アルゴリズムを使用する TestFrequencySeconds には、登録された ConnectionPoolFailoverCallbackHandler があり、DS1、DS2、および DS3 という順序でリストされている 3 つのデータ ソースが含まれています。
DS1 が無効化されると、MultiDataSource_1 では接続リクエストが DS2 にフェイルオーバされます。
DS2 が無効化されると、MultiDataSource_1 では接続リクエストが DS3 にフェイルオーバされます。
しばらく経つと、DS1 が再び利用可能になり、コールバック ハンドラによって WebLogic Server によるデータ ソースの再有効化が許可されます。DS1 はマルチ データ ソース内にリストされた最初のデータ ソースなので、以降の接続リクエストは、DS1 によって処理されます。
続いて DS2 が利用可能になり、コールバック ハンドラによって WebLogic Server によるデータ ソースの再有効化が許可されても、データ ソースのリストで DS1 は DS2 の前にリストされているので、接続リクエストは引き続き DS1 によって処理されます。
接続リクエストに応じるためにマルチ データ ソースで使用されているデータ ソースはすべて、マルチ データ ソースと同じサーバおよびクラスタにデプロイされている必要があります。マルチ データ ソースは、常に同じサーバにデプロイされているデータ ソースを使用して、接続リストに応じます。マルチ データ ソースは、クラスタまたはドメイン内の他のサーバへの接続リクエストのルーティングは行いません。
マルチ データ ソースをクラスタまたはサーバにデプロイするには、サーバまたはクラスタをデプロイメント対象として選択します。サーバにマルチ データ ソースをデプロイする場合、そのサーバ上にマルチ データ ソースのインスタンスが作成されます。クラスタにマルチ データ ソースをデプロイする場合、クラスタ内の各サーバ上にマルチ データ ソースのインスタンスが作成されます。
手順については、Administration Console オンライン ヘルプの「JDBC マルチ データ ソースの対象指定とデプロイ」を参照してください。
|
|
|