レベル1: 基本的なアプリケーション高可用性の構成

ステップ1: 高可用性データベース・サービスの構成

高可用性機能を使用するために、デフォルト以外のロールベースのデータベース・サービスを作成します。

データベース・サービスとは、ワークロードを管理するための論理的な抽象化であり、同様のSLAやワークロードのタイプ(OLTPとバッチなど)を共有するアプリケーションのグループです。データベース・サービスは、場所の透過性を提供し、基礎となるシステムの複雑な側面をクライアントから隠します。

高可用性機能を使用するために、アプリケーションはデフォルト以外のデータベース・サービスに接続する必要があります。デフォルトのデータベース・サービスまたはデフォルトのPDBサービス(データベースまたはPDBと同じ名前のサービス)を使用するかわりに、単一のサービス(または各種アプリケーション・ワークロードに応じて必要になる複数のサービス)を明示的に作成する必要があります。

Oracle Autonomous Databaseでは、推奨属性を使用することで適切なサービスが作成されます。

サービスのサーバー側構成について

こうしたサービスは、Oracle Clusterwareを通じてサービスを設定するためにデータベース管理者が構成します。

Oracle Data Guardとスタンバイ・データベースを使用する場合は、読取り/書込み操作に対してアプリケーションがプライマリ・データベースに接続するようにするためのプライマリ・ロールを使用するサービスと、読取り専用の操作と少数低頻度の書込みを必要に応じてスタンバイ・データベースにオフロードするためのスタンバイ・ロールを使用するサービスを作成します。

サービスは、ロールに基づいてData Guardのロール・トランジション(スイッチオーバーやフェイルオーバーなど)の後に自動的に起動および停止します。

次のいずれかのセクションのアーキテクチャに応じてサービスを構成します。

ノート:

サービスは、作成後に使用できるように起動する必要があります。次のようなコマンドを使用します。

$ srvctl start service -db mydb -service my_service

関連項目:

『Oracle Real Application Clusters管理およびデプロイメント・ガイド』のOracleサービスの使用

高可用性サービスの構成

高可用性機能を使用するために、デフォルト以外のロールベースのデータベース・サービスを作成します。

サービスは、単一の優先インスタンスに接続するように構成することも、優先インスタンスが停止している場合には使用可能なインスタンスに接続するように構成することもできます。単一のインスタンスでのみ使用可能なサービスは、シングルトン・サービスと呼ばれます。これにより、クラスタ内のインスタンス間でワークロードの分離が可能になります。

また、クラスタの複数のインスタンスに接続して、すべてのインスタンスに作業を分散するようにサービスを構成することもできます。さらに、1つのインスタンスが停止している場合には、正常に稼働しているインスタンスに接続できます。

それ以外にも、インスタンスのサブセットを「優先」として構成し、インスタンスの別のサブセットを「使用可能」として構成できる組合せもあります。こうしたサブセットを使用すると、一部のインスタンス間で負荷を分散しながら、別のインスタンスからは作業を分離できます(また、障害発生時に使用可能なインスタンスを確保できます)。

データベースがOracle Cloud上で実行されている場合は、「Oracle Cloud Database Serviceに関する考慮事項」を参照してください。

例1: シングルトン・サービス

この例では、プライマリ・ロール用にmy_serviceというシングルトン・サービスを作成します。これにより、接続がインスタンスinst1に対して確立されます(そのインスタンスを使用できない場合を除く)。そのインスタンスが使用不可の場合、接続はinst2に対して確立されます。また、セッションがドレインされるまで待つドレイン・タイムアウトのデフォルトを300秒に構成します。その時間の終了時点で、IMMEDIATEオプションにより、残りのセッションが終了します。

commit_outcomeとfailovertypeの設定により、透過的アプリケーション・コンティニュイティ(TAC)が有効になります(それを実装することに決めた場合)。「レベル3: 計画外および計画フェイルオーバーのアプリケーションからのマスクの構成」を参照

$ srvctl add service -db mydb -service my_service -pdb mypdb
 –preferred inst1 -available inst2 -notification TRUE -drain_timeout 300
 -stopoption IMMEDIATE -role PRIMARY

アプリケーションが別のOracle RACインスタンスにアプリケーションのブラックアウトなしで正常に切り替えられるようにするために、drain_timeoutの間隔は、アプリケーションがトランザクション間の接続をクローズして、正常に停止または別のインスタンスに移動できる十分なタイムアウトに設定します。drain_timeoutの間隔は、短いOLTPアプリケーションに対して最適です。大規模なバッチ操作の場合は、計画メンテナンス・ウィンドウの前に、そのような操作を遅延させるか一時停止することをお薦めします。

例2: 複数のインスタンスを持つサービス

この例では、前述のシングルトンと同様のサービスを作成しますが、このクラスタ内の複数のインスタンスに接続が分散されます。

$ srvctl add service -db mydb -service my_service -pdb mypdb
 –preferred inst1,inst2 -commit_outcome TRUE -failovertype AUTO  -notification TRUE
 -drain_timeout 300 -stopoption IMMEDIATE -clbgoal LONG -rlbgoal SERVICE_TIME
 -clbgoal LONG -rlbgoal SERVICE_TIME -role PRIMARY

Oracle Active Data Guardまたはスタンバイ・ロールの高可用性サービスの構成

スタンバイ・データベース(読取り専用フィジカル・スタンバイ)への接続に使用するサービスを作成します。

次の例に示すように、サービスを作成します。

$ srvctl add service -db mydb -service my_standby_service  -pdb mypdb
 –preferred inst1 -available inst2 -notification TRUE -drain_timeout 300
 -stopoption IMMEDIATE -clbgoal LONG -rlbgoal SERVICE_TIME -clbgoal LONG
 -rlbgoal SERVICE_TIME -role PHYSICAL_STANDBY

Oracle Cloud Database Serviceに関する考慮事項

デフォルト・サービスは、Oracle CloudでプロビジョニングされるすべてのPDBとともに作成されます。

ご使用のクラウド・サービスのタイプに応じて、次の考慮事項に注意してください。

Autonomous Database Serverless

Autonomous Database Serverlessの場合、データベース・サービスは、様々なパフォーマンス特性および同時実行性特性をサポートするように事前構成されています。DBMS_APP_CONT_ADMINパッケージを使用して、特定の可用性機能を有効にするようにそれらのサービスを変更できます。

具体的には、次のようにします:

ドレイン・タイムアウト属性を設定するには、DBMS_APP_CONT_ADMIN.SET_DRAININGを使用します。詳細は、DBMS_APP_CONT_ADMINを参照してください。
TAC属性やAC属性を設定するには、DBMS_APP_CONT_ADMIN.ENABLE_TACまたはDBMS_APP_CONT_ADMIN.ENABLE_ACを使用します

これにより、関連するサービス属性が、TACまたはACをサポートするための推奨値に設定されます
特定の属性を設定するには、DBMS_APP_CONT_ADMIN.MODIFY_SERVICEを使用します

DBMS_APP_CONT_ADMINパッケージでどの程度までそのサービスに対する変更がサポートされているかは、データベースのバージョンによって異なります。

Autonomous Database Serverlessでのサービスの可用性側面(優先インスタンスや使用可能インスタンスなど)は自動的に構成されます。詳細とその他のオプションについては、Autonomous Databaseのデータベース・サービス名を参照してください。

専用Exadataインフラストラクチャ上のAutonomous Database

専用Exadataインフラストラクチャ上のAutonomous Databaseの場合、データベース・サービスは、TAC、AC、および様々な並列度のサポートを含めて事前構成されています。アプリケーションのニーズを満たすサービス名を使用します。

Autonomous Databaseでのサービスの可用性側面(優先インスタンスや使用可能インスタンスなど)は自動的に構成されます。詳細とその他のオプションについては、「Autonomous Databaseの事前定義済データベース・サービス名」を参照してください。

Oracle Exadata Database Service on Dedicated InfrastructureとOracle Base Database

UIで提供される接続文字列内のサービスは、クライアント・アプリケーション接続用ではなく、管理用です。「高可用性サービスの構成」内の推奨事項に従って、アプリケーション用のデータベース・サービスを作成する必要があります。

ステップ2: 高可用性のための接続文字列の構成

データベース・スイッチオーバーや別のサイトへのフェイルオーバーなどの様々なシナリオで適切な接続ができるように、ここに示す接続文字列の構成を使用することをお薦めします。

例1: Oracle RACプライマリ・データベースとの接続文字列、スタンバイなし

Alias = (DESCRIPTION =
(CONNECT_TIMEOUT= 90)(RETRY_COUNT=20)(RETRY_DELAY=3)(TRANSPORT_CONNECT_TIMEOUT=1000ms)
    (ADDRESS_LIST =
        (LOAD_BALANCE=on)
        (ADDRESS = (PROTOCOL = TCP)(HOST=clu_site1-scan)(PORT=1521))) 
    (CONNECT_DATA=(SERVICE_NAME = my_service)))

例2: Oracle RACプライマリ・データベースおよびスタンバイ・データベースとの接続文字列

この例では、Oracle RACプライマリ・データベースまたはスタンバイ・データベースのどちらかの使用可能なデータベースに接続します。

Alias = (DESCRIPTION =
(CONNECT_TIMEOUT= 90)(RETRY_COUNT=100)(RETRY_DELAY=3)(TRANSPORT_CONNECT_TIMEOUT=1000ms)
    (ADDRESS_LIST =
        (LOAD_BALANCE=on)
        (ADDRESS = (PROTOCOL = TCP)(HOST=clu_site1-scan)(PORT=1521)))
    (ADDRESS_LIST =
        (LOAD_BALANCE=on)
        (ADDRESS = (PROTOCOL = TCP)(HOST=clu_site2-scan)(PORT=1521)))      
    (CONNECT_DATA=(SERVICE_NAME = my_service)))

ノート:

clu_site1-scanおよびclu_site2-scanは、それぞれsite1およびsite2のクラスタ内のSCANリスナーを表します。

最新ドライバの使用をお薦めしますが、前述の接続文字列の例はリリース12.2以降のすべてのOracleドライバに使用する必要があります。特定の値で調整できますが、この例では出発点として妥当な値を示しているため、ほとんどすべてのケースに使用できます。

接続文字列またはURLは、LDAPやtnsnames.oraなどの中央の場所に維持するようにしてください。接続文字列またはURLはプロパティ・ファイルやプライベートの場所に分散しないでください。そのようにすると、メンテナンスが非常に困難になります。集中管理された場所を使用すると、標準のフォーマット、チューニングおよびサービスの設定を維持できます。このためのOracleのソリューションは、Oracle Unified Directory製品とともにLDAPを使用することです。

JDBCの場合、前述の接続文字列は、これらの例で示すように実装されます。

例1.スタンバイなしのOracle RAC

jdbc:oracle:thin:@(DESCRIPTION =(CONNECT_TIMEOUT= 90)(RETRY_COUNT=20)(RETRY_DELAY=3)
(TRANSPORT_CONNECT_TIMEOUT=1000ms)(ADDRESS_LIST=(LOAD_BALANCE=on)(ADDRESS = (PROTOCOL = TCP)
(HOST=clu_site1-scan)(PORT=1521)))(CONNECT_DATA=(SERVICE_NAME = my_service)))

例2.スタンバイありのOracle RAC

jdbc:oracle:thin:@(DESCRIPTION =(CONNECT_TIMEOUT= 90)(RETRY_COUNT=100)(RETRY_DELAY=3)
(TRANSPORT_CONNECT_TIMEOUT=1000ms)(ADDRESS_LIST=(LOAD_BALANCE=on)(ADDRESS = (PROTOCOL = TCP)
(HOST=clu_site1-scan)(PORT=1521)))(ADDRESS_LIST=(LOAD_BALANCE=on)(ADDRESS = (PROTOCOL = TCP)
(HOST=clu_site2-scan)(PORT=1521)))(CONNECT_DATA=(SERVICE_NAME = my_service)))

他のクライアントについては、クライアントのドキュメントを参照してください。

関連項目:

Data Guardスイッチオーバーまたはフェイルオーバー時の接続時間の推定
Oracle Net TNS文字列パラメータ
『Oracle Unified Directoryの管理』のOracle Unified Directory
『Oracle Database Net Servicesリファレンス』のローカル・ネーミング・パラメータの概要

接続文字列に関するOracle Cloudの考慮事項

Oracle Cloudでは、プロビジョニングされるCDBとPDBについて接続文字列サンプルが提供されます。

クラウド・サービス(Exadata Database Services on Dedicated InfrastructureやOracle Base Database Serviceなど)の場合は、提供された接続文字列内のデフォルト・サービスではなく、ステップ1で追加した新しいサービスを含めるように、提供された接続文字列を変更する必要があります。

データベースにData Guardアソシエーションがある場合に、プライマリ・データベース障害の発生後に既存のアプリケーションを自動的にスタンバイにフェイルオーバーする必要があるときは、ステップ2で、プライマリ・エントリとスタンバイ・エントリを含む接続文字列形式を使用できます。

同じリージョン内のスタンバイの場合、通常は接続文字列にスタンバイを追加する必要がありますが、クロスリージョン・スタンバイの場合は、OCI Full Stack Disaster Recoveryサービスを評価して、アプリケーション、データベースおよびクライアントのフェイルオーバーを調整します。Oracle.comでのフル・スタック・ディザスタ・リカバリを参照してください。

ステップ3: FANが使用されていることとONSポート6200が開かれていることの確認

サービスで定期メンテナンスのためにドレインが必要な場合や計画外の障害(ノードやネットワークの停止など)が発生した場合、アプリケーションは、別のインスタンスやサイトに接続を迅速に移動できるよう、リアルタイムで通知される必要があります。これは、アプリケーションと接続プールに1つ以上のクラスタからイベント通知が届くようにすることができる、Oracleの高速アプリケーション通知(FAN)機能を使用して実現されます。

前述のステップ1と2で、推奨されるサービスと接続文字列を使用している場合、FANイベントを受信するための機能は、Oracle JDBCドライバ(最新バージョンをお薦めします。12.2より前ではありません)とともに自動的に有効になります。

ONSポート(デフォルトでは6200)は、すべてのデータベース・サーバー、ファイアウォールおよびOracle Active Data Guardノードでオープンしておく必要があります。

FANの使用は必須ではありませんが、多くのタイプの計画外停止シナリオを検出でき、アプリケーションでこれらのシナリオに適切に対応して高可用性を維持できるようになるためお薦めしています。

FANは、Oracle ClusterwareのOracle Notification Service (ONS)を使用して、クラスタからイベントを受信します。ONSでは、クライアントとサーバーの間でポートが使用可能になっている必要があり、場合によっては、これには、すべてのデータベース・サーバー、ファイアウォールおよびOracle Active Data Guardノードでファイアウォール・ポート(デフォルトでは6200)を開く必要があります。

FANを使用できない場合の代替手段: バンド内通知

ポート6200を開けないか使用できない場合は、Oracleの接続ドライバによって自動的に、それらのデータベース接続自体を使用した"バンド内"通知が有効になります。バンド内通知は、そのデータベースへの次のラウンドトリップで受信されます。

この通知では、単に、サービスがドレインされたことと、クライアントで接続をクローズする必要があることがドライバに伝えられるだけです。クライアントは、クライアントにすぐに切断するよう通知する、インスタンス障害やノード障害のイベントを受信するわけではありません。これは、このような障害によって接続が正常に終了せず、その接続がなくなることで、通知を表示する機能がなくなるためです。

バンド内通知は計画メンテナンス用であり、計画外停止には適用されません。

クライアントに対するONS/FANの有効化

FANを使用するためのアプリケーション・コードの変更は不要です。FANに必要なのは、Oracleドライバと、前述のステップ2で示した推奨されるデータベース接続文字列のみです。

デフォルトでは、19c以降のONSは、その推奨されるデータベース接続文字列(前述のステップ2内)を利用することで自動構成されます(クラスタのSCANリスナーを使用してクラスタに接続するためにこれらの文字列が使用される場合)。ONSによって、スタンバイ・クラスタ内のノードを含め(そのスタンバイ・クラスタがその接続文字列内にある場合)、どのノードに対して接続を確立する必要があるかが自動的に決定されます。

FANの自動構成には、ステップ2で示したTNS形式を使用することが重要です。別の書式構文を使用すると、FANが自動構成されるのを防ぐことができます。

推奨される接続URL/文字列(ステップ2内)を使用できない場合は、ONSのノードとポートのリストを設定することで、手動で、ONSをサブスクライブするようにクライアントを構成します。

たとえば、UCPでは、ONSエンドポイントを次の例のように構成できます(他のプールでは同様のものが使用されます。ご使用のプールのドキュメントを確認してください)。

pds.setONSConfiguration("nodes=racnode1:4200,racnode2:4200\nwalletfile=/oracle11/onswalletfile");

これは、ウォレット・ファイルを使用したONS構成を示しています。これは通常はOracle Cloudでは必要ですが、他の環境では使用しないでください。プロパティ・ファイルを作成し、ハードコーディングした値ではなくそのファイルを参照することをお薦めします(詳細は、「ONSのリモート構成」を参照)。

関連項目:

『Oracle Real Application Clusters管理およびデプロイメント・ガイド』のOracle統合クライアントおよびFANの概要

ステップ4: アプリケーションで再接続ロジックを実装するかどうかを開発者が決定

アプリケーションを、データベース・コール中に接続障害の例外とエラーを捕捉するように記述でき、それにより、続行が妥当な場合はそれらで新しい接続を取得し新しい作業を続行できるようにします。

アプリケーションの続行が妥当かどうかと接続を失った後にどのように進めるかを判断するために、多くの事柄を考慮する必要があります。「レベル3: 計画外および計画フェイルオーバーのアプリケーションからのマスクの構成」では、ACとTACを使用して透過的にアプリケーションから障害をマスクするための堅牢なソリューションが示されています。

JDBCベースのアプリケーションの場合は、SQLRecoverableExceptionを捕捉することで、接続エラーと通常のアプリケーション・エラーまたはSQLエラーとの区別ができます。接続エラーが捕捉された場合は、新しい接続を取得する必要があります。これは、SQLExceptionクラスの個別のOracleエラー(Oracle Databaseリリースによる調整が可能)を確認するよりも簡単で堅牢になります。

関連項目:

接続再試行ロジックの例