1. Oracle WebLogic Server JDBCデータ・ソースの管理
  2. JDBCデータ・ソース・タイプ
  3. JDBCマルチ・データ・ソースの使用

JDBCマルチ・データ・ソースの使用

マルチ・データ・ソース(MDS)とは、汎用データ・ソースがJNDIツリーにバインドされるのと同じように、JNDIツリーまたはローカル・アプリケーション・コンテキストにバインドされる汎用データ・ソースのグループを抽象化したものです。MDSを構成して、接続リクエスト時に、そのMDSに関連付けられた汎用データ・ソース間のロード・バランシングまたはフェイルオーバー処理を提供できます。

汎用データ・ソースの詳細は、汎用データ・ソースの使用を参照してください。

アプリケーションは、汎用データ・ソースの場合と同じようにJNDIツリー上のMDSまたはローカル・アプリケーション・コンテキスト(java:comp/env)内のMDSをルックアップし、その後データベース接続をリクエストします。MDSによって、MDS構成で選択されたアルゴリズム(ロード・バランシングまたはフェイルオーバー)に応じて、リクエストに対応するために使用する汎用データ・ソースが決定されます。

ノート:

Active GridLinkとマルチ・データ・ソースは、Oracle RACクラスタと連動するように設計されています。汎用データ・ソースをOracle RACクラスタとともに使用することはお薦めしません。「Oracle RACの停止に対する汎用データ・ソースの処理」を参照してください。

  • マルチ・データ・ソースとは
    マルチ・データ・ソースは、Oracle Real Application Clusters(Oracle RAC)など、可用性の高いデータベース・システムのノード間のフェイルオーバーまたはロード・バランシングに使用されます。MDSソースの汎用データ・ソース・メンバー・リストは、動的な更新をサポートしています。この機能により、Oracle RAC環境では、データベース・ノードおよび対応する汎用データ・ソースを再デプロイメントなしで追加および削除し、スループットに応じてRACクラスタを拡大/縮小し、メンテナンスのためにOracle RACノードを停止できます。
  • マルチ・データ・ソースの構成
    このトピックで説明するステップを実行して、マルチ・データ・ソースを作成および構成します。
  • マルチ・データ・ソース・フェイルオーバー機能の拡張
    マルチ・データ・ソースでのフェイルオーバー処理を改善する方法について学習します。
  • マルチ・データ・ソースでの計画データベース・メンテナンス
    マルチ・データ・ソースで使用されるデータベース・サーバーで、サービスの中断なしに計画されたメンテナンスを処理する方法を学習します。
  • データ・ソースの停止
    データ・ソースを停止する場合、まずデータ・ソースを中断してから、関連するリソース(接続など)を解放します。

親トピック: JDBCデータ・ソース・タイプ

マルチ・データ・ソースとは

マルチ・データ・ソースは、Oracle Real Application Clusters(Oracle RAC)など、可用性の高いデータベース・システムのノード間のフェイルオーバーまたはロード・バランシングに使用されます。MDSソースの汎用データ・ソース・メンバー・リストは、動的な更新をサポートしています。この機能により、Oracle RAC環境では、データベース・ノードおよび対応する汎用データ・ソースを再デプロイメントなしで追加および削除し、スループットに応じてRACクラスタを拡大/縮小し、メンテナンスのためにOracle RACノードを停止できます。

ノート:

マルチ・データ・ソースは、データベース同士を同期させるものではありません。データベースの同期は、データの整合性が保たれるよう、WebLogic Serverの外部で適切に処理されることが前提となっています。

データベース・ノードの追加および削除は、データベース管理者が手動で行う操作です。

  • データベース・ノードの追加
    データベース・ノードと対応する汎用データ・ソースを、再デプロイせずに追加できます。この機能によって、メンテナンス後にノードを起動したり、クラスタを拡張できます。
  • データベース・ノードの削除
    データベース・ノードと対応する汎用データ・ソースを、再デプロイせずに削除できます。この機能によって、メンテナンスのためにノードを停止したり、クラスタを縮小できます。

親トピック: JDBCマルチ・データ・ソースの使用

データベース・ノードの追加

データベース・ノードと対応する汎用データ・ソースを、再デプロイせずに追加できます。この機能によって、メンテナンス後にノードを起動したり、クラスタを拡張できます。

次のステップに従って、データベース・ノードを追加します。

  1. データベース・ノードを再起動します。
  2. 汎用データ・ソースを再起動します。Oracle WebLogic Server管理コンソール・オンライン・ヘルプのJDBCデータ・ソースの開始を参照してください。
  3. 汎用データ・ソースを再度マルチ・データ・ソースに追加します。Oracle WebLogic Server管理コンソール・オンライン・ヘルプのJDBCマルチ・データ・ソース内のデータ・ソースの追加または削除を参照してください。

親トピック: マルチ・データ・ソースとは

データベース・ノードの削除

データベース・ノードと対応する汎用データ・ソースを、再デプロイせずに削除できます。この機能によって、メンテナンスのためにノードを停止したり、クラスタを縮小できます。

次のステップに従って、データベース・ノードを停止します。

ノート:

これらのステップに失敗した場合、トランザクションがロールバックされる場合があります。

  1. 汎用データ・ソースをマルチ・データ・ソースから削除します。『Oracle WebLogic Server Administration Consoleオンライン・ヘルプ』のJDBCマルチ・データ・ソース内のデータ・ソースの追加または削除に関する項を参照してください。
  2. すべてのトランザクションの終了後に、汎用データ・ソースを中断します。Oracle WebLogic Server管理コンソール・オンライン・ヘルプのJDBCデータ・ソースの中断を参照してください。
  3. すべてのトランザクションの終了後に、汎用データ・ソースを停止します。Oracle WebLogic Server管理コンソール・オンライン・ヘルプのJDBCデータ・ソースの停止を参照してください。
  4. データベース・ノードを停止します。

親トピック: マルチ・データ・ソースとは

マルチ・データ・ソースの構成

このトピックで説明するステップを実行して、マルチ・データ・ソースを作成および構成します。

  1. 汎用データ・ソースを作成します。汎用データ・ソースの使用を参照してください。

  2. WebLogic Server管理コンソールまたはWebLogicスクリプト・ツールを使用して、マルチ・データ・ソースを作成します。Oracle WebLogic Server管理コンソール・オンライン・ヘルプのJDBCマルチ・データ・ソースの構成を参照してください。

  3. 汎用データ・ソースをマルチ・データ・ソースに割り当てます。

    マルチ・データ・ソースの構成時に作成される構成ファイルについては、WebLogic ServerにおけるJDBCリソースの理解およびマルチ・データ・ソース・モジュールの作成を参照してください。

ノート:

一般に、WebLogic Serverデータ・ソースの初期容量の設定がゼロに設定されている場合、WebLogic Serverは起動時にDBMS接続を作成しません。しかし、LLRデータ・ソースのマルチ・データ・ソースを起動するために、WebLogic Serverは起動時に接続を作成してDBMSがRACかどうかを確認します。汎用のLLRマルチ・データ・ソースの場合、すべてのデータ・ソースが使用可能である必要がありますが、RACを使用している場合は1つのノードのみがLLR処理用にアクセス可能である必要があります。

  • マルチ・データ・ソース・アルゴリズムの選択
    マルチ・データ・ソースを設定する前に、マルチ・データ・ソースの主要な目的(フェイルオーバーまたはロード・バランシング)を決める必要があります。アルゴリズムは、必要に応じて選択できます。
  • マルチ・データ・ソースのフェイルオーバーの制限と要件
    WebLogic Serverはマルチ・データ・ソース用のフェイルオーバー・アルゴリズムを備えており、汎用データ・ソースで障害(たとえば、データベース管理システムのクラッシュ)が発生しても、システムをそのまま稼働できます。ただし、マルチ・データ・ソースの構成時に考慮する必要がある特定の制限と要件があります。
  • コールバックによるマルチ・データ・ソース・フェイルオーバーの制御
    コールバック・ハンドラをWebLogic Serverに登録できます。これにより、フェイルオーバー・アルゴリズムが設定されたMDSが、接続リクエストをMDS内の1つのJDBC汎用データ・ソースからリスト内の次の汎用データ・ソースにフェイルオーバーするタイミングが制御されます。
  • サーバーおよびクラスタへのJDBCマルチ・データ・ソースのデプロイ
    接続リクエストに応じるために、マルチ・データ・ソースで使用されている汎用データ・ソースはすべて、マルチ・データ・ソースと同じサーバーおよびクラスタにデプロイされている必要があります。マルチ・データ・ソースは、常に同じサーバーにデプロイされている汎用データ・ソースを使用して、接続リストに応じます。マルチ・データ・ソースは、クラスタまたはドメイン内の他のサーバーへの接続リクエストのルーティングは行いません。

親トピック: JDBCマルチ・データ・ソースの使用

マルチ・データ・ソース・アルゴリズムの選択

マルチ・データ・ソースを設定する前に、マルチ・データ・ソースの主要な目的(フェイルオーバーまたはロード・バランシング)を決める必要があります。アルゴリズムは、必要に応じて選択できます。

親トピック: マルチ・データ・ソースの構成

フェイルオーバー

フェイルオーバー・アルゴリズムでは、接続リクエストに応じるために使用する汎用データ・ソースの順序付けされたリストを指定します。通常、この種類のマルチ・データ・ソースに対する接続リクエストはすべて、リストの先頭にある汎用データ・ソースによって処理されます。データベース接続テストが失敗して接続を置換できなかったり、汎用データ・ソースが中断した場合には、リスト上の次の汎用データ・ソースから順次、接続が検索されます。

ノート:

このアルゴリズムでは、汎用データ・ソースの「予約時に接続をテスト」(TestConnectionsOnReserve)を有効化する必要があります。有効になっている場合は、最初の汎用データ・ソースの接続をテストして、汎用データ・ソースが正常かどうかを確認します。接続のテストが失敗した場合は、マルチ・データ・ソースにリストされている次の汎用データ・ソースの接続が使用されます。TestConnectionsOnReserveの構成については、「データ・ソースの接続テスト・オプション」を参照してください。

JDBCは、きわめてステートフルなクライアントとDBMS間のプロトコルです。JDBCでは、DBMS接続とトランザクション状態が、DBMSプロセスとクライアント(ドライバ)間のソケットに直接関連付けられます。このため、使用中の接続のフェイルオーバーはサポートされません。

ロード・バランシング

ロード・バランシング・マルチ・データ・ソースへの接続リクエストは、リスト内の任意の汎用データ・ソースで処理されます。MDSは、接続リクエストに応じるための汎用データ・ソースをラウンドロビン方式で選択します。MDSは接続を提供する際に、最後に使用された汎用データ・ソースの直後にリストされている汎用データ・ソースの接続を選択します。データベース接続テストが失敗して接続を置き換えられない場合や汎用データ・ソースが中断されている場合も、ロード・バランシング・アルゴリズムを使用するマルチ・データ・ソースは、リスト内の次の汎用データ・ソースにフェイルオーバーします。

マルチ・データ・ソースのフェイルオーバーの制限と要件

WebLogic Serverはマルチ・データ・ソース用のフェイルオーバー・アルゴリズムを備えており、汎用データ・ソースで障害(たとえば、データベース管理システムのクラッシュ)が発生しても、システムをそのまま稼働できます。ただし、マルチ・データ・ソースの構成時に考慮する必要がある特定の制限と要件があります。

親トピック: マルチ・データ・ソースの構成

予約時の接続テストによるフェイルオーバーの有効化

汎用データ・ソースは、データベース接続が失われたときに把握できるように、汎用データ・ソースの「予約時に接続をテスト」(TestConnectionsOnReserve)機能を利用します。マルチ・データ・ソース内の汎用データ・ソースの「予約時に接続をテスト」機能を有効化する必要があります。各接続をアプリケーションに渡す前に、それらの接続をWebLogic Serverでテストします。このフェイルオーバー・アルゴリズムの場合、マルチ・データ・ソースは接続テストの結果を使用して、マルチ・データ・ソース内の次の汎用データ・ソースにフェイルオーバーする時期を決定します。テストに失敗した場合、汎用データ・ソースは接続を再試行します。再試行も失敗した場合、マルチ・データ・ソースは次の汎用データ・ソースにフェイルオーバーします。

使用中の接続に対するフェイルオーバーの実施不可能

予約後に接続が失敗する可能性もありますが、これについてはアプリケーションで処理する必要があります。WebLogic Serverでは、アプリケーションで使用中に失敗した接続をフェイルオーバーさせることはできません。接続の使用中に障害が発生した場合、アプリケーション・コードでは、障害が発生した接続を閉じて、新しい接続でトランザクションを最初から再起動する必要があります。

コールバックによるマルチ・データ・ソース・フェイルオーバーの制御

コールバック・ハンドラをWebLogic Serverに登録できます。これにより、フェイルオーバー・アルゴリズムが設定されたMDSが、接続リクエストをMDS内の1つのJDBC汎用データ・ソースからリスト内の次の汎用データ・ソースにフェイルオーバーするタイミングが制御されます。

フェイルオーバーを行うかどうか、またはいつ行うかをコールバック・ハンドラで制御することによって、データベースの準備や高可用性フレームワークとの通信といったシステム準備タスクを、フェイルオーバーの前に実行できるようになります。

コールバック・ハンドラは、MDSの「フェイルオーバーのコールバック・ハンドラ」属性を介して、MDSごとに登録されます。コールバック・ハンドラを適用する各MDSに、コールバック・ハンドラを登録する必要があります。また、ドメイン内のMDSごとに、別々のコールバック・ハンドラを登録できます。

親トピック: マルチ・データ・ソースの構成

コールバック・ハンドラの要件

マルチ・データ・ソース内のフェイルオーバーおよびフェイルバックの制御に使用されるコールバック・ハンドラには、weblogic.jdbc.extensions.ConnectionPoolFailoverCallbackインタフェースの実装が含まれている必要があります。マルチ・データ・ソースでリスト内の次の汎用データ・ソースにフェイルオーバーする必要がある場合や、以前に無効化された汎用データ・ソースが利用可能になった場合、WebLogic ServerではConnectionPoolFailoverCallbackインタフェースのallowPoolFailover()メソッドがコールされ、次に定義されている3つのパラメータ(currPool、nextPoolおよびopcode)の値が渡されます。WebLogic Serverはコールバック・ハンドラからの戻り値を待機し、その後タスクが完了されます。

アプリケーションは、次に定義されているOK、RETRY_CURRENTまたはDONOT_FAILOVERを戻す必要があります。アプリケーションはフェイルオーバーおよびフェイルバックの個々の状況を処理する必要があります。

「weblogic.jdbc.extensions.ConnectionPoolFailoverCallback」インタフェースを参照してください。

ノート:

「フェイルオーバーのコールバック・ハンドラ」はオプションです。マルチ・データ・ソースの構成にコールバック・ハンドラが指定されていなければ、WebLogic Serverは操作(フェイルオーバーまたは無効化された汎用データ・ソースの再有効化)を続行します。

コールバック・ハンドラの構成

フェイルオーバーおよびフェイルバック機能に関連付けられたマルチ・データ・ソース構成の属性は2つあります:

  • フェイルオーバーのコールバック・ハンドラ(ConnectionPoolFailoverCallbackHandler) - マルチ・データ・ソースのフェイルオーバーのコールバック・ハンドラを登録するには、マルチ・データ・ソースの構成にこの属性の値を追加します。値には、com.bea.samples.wls.jdbc.MultiDataSourceFailoverCallbackApplicationなどの絶対名を指定する必要があります。フェイルオーバーのコールバック・ハンドラを設定するには、WebLogic Server管理コンソールを使用ます(Oracle WebLogic Server管理コンソール・オンライン・ヘルプのフェイルオーバーのコールバック・ハンドラの登録を参照)。またはWLSTを使用してマルチ・データ・ソース用のJDBCDataSourceParamsBeanで設定できます。

  • テスト頻度(TestFrequencySeconds) - マルチ・データ・ソースによる、無効化された(レスポンスのない)汎用データ・ソースが利用可能になったかどうかのチェック頻度を制御します。詳細は、「マルチ・データ・ソース内の障害が発生した汎用データ・ソースがリカバリした場合の自動的な再有効化」を参照してください。

フェイルオーバーの仕組み

WebLogic Serverは、現在の汎用データ・ソースで接続テストが失敗した場合や、FailoverRequestIfBusyが有効化されているときに現在の汎用データ・ソース内のすべての接続が使用中の場合に、接続リクエストをリスト内の次の汎用データ・ソースにフェイルオーバーしようとします。

コールバック機能を有効化するには、マルチ・データ・ソースの構成で「フェイルオーバーのコールバック・ハンドラ」を使用して、コールバック・ハンドラをWebLogic Serverに登録します。

フェイルオーバー・アルゴリズムを使用する場合、接続リクエストはリスト内の最初の汎用データ・ソースで処理されます。汎用データ・ソースの接続が接続テストに失敗すると、WebLogic Serverはその汎用データ・ソースを「レスポンスなし」としてマーク付けし、無効にします。コールバック・ハンドラが登録されている場合、WebLogic Serverは次の情報を渡してコールバック・ハンドラを呼び出し、戻り値を待機します。

  • currPool - フェイルオーバーの場合、データベース接続の提供に現在使用されている汎用データ・ソースの名前です。これは、「フェイルオーバー元」の汎用データ・ソースです。

  • nextPool - マルチ・データ・ソースにリストされた次の利用可能な汎用データ・ソースの名前です。フェイルオーバーの場合、これは「フェイルオーバー先」の汎用データ・ソースです。

  • opcode - 呼出しの理由を示すコードです。

フェイルオーバーは接続リクエストと同期します。フェイルオーバーは、WebLogic Serverが接続リクエストに応じようとする場合にのみ発生します。

コールバック・ハンドラからの戻り値は、次の3種類のオプションのいずれかを示します。

  • OK - 処理を続行します。この場合、リスト内の次の汎用データ・ソースにフェイルオーバーすることを意味します。

  • RETRY_CURRENT - 接続リクエストを現在の汎用データ・ソースで再試行します。

  • DONOT_FAILOVER - 現在の接続リクエストの再試行も、フェイルオーバーも行いません。WebLogic Serverによってweblogic.jdbc.extensions.PoolUnavailableSQLExceptionがスローされます。

WebLogic Serverはコールバック・ハンドラによって返された値に従って処理を行います。

2番目の汎用データ・ソースで障害が発生すると、先のフェイルオーバーと同様に、マルチ・データ・ソース内の次に利用可能な汎用データ・ソースにフェイルオーバーを試行するために、WebLogic Serverではコールバック・ハンドラが再度呼び出されます(データ・ソースが存在している場合)。

ノート:

汎用データ・ソースを手動で無効化した場合、WebLogic Serverはコールバック・ハンドラを呼び出しません。

ロード・バランシング・アルゴリズムを使用するマルチ・データ・ソースの場合、WebLogic Serverでは汎用データ・ソースが無効化されても、コールバック・ハンドラは呼び出されません。ただし、無効化された汎用データ・ソースを再有効化しようとする場合には、コールバック・ハンドラが呼び出されます。詳細は、次の項を参照してください。

サーバーおよびクラスタへのJDBCマルチ・データ・ソースのデプロイ

接続リクエストに応じるために、マルチ・データ・ソースで使用されている汎用データ・ソースはすべて、マルチ・データ・ソースと同じサーバーおよびクラスタにデプロイされている必要があります。マルチ・データ・ソースは、常に同じサーバーにデプロイされている汎用データ・ソースを使用して、接続リストに応じます。マルチ・データ・ソースは、クラスタまたはドメイン内の他のサーバーへの接続リクエストのルーティングは行いません。

マルチ・データ・ソースをクラスタまたはサーバーにデプロイするには、サーバーまたはクラスタをデプロイ・ターゲットとして選択します。マルチ・データ・ソースをサーバーにデプロイすると、そのサーバーに、WebLogic Serverによってマルチ・データ・ソースのインスタンスが作成されます。マルチ・データ・ソースをクラスタにデプロイすると、クラスタ内の各サーバーに、WebLogic Serverによってマルチ・データ・ソースのインスタンスが作成されます。

手順については、Oracle WebLogic Server管理コンソール・オンライン・ヘルプのJDBCデータ・ソースのターゲット指定とデプロイを参照してください。

親トピック: マルチ・データ・ソースの構成

マルチ・データ・ソース・フェイルオーバー機能の拡張

マルチ・データ・ソースでのフェイルオーバー処理を改善する方法について学習します。

親トピック: JDBCマルチ・データ・ソースの使用

汎用データ・ソースの障害発生時における接続リクエストのルーティング機能の拡張

マルチ・データ・ソース内の汎用データ・ソースで障害が発生したときのパフォーマンスを向上させるため、WebLogic Serverはプールされた接続が接続テストで失敗すると、汎用データ・ソースを自動的に無効化します。汎用データ・ソースが無効化されると、WebLogic Serverでは、アプリケーションからその汎用データ・ソースに接続リクエストがルーティングされなくなります。そのかわりに、マルチ・データ・ソース内にリストされた、次に利用可能な汎用データ・ソースに接続リクエストがルーティングされます。

この機能を使用するには、汎用データ・ソース・テスト・オプション(特に「表名のテスト」および「予約時に接続をテスト」)がマルチ・データ・ソース内のすべての汎用データ・ソースに対して構成されていることが必要です。「データ・ソースの接続テスト・オプション」を参照してください

マルチ・データ・ソースに対してコールバック・ハンドラが登録されている場合、WebLogic Serverでは、コールバック・ハンドラが呼び出されてから、リスト内の次の汎用データ・ソースにフェイルオーバーされます。詳細は、「コールバックによるマルチ・データ・ソース・フェイルオーバーの制御」を参照してください。

親トピック: マルチ・データ・ソース・フェイルオーバー機能の拡張

マルチ・データ・ソース内の障害が発生した汎用データ・ソースがリカバリした場合の自動的な再有効化

接続に失敗して汎用データ・ソースが自動的に無効になった場合、マルチ・データ・ソースは、無効になった汎用データ・ソースからの接続を定期的にテストし、汎用データ・ソース(または基礎となるデータベース)が再び使用可能になったときに判別します。汎用データ・ソースが使用可能になると、マルチ・データ・ソースが汎用データ・ソースを自動的に再有効化し、その汎用データ・ソースへの接続リクエストのルーティングを再開します。これは、マルチ・データ・ソース・アルゴリズムと、含まれる汎用データ・ソース・リスト内の汎用データ・ソースの位置によって異なります。これらのテストの頻度は、マルチ・データ・ソースのテスト間隔属性によって制御されます。テスト頻度のデフォルト値は120秒です。そのため、特にこのオプションの値を設定しない場合は、マルチ・データ・ソースは無効化された汎用データ・ソースを120秒おきにテストします。Oracle WebLogic Server管理コンソール・オンライン・ヘルプのJDBCマルチ・データ・ソース: 構成: 全般を参照してください。

WebLogic Serverは、手動で無効化した汎用データ・ソースに対して、テストも自動的な再有効化も行いません。テストは自動的に無効化された汎用データ・ソースに対してのみ行われます。

マルチ・データ・ソースに対してコールバック・ハンドラが登録されている場合、WebLogic Serverがコールバック・ハンドラをコールしてから、汎用データ・ソースを再有効化します。詳細は、「コールバックによるマルチ・データ・ソース・フェイルバックの制御」を参照してください。

親トピック: マルチ・データ・ソース・フェイルオーバー機能の拡張

マルチ・データ・ソース内のビジー状態の汎用データ・ソースのフェイルオーバーの有効化

デフォルトでは、フェイルオーバー・アルゴリズムを使用するマルチ・データ・ソースの場合、データベース接続に対するリクエスト数が、マルチ・データ・ソース内の現在の汎用データ・ソースにある利用可能な接続数を超過すると、以降の接続リクエストが失敗します。

現在の汎用データ・ソースのすべての接続が使用されている場合にマルチ・データ・ソースがフェイルオーバーできるようにするには、WebLogic Server管理コンソールの「JDBCマルチ・データ・ソース: 構成: 一般」ページで「ビジー時はリクエストをフェイルオーバー」オプションを有効にします。(JDBCDataSourceParamsBeanのFailoverRequestIfBusy属性でも設定できます)。有効(trueに設定)の場合、現在の汎用データ・ソース内のすべての接続が使用中のとき、アプリケーションの接続リクエストはマルチ・データ・ソース内の次に使用可能な汎用データ・ソースにルーティングされます。無効(デフォルトのfalseに設定)の場合、接続リクエストのフェイルオーバーは行われません。

マルチ・データ・ソースの構成にConnectionPoolFailoverCallbackHandlerが含まれている場合は、WebLogic Serverでは、コールバック・ハンドラがコールされてから、フェイルオーバーが行われます。詳細は、「コールバックによるマルチ・データ・ソース・フェイルオーバーの制御」を参照してください。

親トピック: マルチ・データ・ソース・フェイルオーバー機能の拡張

コールバックによるマルチ・データ・ソース・フェイルバックの制御

マルチ・データ・ソースに対してフェイルオーバーのコールバック・ハンドラが登録されている場合、WebLogic Serverは、自動的に無効化された汎用データ・ソースを再有効化するときに、同じコールバック・ハンドラをコールします。無効化された汎用データ・ソースの再有効化を行うかどうか、またはいつ行うかをコールバックで制御することによって、データベースの準備や高可用性フレームワークとの通信といったシステム準備タスクを、汎用データ・ソースの再有効化の前に実行できるようになります。

コールバック・ハンドラの詳細は、次の項を参照してください。

親トピック: マルチ・データ・ソース・フェイルオーバー機能の拡張

フェイルバックの仕組み

WebLogic Serverでは、マルチ・データ・ソース内の自動的に無効化された汎用データ・ソースのステータスが定期的にチェックされます。(「マルチ・データ・ソース内の障害が発生した汎用データ・ソースがリカバリした場合の自動的な再有効化」を参照してください)無効化された汎用データ・ソースが使用可能になり、コールバック・ハンドラが登録されている場合、WebLogic Serverは次の情報をとともにコールバック・ハンドラをコールし、戻り値を待機します。

  • currPool - フェイルバックの場合、以前に無効化されて現在は再有効化が可能になっている汎用データ・ソースの名前です。

  • nextPool - フェイルバックの場合、これはNULLです。

  • opcode - 呼出しの理由を示すコードです。フェイルバックの場合、コードは常にOPCODE_REENABLE_CURR_POOLです。これは、currPoolに名前のある汎用データ・ソースが現在使用できることを示します。

フェイルバック(つまり、無効化された汎用データ・ソースを自動的に再有効化すること)は、フェイルオーバーが接続リクエストと同期しているものの、フェイルバックは接続リクエストと非同期であるという点で、フェイルオーバーとは異なります。

コールバック・ハンドラは、次の値のいずれかを戻す可能性があります。

  • OK - 処理を続行します。この場合、示された汎用データ・ソースを再有効化することを意味します。WebLogic Serverが、その汎用データ・ソースへの接続リクエストのルーティングを再開します。これは、マルチ・データ・ソース・アルゴリズムと、含まれる汎用データ・ソース・リスト内の汎用データ・ソースの位置によって異なります。

  • DONOT_FAILOVER - currPool汎用データ・ソースを再有効化しません。使用中の汎用データ・ソースで接続リクエストの処理を続行します。

WebLogic Serverはコールバック・ハンドラによって返された値に従って処理を行います。

コールバック・ハンドラがDONOT_FAILOVERを返した場合、WebLogic Serverはマルチ・データ・ソースの構成のTestFrequencySeconds属性で決められている設定に従って、次のテスト・サイクル中に汎用データ・ソースの再有効化を試行し、そのプロセスの一部としてコールバック・ハンドラをコールします。

マルチ・データ・ソース内での汎用データ・ソースのリスト順は、非常に重要です。フェイルオーバー・アルゴリズムを使用するマルチ・データ・ソースは、常にマルチ・データ・ソース内の汎用データ・ソース・リストで最初に利用可能な汎用データ・ソースで接続リクエストを処理しようとします。次のようなシナリオを想定してください。

  1. フェイルオーバー・アルゴリズムを使用するMultiDataSource_1には、登録されたConnectionPoolFailoverCallbackHandlerがあり、DS1、DS2およびDS3という順序でリストされている、3つの汎用データ・ソースが含まれています。

  2. DS1が無効化されると、MultiDataSource_1では接続リクエストがDS2にフェイルオーバーされます。

  3. DS2が無効化されると、MultiDataSource_1では接続リクエストがDS3にフェイルオーバーされます。

  4. しばらくすると、DS1が再び使用可能になり、コールバック・ハンドラによってWebLogic Serverによる汎用データ・ソースの再有効化が許可されます。以降の接続リクエストはDS1によって処理されます。これはDS1がマルチ・データ・ソース内にリストされた最初の汎用データ・ソースだからです。

  5. 続いてDS2が利用可能になり、コールバック・ハンドラによってWebLogic Serverによる汎用データ・ソースの再有効化が許可されても、汎用データ・ソースのリストでDS1はDS2の前にリストされているため、接続リクエストは引き続きDS1によって処理されます。

マルチ・データ・ソースでの計画データベース・メンテナンス

マルチ・データ・ソースで使用されるデータベース・サーバーで、サービスの中断なしに計画されたメンテナンスを処理する方法を学習します。

サービスの中断を回避するには、ローリング方式でデータベースを更新できるように、複数のデータベース・インスタンスが使用できる必要があります。Oracle RACクラスタおよびOracle GoldenGate (またはそれらの製品の組合せ)を使用すると、この目的を達成できます。(Oracle DataGuardは、サービスを中断しない計画メンテナンスに使用することはできません。)各データベース・インスタンスは、マルチ・データ・ソースの汎用データ・ソース・メンバーとして構成されます。このアプローチでは、アプリケーションが定期的にプールに接続を返すことが前提です。

プロセスの概要

次のステップでは、計画メンテナンス・プロセスの概要を示します。

  1. 中間層システムで、メンテナンスで停止されるOracle RACインスタンスに関連付けられたすべてのメンバー・データ・ソースを停止します。他のメンバーのために接続を予約できるように、各マルチ・データ・ソース・リストのデータ・ソースをすべて停止しないことが重要です。データ・ソースの停止が完了するのを待機します。参照:
  2. 必要に応じて、WebLogicデータ・ソースに関連付けられていない、データベース側の残りの接続を削減できます。この場合、Oracle Databaseサーバーでは、メンテナンスで停止されるインスタンスのアプリケーション・サービスの停止(または再配置)、リスナーの停止、データベース・インスタンスのサービスに対するトランザクション切断の発行などを行います。
  3. 適切なツールを使用してデータベース・インスタンスを停止します。
  4. 計画メンテナンスを実行します
  5. 適切なツールを使用してデータベース・インスタンスを再起動します。
  6. データベース・インスタンスでアプリケーションを使用する準備ができたら、サービスを起動します。
  7. 中間層システムで、メンバー・データ・ソースを起動します。Oracle WebLogic Server MBeanリファレンスのJDBCDataSourceRuntimeMBeanの起動操作に関する項を参照してください。

親トピック: JDBCマルチ・データ・ソースの使用

データ・ソースの停止

データ・ソースを停止する場合、まずデータ・ソースを中断してから、接続を含む関連リソースを解放します。

マルチ・データ・ソースのメンバー・データ・ソースが中断としてマークされると、マルチ・データ・ソースは、中断したプールから接続を取得しなくなります。かわりに、接続を予約するため、次のメンバー・データ・ソースに移動します。同時にマルチ・データ・ソース・リストのメンバー・データ・ソースをすべて停止しないことが重要です。すべてのメンバーが停止または失敗した場合、マルチ・データ・ソースへのアクセスは失敗し、アプリケーションは障害を認識します。

停止プロセスの最初のステップとしてデータ・ソースを正常に中断すると、次の処理が発生します。

  • データ・ソースは、操作の開始時に即座に中断としてマークされ、そのデータ・ソースでそれ以上接続は作成されなくなります。

  • アイドル(非予約)接続は閉じられたものとしてマークされます。

  • 中断操作のタイムアウト期間の経過後、プールに残っているすべての接続は中断としてマークされ、接続に対する任意の操作でデータ・ソースが中断していることを示す次の例外がスローされます。

    java.sql.SQLRecoverableException: Connection has been administratively disabled. Try later.

  • 残りのすべての接続は、その後閉じられます。それらが正常かどうかは、データ・ソースが再開されるまでわかりません。この場合、データベースが停止され、データ・ソースが再開された場合、プールの接続が正常ではないことがわかります。かわりに、無効な接続をすべて閉じるデータ・ソースの停止を実行します。

    停止操作は、同期的または非同期的に実行できます。非同期停止を実行する場合、デフォルトのタイムアウト期間は60秒です。このタイムアウト期間の値は、Inactive Connection Timeout Secondsを0 (ゼロ)以外の値に構成(または動的に設定)することで変更できます。非アクティブ・タイムアウト期間に上限はありません。ただし、実際の処理では、使用中(予約済)のリソースが10分の1秒ごとにチェックされるため、タイムアウト値が2時間に設定され、すべての予約済リソースが1秒後に解放されると、停止は1秒後に完了します。非同期操作を行う場合は、メソッドそのもにタイムアウト期間が指定されます。0に設定した場合、デフォルトが使用されます。デフォルトでは、Inactive Connection Timeout Seconds(設定されている場合)または60秒を使用します。タイムアウトを最小限にする場合は、値を1に設定します。タイムアウトを設定しない場合は、これを大きい値にします(非推奨)。

この停止操作は、同期的に実行されるため、使用できる非同期バージョンのMBean操作はありません。

これは、ロード・バランシングまたはフェイルオーバーによって構成されたマルチ・データ・ソースでも使用できます。

例4-1 WLSTの例

次のWLSTのスクリプト例は、中断タイムアウト期間を延長してから、ランタイムMBeanを使用してデータ・ソースを停止するように構成を編集する方法を示しています。このスクリプトは、すべてのWebLogic Serverサーバーおよびデータ・ソースの既存のフレームワークに統合する必要があります。

import sys, socket, os
hostname = 'hostname'
datasource='ds'
svr='myserver'
connect("weblogic","password","t3://"+hostname+":7001")
# Shutdown the data source serverRuntime()
serverRuntime()
cd('/JDBCServiceRuntime/' + svr + '/JDBCDataSourceRuntimeMBeans/' +datasource )
task = cmo.shutdown(10000)
while (task.isRunning ()): 
      print 'SHUTTING DOWN' 
      java.lang.Thread.sleep(2000) 
      print 'Datasource task is in status' + task.getStatus()
exit()
$ java weblogic.WLST myscript2.py
Intializing Weblogic Scripting Tool (WLST)...
Welcome to WebLogic Server Administration Scripting Shell
....
Location changed to serverRuntime tree.
This is a read-only tree with ServerRuntimeMBean as the root. For more help, use help('serverRuntime').
SHUTTING DOWN
Datasource task is in status
SUCCESS
Datasource task is in status
SUCCESS
Exiting WebLogic Scripting Tool.

重要な考慮事項

次のリストで、計画メンテナンスの実行時に考慮する必要のある問題について説明します。

  • マルチ・データ・ソースでデータベース・サービスを使用している場合、マルチ・データ・ソースを中断または停止する前にデータベース・サービスを停止または再配置することはできません。それを行うと、マルチ・データ・ソースは、現在存在しないサービスへの接続を作成する可能性があり、データベースが停止している場合と同様の応答をしてすべての接続を強制終了し、正常な停止が行われません。マルチ・データ・ソースを中断することで、関連するインスタンスで新しい接続が作成されないことが保証されるため、サービスを停止する必要はありません。(マルチ・データ・ソースは、このインスタンスでのみ接続を作成することに注意してください。再配置されても、別のインスタンスでは接続を作成しません。)また、マルチ・データ・ソースを中断することで、すべての接続に対する操作が停止されるため、マルチ・データ・ソース・プールに残っているどのセッションでも後続の処理は発生しません(トランザクションは完了しません)。

  • マルチ・データ・ソース・アルゴリズムによって強制適用されるXAアフィニティに関する問題が発生することがあります。Oracle RACインスタンスでXAブランチが作成されると、同じインスタンスですべての追加ブランチが作成されます。Oracle RACではインスタンス間のXAがサポートされますが、準備フェーズの前にアプリケーションが直面する重要な制限があり、マルチ・データ・ソースによって、すべての操作が同じインスタンス上で発生するように強制されます。正常な中断操作が開始すると同時に、メンバー・データ・ソースは中断としてマークされ、そこでそれ以上接続は割り当てられなくなります。グローバル・トランザクションを使用するアプリケーションが、中断しているデータ・ソースで別のブランチを開始しようとすると、接続を取得できずにトランザクションは失敗します。複数のWebLogic ServerにまたがるXAトランザクションの場合、中断は正常に行われません。この問題は、2フェーズ・コミットのエミュレートまたは1フェーズ・コミット(すべての作業に単一の接続を使用)およびロギング・ラスト・リソース(LLR)には適用されません。

  • なんらかの理由で、その時点ですべての接続が無効化されるデータ・ソースの中断とリソースの解放を分離する必要がある場合、中断の後にforceShutdownを実行できます。強制停止を使用して、2回目の待機期間を回避する必要があります。このプロセスの使用はお薦めできません。

  • データベースの停止時にデータ・ソースの正常な停止を行うには、データ・ソースを含める必要があります。データ・ソースを停止してからデータベースを停止するこのプロセスでは、中間層とデータベース・サーバー処理の間で調整が必要です。マルチ・データ・ソースのかわりにActive GridLinkを使用すると処理が簡略化されます。「Active GridLinkデータ・ソースの使用方法」を参照してください

  • Oracle Databaseを使用する場合、高可用性向けに構成できるように、データベースごとにアプリケーション・サービスを構成することをお薦めします。アプリケーション・サービスを使用することで、それを使用するためのデータ・ソースを起動せずに、単独でデータベースを起動できます。アプリケーション・サービスが明示的に起動されたら、管理者は、データ・ソースでデータベースを使用できるように設定できます。

親トピック: JDBCマルチ・データ・ソースの使用