レベル1: 基本的なアプリケーション高可用性の構成
アプリケーションがインスタンス、ノードまたはデータベースの障害に即座に対応して、障害が発生していないデータベース・インスタンスへの新しい接続を迅速に確立できる、高可用性のレベルを実装します。
アプリケーションHAレベル1では、計画外停止および計画停止の停止時間が最小限に抑えられます。こうしたメリットは、次の推奨事項がアプリケーション構成で確実に実装されるようにすることで得られます。設計時のコード変更は不要です。
レベル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つのインスタンスが停止している場合には、正常に稼働しているインスタンスに接続できます。
それ以外にも、インスタンスのサブセットを「優先」として構成し、インスタンスの別のサブセットを「使用可能」として構成できる組合せもあります。こうしたサブセットを使用すると、一部のインスタンス間で負荷を分散しながら、別のインスタンスからは作業を分離できます(また、障害発生時に使用可能なインスタンスを確保できます)。
例1: シングルトン・サービス
この例では、プライマリ・ロールにMyServiceというシングルトン・サービスを作成します。このサービスは、インスタンスinst1に接続します(そのインスタンスが使用できない場合を除きます)。インスタンスが使用できない場合は、inst2に接続します。また、セッションのドレインを待機するデフォルトの300秒のドレイン・タイムアウトも構成します。その時間の終了時点で、残りのセッションはIMMEDIATEオプションによってすべて終了します。
commit_outcomeとfailovertypeの設定により、今後、透過的アプリケーション・コンティニュイティ(TAC)の実装を決定した場合に、その機能を使用できるようにします(これは高度な機能です。詳細は、Oracle MAAのOracleアプリケーション・コンティニュイティを参照してください)。TACを有効にしても悪影響はありません。HAレベル3への移行を決定したときに、前提条件が満たされていれば自動的にメリットが得られます。
$ srvctl add service -db mydb -service my_service -pdb mypdb
–preferred inst1 -available inst2 -commit_outcome TRUE
-failovertype AUTO -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
-role PRIMARYOracle 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 -role PHYSICAL_STANDBYステップ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を使用することです。
関連項目:
-
『Oracle Unified Directoryの管理』のOracle Unified Directory
-
『Oracle Database Net Servicesリファレンス』のローカル・ネーミング・パラメータの概要
ステップ3: FANが使用されていることの確認
FANは、停止の発生時にインテリジェントで即時的な割込みを提供して、アプリケーションへの影響やブラウンアウトを大幅に縮小します。
サービスが定期的な保守や計画外の障害(ノードやネットワークの停止など)のためにドレインする必要がある場合、アプリケーションは別のインスタンスやサイトに接続を迅速に移動できるようにリアルタイムで通知されることが必要です。これは、Oracleの高速アプリケーション通知(FAN)機能を使用することで実現できます。FANを有効にすると、ノード、ネットワーク、サイトの障害などの物理的な障害が発生したときに、アプリケーションがハングしないようになります。
FANは、Oracle ClusterwareのOracle Notification Service (ONS)を使用して、クラスタからイベントを受信します。ONSにはクライアントとサーバーの間で使用可能なポートが必要になり、場合によってはファイアウォール・ポートのオープンが必要になります。
前述のステップ1および2で推奨されているサービスと接続文字列を使用していると、FANイベントを受信するための登録が自動的に有効になります。
ONSポート(デフォルトでは6200)は、すべてのデータベース・サーバー、ファイアウォールおよびOracle Active Data Guardノードでオープンしておく必要があります。例に示すように、Oracle Autonomous Database on Dedicated Exadata Infrastructure (ADB-D)、Exadata Database Service on Dedicated Infrastructure (ExaDB-D)、Oracle Exadata Database Service on Cloud@Customer (ExaDB-C@C)などのクラウド環境では、このステップは非常に重要です。
クライアントのFANの有効化
FANを使用するためのアプリケーション・コードの変更は不要です。FANに必要なものは、Oracleドライバおよび推奨のデータベース接続文字列のみです。
FANは自動構成され、設定なしで有効化されます。Oracleデータベースへの接続時に、データベースはURLまたはTNS接続文字列を使用してクライアントでFANを自動構成します。
FANの自動構成には、ステップ2に示したTNS形式を使用することが重要です。別の形式の構文を使用すると、FANが自動構成されないことがあります。FANを使用するには、データベース・サービス(ステップ1で構成したサービス)に接続して、Oracle Notification Service (ONS)からイベントを受信できるようにする必要があります。そのためには、前述したようにポートのオープンが必要になることがあります。
また、接続プールの設定(後述)を使用して、必要に応じて手動でFANを構成することもできます。
各種プール・タイプの構成要件については、次を参照してください。
JDBC FANの要件
UCPを使用するクライアント・ドライバの場合:
- ONSの自動構成には、推奨の接続URL/文字列(前述)を使用します。
- JDBC JARファイル
ojdbc8.jar(またはそれ以降)、ons.jarおよびsimplefan.jarをCLASSPATHに含めます(また、オプションのウォレットjar:osdt_cert.jar、osdt_core.jarおよびoraclepki.jarを必要に応じて加えます)。 - プールまたはドライバのプロパティを設定して、高速接続フェイルオーバーを有効にします(たとえば、UCPでは
setFastConnectionFailoverEnabled(true)を使用してPoolDataSourceに対して設定します)。 - 自動コミット接続プロパティを無効にします(たとえば、UCPでは、
setConnectionProperty(OracleConnection.CONNECTION_PROPERTY_AUTOCOMMIT, "false");を使用してPoolDataSourceに対して無効にします)。 - サード・パーティのJDBCプールの場合は、データ・ソースとしてユニバーサル接続プール(UCP)の使用をお薦めします。
- データベース・サーバーからのONS通信用のポート6200をオープンします(6200はデフォルト・ポートです。別のポートが選択されている可能性があります)。
推奨の接続URL/文字列を使用できない場合は、次の設定によってクライアントを手動で構成します。
oracle.ons.nodes=Node01:6200, Node02:6200, Node03:6200 手動で構成する場合は、追加の設定が必要になることがあります。たとえば、walletfileとwalletpasswordです。
UCP以外の接続プールにも同様の要件があります。
OCI FANの要件
-
Oracle Call Interface (OCI)クライアントの場合:
OCIクライアントは、FANをドライバ・レベルで埋め込むことで、プール・ソリューションに関係なくすべてのクライアントが使用できるようにします。
データベース・サービスには、属性"-notification TRUE"を設定しておく必要があります。
oraaccess.xmlを使用している場合は、eventsタグがTRUEであることを確認します。
<oraaccess> xmlns="http://xmlns.oracle.com/oci/oraaccess" xmlns:oci="http://xmlns.oracle.com/oci/oraaccess" schemaLocation="http://xmlns.oracle.com/oci/oraaccess http://xmlns.oracle.com/oci/oraaccess.xsd"> <default_parameters> <events>true</events> </default_parameters> </oraaccess>
-
ODP.Netクライアントの場合
接続文字列でHA eventsを指定します
"user id=oracle; password=oracle; data source=HA; pooling=true; HA events=true;"
関連項目:
『Oracle Real Application Clusters管理およびデプロイメント・ガイド』のOracle統合クライアントおよびFANの概要
ステップ4: アプリケーションへの再接続ロジックの実装の確認
アプリケーションは、データベース・コール中の接続障害の例外とエラーを捕捉するように記述して、新しい接続を取得して新しい作業を続行できるようにする必要があります。
JDBCベースのアプリケーションの場合は、SQLRecoverableExceptionを捕捉することで、接続エラーと通常のアプリケーション・エラーまたはSQLエラーの区別ができます。接続エラーが捕捉された場合は、新しい接続を取得する必要があります。これは、SQLExceptionクラスの個別のOracleエラー(Oracle Databaseリリースによる調整が可能)を確認するよりも簡単で堅牢になります。
関連項目: