RACデータベースへの接続

本ページではRAC環境でのデータベースへの接続方法や負荷分散、SCANの仕組み等を記載します。


接続設定例

以下はtnsnames.oraを使用した基本的な接続設定例です。
この設定はRACを構成する3ノードのいずれかにランダムで接続を試みて、 もし特定のノードがダウンしていたとしてもクライアントにエラーを返すことなくその他の2ノードに対して接続を試行します。 
RAC=
 (DESCRIPTION=
  (LOAD_BALANCE=ON)(FAILOVER=ON)
  (ADDRESS=(PROTOCOL=TCP)(HOST=vip_1)(PORT=port_number))
  (ADDRESS=(PROTOCOL=TCP)(HOST=vip_2)(PORT=port_number))
  (ADDRESS=(PROTOCOL=TCP)(HOST=vip_3)(PORT=port_number))
  (CONNECT_DATA=(SERVICE_NAME=service_name))
 )
実際の例は以下のようになります。 
RAC=
 (DESCRIPTION=
  (LOAD_BALANCE=ON)(FAILOVER=ON)
  (ADDRESS=(PROTOCOL=TCP)(HOST=vip_1)(PORT=1521))
  (ADDRESS=(PROTOCOL=TCP)(HOST=vip_2)(PORT=1521))
  (ADDRESS=(PROTOCOL=TCP)(HOST=vip_3)(PORT=1521))
  (CONNECT_DATA=(SERVICE_NAME=ORCL))
 )

パラメータ説明

LOAD_BALANCE
ONにすると複数接続先が記載されていた場合ランダムに接続先を選択するようになります。
OFFにした場合は上から順番に接続を試行します。

FAILOVER
ONにすると複数の接続先が記載されており接続試行先からエラーが返ってきた場合、エラーを表示が戻らずに次の接続先に自動的に接続を試行します。 OFFにすると接続試行先からエラーが返った段階でエラーが表示させ処理が終了します。

したがって、LOAD_BALANCE=ON、FAILOVER=ONの設定を組み合わせることによって以下の2つの機能が有効になります。

・負荷分散(クライアント側ロードバランス)
・接続のフェイルオーバ(特定の負荷分散先がダウンしてもエラーなく他のノードへ接続する)

リスナーロードバランスについて

上記設定でFAILOVER=OFFにした場合上から順番に接続をする、と記載しましたが上記設定でFAILOVER=OFFにしたとしても 設定によってはvip_1の起動ノード以外に接続される場合があります。これは リスナーロードバランス(サーバー側ロードバランス)が設定されているためです。

リスナーロードバランスはリスナがクライアントから接続要求を受け取った後にデータベースの負荷が低いノードへ接続要求を受け流す機能で、 クライアント側のロードバランスがランダムに接続先を振り分けるのに対し、リスナ側のロードバランスはCPU負荷を考慮して振り分けを行うという違いがあります。 リスナーロードバランスはデータベースパラメータのremote_listenerが設定すると有効になりますがdbcaでDBを作成した場合や、リスナーのポート番号がデフォルト(1521)の場合は自動で設定されます。

接続先ホストのIP指定について

上記例では「vip_1」のようにvipに対応するノード名を指定していますが、リスナーがLISTENINGしていれば実IPや実IPに名前解決されるホスト名を記載しても接続することは可能です。 ですが、接続先には実IPではなくvipを指定することをお勧めします。

実IPを指定した場合に問題となるのがノードの一部でOSダウンが発生した場合で、vipはノードがダウンしても生存ノードにフェイルオーバーするためvipはダウンしませんが、実IPの場合はOSがダウンすると消失することになります。 消失したIPに対して接続試行された場合tcp/ipレイヤのconnectシステムコールでエラーが戻るまでに3分を超える(正確には189秒)待機が発生する可能性があります。

この事象の対処としてはoracleレイヤでコネクションタイムアウト値を短く設定することや、OSのカーネルパラメータ(Linuxであればtcp_syn_retries)の設定変更等が有効です。

サービス名の指定について

「クライアント接続設定(1)」で記載したように特定のノード内でどのインスタンスに接続するかはSIDまたはサービス名で指定しますが、 RACを構成する全てのノードに接続したい場合は全てのインスタンスが共通で持つservice_names(デフォルトではdb_nameパラメータと同様の値)を指定します。

特定のノードに接続したい場合は各インスタンスに固有のサービス名を追加すれば可能です。なお、RAC環境ではservice_namesパラメータをクラスタウエアのリソースとしてデータベースから外だしした service リソース(srvctl add serviceコマンドにて追加します)でサービスが管理されているためデータベースのservice_namesパラメータを直接編集するのではなくサービスリソースを追加します。 また、リスナの設定を変更してSIDを静的登録する方法もあります。

SCAN(Single Client Access Name)について(11.2～)

バージョン11.2よりscanという仕組みが追加されています。scanを構成する仕組みは主に以下の3つです。

・scan名(DNSやGNSで複数のIPに解決されるクラスタ全体の名前)
・scan_vip(クラスタを構成するどこかのノードで起動するscan名に対応する複数の仮想IP
・scan_listener(それぞれのscan_vipをLITENするlistener)

クライアントがscan名に対して接続を試行するとdns等によりいずれかのscan_vipに変換されscan_listenerに接続要求が渡されます。 接続要求を受け取ったscan_listenerはリスナーロードバランスの仕組みによりクラスタを構成するいずれかのノードのlistenerに接続を受け渡すことで負荷分散する仕組みです。

11.1までの仕組みではノードを追加するとvipも増えるためにクライアント側の設定にも全て修正が必要でしたが、 11.2ではscan名を接続先に指定すれば以後ノードが増えてもクライアントの設定を修正することなク負荷分散できるメリットがあります。 ただし、DNSが単一障害点にならないようDNSの冗長化や、vip等の接続先の併用も考慮したほうがより安全だと思われます。

JAVAアプリケーションからのJDBC接続

「JDBCとは」のページでサンプルを記載をしています

マニュアル

Net Services 管理者ガイド10g リリース2（10.2）
Net Services リファレンス10g リリース2（10.2）
Oracle ClusterwareおよびOracle Real Application Clusters管理およびデプロイメント・ガイド10g リリース2（10.2）
Net Services管理者ガイド11g リリース1（11.1）
Net Servicesリファレンス11g リリース1（11.1）
Oracle Clusterware管理およびデプロイメント・ガイド11gリリース1（11.1）
Net Services管理者ガイド11gリリース2（11.2）
Net Servicesリファレンス11gリリース2（11.2）
Real Application Clusters管理およびデプロイメント・ガイド11g リリース2（11.2）
Clusterware管理およびデプロイメント・ガイド11g リリース2（11.2）
　
★ORACLE案件承ります