Oracle Fusion Middleware Oracle WebLogic Server JDBCデータ・ソースの構成と管理 11g リリース1 (10.3.6) B60997-05 |
|
![]() 前 |
![]() 次 |
この章では、マルチ・データ・ソースを構成および使用して、接続リクエスト時に、マルチ・データ・ソースと関連付けられたデータ・ソース間のロード・バランシングまたはフェイルオーバー処理を提供する方法について説明します。
マルチ・データ・ソースとは、データ・ソースが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マルチ・データ・ソース・モジュールの作成」も参照してください。
マルチ・データ・ソースを設定する前に、その主要な目的、つまりフェイルオーバーまたはロード・バランシングのいずれかを指定する必要があります。アルゴリズムは、各自のニーズにあわせて選択できます。
フェイルオーバー・アルゴリズムは、接続リクエストに応じるために使用するデータ・ソースの順序付けされたリストを提供します。通常、このタイプのマルチ・データ・ソースへのすべての接続リクエストは、リストの最初のデータ・ソースによって処理されます。データベース接続テストが失敗し、かつその接続を置き換えられない場合、またはデータ・ソースが中断されている場合、そのリストの次のデータ・ソースから順番に接続が選択されます。
注意: このアルゴリズムでは、データ・ソースの「予約時に接続のテスト」( 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データ・ソースのターゲット指定とデプロイに関する項を参照してください。