| Oracle® Fusion Middleware Oracle WebLogic Server JDBCデータ・ソースの構成と管理 11gリリース1 (10.3.6) B60997-04 |
|
 前 |
 次 |
| Oracle® Fusion Middleware Oracle WebLogic Server JDBCデータ・ソースの構成と管理 11gリリース1 (10.3.6) B60997-04 |
|
前 |
次 |
この章では、マルチ・データ・ソースを構成および使用して、接続リクエスト時に、マルチ・データ・ソースと関連付けられたデータ・ソース間のロード・バランシングまたはフェイルオーバー処理を提供する方法について説明します。
マルチ・データ・ソースとは、データ・ソースがJNDIツリーにバインドされるのと同じように、JNDIツリーまたはローカル・アプリケーション・コンテキストにバインドされるデータ・ソースのグループ周辺を抽象化したものです。アプリケーションは、データ・ソースの場合と同じようにJNDIツリー上のマルチ・データ・ソースまたはローカル・アプリケーション・コンテキスト(java:comp/env)内のマルチ・データ・ソースをルックアップし、その後データベース接続をリクエストします。マルチ・データ・ソースは、そのマルチ・データ・ソースの構成内で選択されるアルゴリズムに応じて、リクエストを満たすためにロード・バランシングとフェイルオーバーのうちどちらのデータ・ソースを使用するかを決定します。
この項は、次の情報を含みます。
マルチ・データ・ソースは、データ・ソースのプールであると捉えることができます。マルチ・データ・ソースは、冗長なデータベースやOracle Real Application Clusters (Oracle RAC)など、可用性の高いデータベース・システムのノード間でのフェイルオーバーまたはロード・バランシングに最適です。
マルチ・データ・ソースのデータ・ソース・メンバー・リストは、動的な更新をサポートしています。これによって、Oracle RACなどを使用する環境で、再デプロイメントすることなく、データベース・ノードと対応するデータ・ソースを追加および削除でき、次のことができます。
スループットに応じてOracle RACクラスタを拡大および縮小します。「データベース・ノードの追加」を参照してください。
メンテナンスのためOracle RACノードを停止します。「データベース・ノードの削除」を参照してください。
「Oracle RACでのマルチ・データ・ソースの使用」を参照してください。
|
注意: マルチ・データ・ソースは、データベース同士を同期させるものではありません。データベースの同期は、データの整合性が保たれるよう、WebLogic Serverの外部で適切に処理されることが前提となっています。 |
再デプロイメントせずに、データベース・ノードと対応するデータ・ソースを削除することができます。この機能によって、メンテナンスのためにノードを停止したり、クラスタを縮小できます。以下の手順に従って、データベース・ノードを停止します。
|
注意: これらの手順に失敗した場合、トランザクションがロールバックされる場合があります。 |
データ・ソースをマルチ・データ・ソースから削除します。Oracle WebLogic Server管理コンソール・ヘルプのJDBCマルチ・データ・ソース内のデータ・ソースの追加または削除に関する項を参照してください。
すべてのトランザクションの終了後、データ・ソースを一時停止します。Oracle WebLogic Server管理コンソール・ヘルプのJDBCデータ・ソースの一時停止に関する項を参照してください。
すべてのトランザクションの終了後、データ・ソースを停止します。Oracle WebLogic Server管理コンソール・ヘルプのJDBCデータ・ソースの停止に関する項を参照してください。
データベース・ノードを停止します。
再デプロイメントせずに、データベース・ノードと対応するデータ・ソースを追加することができます。この機能によって、メンテナンス後にノードを起動したり、クラスタを拡張できます。次のハイレベルの手順に従って、データベース・ノードを追加します。
データベース・ノードを再起動します。
データ・ソースを再起動します。Oracle WebLogic Server管理コンソール・ヘルプのJDBCデータ・ソースの開始に関する項を参照してください。
データ・ソースを再度マルチ・データ・ソースに追加します。Oracle WebLogic Server管理コンソール・ヘルプのJDBCマルチ・データ・ソース内のデータ・ソースの追加または削除に関する項を参照してください。
マルチ・データ・ソースを作成するには、まずデータ・ソースを作成し、次に管理コンソールまたはWebLogic Scripting Toolでマルチ・データ・ソースを作成して、その後データ・ソースをマルチ・データ・ソースに割り当てます。
マルチ・データ・ソースの作成方法は、Oracle WebLogic Server管理コンソール・ヘルプのJDBCマルチ・データ・ソースの構成に関する項を参照してください。
マルチ・データ・ソースの構成時に作成される構成ファイルについては、「WebLogic ServerにおけるJDBCリソースについて」を参照してください。また、「JDBCマルチ・データ・ソース・モジュールの作成」も参照してください。
マルチ・データ・ソースを設定する前に、その主要な目的、つまりフェイルオーバーまたはロード・バランシングのいずれかを指定する必要があります。アルゴリズムは、各自のニーズにあわせて選択できます。
フェイルオーバー・アルゴリズムは、接続リクエストに応じるために使用するデータ・ソースの順序付けされたリストを提供します。通常、このタイプのマルチ・データ・ソースへのすべての接続リクエストは、リストの最初のデータ・ソースによって処理されます。データベース接続テストが失敗し、かつその接続を置き換えられない場合、またはデータ・ソースが中断されている場合、そのリストの次のデータ・ソースから順番に接続が選択されます。
|
注意: このアルゴリズムでは、データ・ソースの「予約時に接続のテスト」(TestConnectionsOnReserve)を有効化する必要があります。有効になっている場合、最初のデータ・ソース内の接続をテストして、データ・ソースが正常であるかどうかを確認します。テストに失敗した場合、マルチ・データ・ソースにリストされている次のデータ・ソースの接続が使用されます。TestConnectionsOnReserveの構成については、「データ・ソースの接続テスト・オプション」を参照してください。
JDBCは、クライアントとDBMS間の高度にステートフルなプロトコルです。JDBCでは、DBMS接続とトランザクション状態が、DBMSプロセスとクライアント(ドライバ)の間のソケットに直接関連付けられます。このため、使用中の接続のフェイルオーバーはサポートされません。 |
ロード・バランシング・マルチ・データ・ソースへの接続リクエストは、リスト内の任意のデータ・ソースから処理されます。マルチ・データ・ソースは、ラウンドロビン方式で接続リクエストに応じるためのデータ・ソースを選択します。マルチ・データ・ソースは接続を提供する際、最後に使用されたデータ・ソースの直後にリストされているデータ・ソースからの接続を選択します。ロード・バランシング・アルゴリズムを使用するマルチ・データ・ソースも、データベース接続テストが失敗して接続を置き換えられない場合、またはデータ・ソースが中断されている場合、リスト内の次のデータ・ソースにフェイルオーバーされます。
WebLogic Serverはマルチ・データ・ソース用のフェイルオーバー・アルゴリズムを備えており、データ・ソースで障害(データベース管理システムのクラッシュなど)が発生しても、システムをそのまま稼働させることができます。ただし、システムを構成する際は、以下の制限と要件を考慮する必要があります。
データ・ソースは、「予約時に接続のテスト」(TestConnectionsOnReserve)機能に依存して、いつデータベース接続が失われるかを確認します。マルチ・データ・ソース内のデータ・ソースの「予約時に接続のテスト」機能を有効化する必要があります。各接続をアプリケーションに渡す前にWebLogic Serverでテストします。フェイルオーバー・アルゴリズムを使用して、マルチ・データ・ソースは接続テストの結果によって、マルチ・データ・ソース内の次のデータ・ソースにフェイルオーバーするタイミングを決定します。テストに失敗した場合、データ・ソースは、接続を再試行します。それにも失敗した場合、マルチ・データ・ソースは次のデータ・ソースにフェイルオーバーします。
次の拡張により、マルチ・データ・ソースのフェイルオーバー処理が向上します。
接続リクエストのルーティングを拡張し、マルチ・データ・ソース内の自動的に無効化された(失効した)データ・ソースからの接続のリクエストを回避します。「データ・ソースの障害発生時における接続リクエストのルーティング機能の拡張」を参照してください。
マルチ・データ・ソース内の障害の発生したデータ・ソースがリカバリした場合の自動的なフェイルバック。「マルチ・データ・ソース内の障害が発生したデータ・ソースがリカバリした場合の自動的な再有効化」を参照してください。
マルチ・データ・ソース内のビジー状態のデータ・ソースのフェイルオーバー。「マルチ・データ・ソース内のビジー状態のデータ・ソースのフェイルオーバーの有効化」を参照してください。
フェイルオーバー・アルゴリズムが設定されたマルチ・データ・ソースに対するフェイルオーバーのコールバック。「コールバックによるマルチ・データ・ソース・フェイルオーバーの制御」を参照してください。
いずれかのアルゴリズムを使用するマルチ・データ・ソースに対するフェイルバックのコールバック。「コールバックによるマルチ・データ・ソース・フェイルバックの制御」を参照してください。
マルチ・データ・ソース内のデータ・ソースで障害が発生したときのパフォーマンスを向上させるため、WebLogic Serverはプールされた接続が接続テストで失敗すると、データ・ソースを自動的に無効化します。データ・ソースが無効化されると、アプリケーションからそのデータ・ソースに接続リクエストがルーティングされなくなります。その代わり、マルチ・データ・ソース内にリストされた次の利用可能なデータ・ソースに接続リクエストがルーティングされます。
この機能を使用するには、データ・ソース・テスト・オプション(特に「表名のテスト」および「予約時に接続のテスト」)がマルチ・データ・ソース内のすべてのデータ・ソースに対して構成されていることが必要です。「データ・ソースの接続テスト・オプション」を参照してください。
マルチ・データ・ソースに対してコールバック・ハンドラが登録されている場合、コールバック・ハンドラが呼び出されてから、リスト内の次のデータ・ソースにフェイルオーバーされます。詳細は、「コールバックによるマルチ・データ・ソース・フェイルオーバーの制御」を参照してください。
接続に失敗してデータ・ソースが自動的に無効になった場合、マルチ・データ・ソースは、無効になったデータ・ソースからの接続を定期的にテストし、データ・ソース(または基礎となるデータベース)がいつ再度有効になるかを決定します。データ・ソースが使用可能になると、マルチ・データ・ソースがデータ・ソースを自動的に再有効化し、マルチ・データ・ソース・アルゴリズムおよび含まれるデータ・ソース・リスト内のデータ・ソースの位置によって、データ・ソースにルーティングする接続リクエストを再開します。これらのテストの頻度は、マルチ・データ・ソースの「テスト間隔」属性によって制御されます。テスト頻度のデフォルト値は120秒なので、特にこのオプションの値を設定しない場合は、マルチ・データ・ソースは無効化されたデータ・ソースを120秒おきにテストします。Oracle WebLogic Server管理コンソール・ヘルプの「JDBCマルチ・データ・ソース: 構成: 一般」を参照してください。
手動で無効化したデータ・ソースに対してはテストも自動的な再有効化も行われません。自動的に無効化されたデータ・ソースだけがテストされます。
マルチ・データ・ソースに対してコールバック・ハンドラが登録されている場合、コールバック・ハンドラが呼び出されてから、データ・ソースの再有効化が行われます。詳細は、「コールバックによるマルチ・データ・ソース・フェイルバックの制御」を参照してください。
デフォルトでは、フェイルオーバー・アルゴリズムを使用するマルチ・データ・ソースの場合、データベース接続に対するリクエスト数が、マルチ・データ・ソース内の現在のデータ・ソースにある利用可能な接続数を超過すると、以降の接続リクエストが失敗します。
現在のデータ・ソースのすべての接続が使用されている場合にマルチ・データ・ソースがフェイルオーバーできるようにするには、管理コンソールの「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などの絶対名を指定する必要があります。管理コンソールを使用してフェイルオーバーのコールバック・ハンドラを設定できます。(Oracle WebLogic Server管理コンソール・ヘルプのフェイルオーバーのコールバック・ハンドラの登録に関する項を参照)または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属性で決められている設定に従って次のテスト・サイクル中にデータ・ソースを再有効化しようとし、そのプロセスの一部としてコールバック・ハンドラを呼び出します。
マルチ・データ・ソース内でのデータ・ソースのリスト順は、非常に重要です。フェイルオーバー・アルゴリズムを使用するマルチ・データ・ソースは常に、マルチ・データ・ソース内のデータ・ソース・リストで最初に利用可能なデータ・ソースからの接続リクエストを処理しようとします。次のシナリオを検討してください。
フェイルオーバー・アルゴリズムを使用するMultiDataSource_1には、登録されたConnectionPoolFailoverCallbackHandlerがあり、DS1、DS2、およびDS3という順序でリストされている3つのデータ・ソースが含まれています。
DS1が無効化されると、MultiDataSource_1では接続リクエストがDS2にフェイルオーバーされます。
DS2が無効化されると、MultiDataSource_1では接続リクエストがDS3にフェイルオーバーされます。
しばらく経つと、DS1が再び利用可能になり、コールバック・ハンドラによってWebLogic Serverによるデータ・ソースの再有効化が許可されます。DS1はマルチ・データ・ソース内にリストされた最初のデータ・ソースなので、以降の接続リクエストは、DS1によって処理されます。
続いてDS2が利用可能になり、コールバック・ハンドラによってWebLogic Serverによるデータ・ソースの再有効化が許可されても、データ・ソースのリストでDS1はDS2の前にリストされているので、接続リクエストは引続きDS1によって処理されます。
接続リクエストに応じるためにマルチ・データ・ソースで使用されているデータ・ソースはすべて、マルチ・データ・ソースと同じサーバーおよびクラスタにデプロイされている必要があります。マルチ・データ・ソースは、常に同じサーバーにデプロイされているデータ・ソースを使用して、接続リストに応じます。マルチ・データ・ソースは、クラスタまたはドメイン内の他のサーバーへの接続リクエストのルーティングは行いません。
マルチ・データ・ソースをクラスタまたはサーバーにデプロイするには、サーバーまたはクラスタをデプロイメント対象として選択します。サーバーにマルチ・データ・ソースをデプロイする場合、そのサーバー上にマルチ・データ・ソースのインスタンスが作成されます。クラスタにマルチ・データ・ソースをデプロイする場合、クラスタ内の各サーバー上にマルチ・データ・ソースのインスタンスが作成されます。
手順については、Oracle WebLogic Server管理コンソール・ヘルプのJDBCデータ・ソースのターゲット指定とデプロイに関する項を参照してください。
