高可用性、ディザスター リカバリーのための JDBC ドライバーのサポート
この記事では、高可用性とディザスター リカバリー (Always On 可用性グループ) に関する Microsoft JDBC Driver for SQL Server のサポートについて説明します。 Always On 可用性グループの詳細については、SQL Server 2012 (11.x) オンライン ブックを参照してください。
Version 4.0 以降の SQL Server 用 Microsoft JDBC ドライバー では、接続プロパティを使用して、(高可用性のディザスター リカバリー) 可用性グループ (AG) の可用性グループ リスナーを指定できます。 Microsoft JDBC Driver for SQL Server アプリケーションを Always On データベースに接続しているときにフェールオーバーが発生した場合、元の接続は切断され、アプリケーションではフェールオーバー後に処理を続行するために新しい接続を開く必要があります。 Microsoft SQL Server 用 JDBC Driver 4.0 では、次の接続プロパティが追加されました。
multiSubnetFailover
applicationIntent
可用性グループまたはフェールオーバー クラスター インスタンスの可用性グループ リスナーに接続する際には、multiSubnetFailover=true を指定してください。
注意
multiSubnetFailover は既定では false です。 applicationIntent を使用してアプリケーションのワークロードの種類を宣言します。 詳細については、以下のセクションを参照してください。
Microsoft JDBC Driver for SQL Server のバージョン 6.0 以降では、Always On 可用性グループまたは複数の IP アドレスが関連付けられているサーバーに透過的に接続するために、新しい接続プロパティ transparentNetworkIPResolution (TNIR) が追加されています。 transparentNetworkIPResolution が true の場合、ドライバーは、使用可能な最初の IP アドレスへの接続を試みます。 最初の試行が失敗した場合、ドライバーは、タイムアウトになるまですべての IP アドレスに並行して接続を試みます。いずれかの試行に成功すると、保留中の接続試行はすべて破棄されます。
注:
- transparentNetworkIPResolution は既定で true に設定されます。
- multiSubnetFailover が true の場合、transparentNetworkIPResolution は無視されます。
- データベース ミラーリングが使用されている場合、transparentNetworkIPResolution は無視されます。
- IP アドレスが 64 個を超える場合、transparentNetworkIPResolution は無視されます。
- transparentNetworkIPResolution が true の場合、最初の接続試行では、タイムアウト値として 500 ミリ秒が使用されます。 残りの接続試行は、multiSubnetFailover 機能と同じロジックに従います。
Note
Microsoft JDBC Driver for SQL Server の 4.2 (以前) を使用しており、multiSubnetFailover が false の場合、SQL Server 用 Microsoft JDBC ドライバー は、最初の IP アドレスへの接続を試みます。 SQL Server 用 Microsoft JDBC ドライバー が 1 つ目の IP アドレスとの間に接続を確立できない場合、接続は失敗します。 SQL Server 用 Microsoft JDBC ドライバー では、サーバーに関連付けられているその他の IP アドレスとの接続は試行されません。
Note
接続タイムアウト値を大きくし、接続再試行ロジックを実装することにより、アプリケーションが可用性グループに接続する確立が高まります。 また、可用性グループのフェールオーバーにより接続が失敗する可能性があるため、接続再試行ロジックを実装して、再接続されるまで、失敗した接続の再接続を試行する必要があります。
multiSubnetFailover を使用した接続
SQL Server 2012 (11.x) 可用性グループまたは SQL Server 2012 (11.x) フェールオーバー クラスター インスタンスの可用性グループ リスナーに接続する際には、必ず multiSubnetFailover=true を指定してください。 multiSubnetFailover を使用することで、SQL Server 2012 (11.x) のすべての可用性グループおよびフェールオーバー クラスター インスタンスに対して高速フェールオーバーが有効化され、単一サブネットおよびマルチサブネットの Always On トポロジにおけるフェールオーバー時間が大幅に短縮されます。 マルチサブネット フェールオーバーの際には、クライアントは複数の接続を並列で試行します。 サブネット フェールオーバー中、SQL Server 用 Microsoft JDBC ドライバー では TCP 接続が積極的に再試行されます。
multiSubnetFailover 接続プロパティを指定すると、アプリケーションが可用性グループまたはフェールオーバー クラスター インスタンスに配置され、SQL Server 用 Microsoft JDBC ドライバー ではすべての IP アドレスに対して接続を試行することで、プライマリ SQL Server インスタンス上のデータベースに接続が試行されます。 接続に対して MultiSubnetFailover=true を指定した場合、オペレーティング システムの既定の TCP 再送信間隔より短い間隔で、クライアントにより TCP 接続が再試行されます。 この動作により、Always On 可用性グループまたは Always On フェールオーバー クラスター インスタンスのフェールオーバー後、再接続されるまでの時間を短縮することができます。これは、単一サブネットとマルチサブネット両方の可用性グループ インスタンスおよびフェールオーバー クラスター インスタンスに適用できます。
SQL Server 用 Microsoft JDBC ドライバーの接続文字列キーワードの詳細については、「接続プロパティの設定」を参照してください。
可用性グループ リスナーまたはフェールオーバー クラスター インスタンス以外に接続するときに multiSubnetFailover=true を指定すると、パフォーマンスが低下する可能性があるため、このような指定はサポートされていません。
セキュリティ マネージャーがインストールされていない場合、Java 仮想マシンにより仮想 IP アドレス (VIP) が期限付きでキャッシュされます。この期限は、既定で JDK 実装および Java プロパティ (networkaddress.cache.ttl および networkaddress.cache.negative.ttl) によって定義されます。 JDK セキュリティ マネージャーがインストールされている場合、Java 仮想マシンにより VIP がキャッシュされます。このキャッシュは、既定で更新されません。 Java 仮想マシン キャッシュの "有効期限" (networkaddress.cache.ttl) を 1 日に設定する必要があります。 既定値を 1 日 (またはその他の値) に変更しない場合、VIP が追加または更新されたときに Java 仮想マシン キャッシュから古い値が削除されません。 networkaddress.cache.ttl および networkaddress.cache.negative.ttl の詳細については、https://download.oracle.com/javase/6/docs/technotes/guides/net/properties.html を参照してください。
可用性グループまたはフェールオーバー クラスター インスタンス内のサーバーに接続する際には、次のガイドラインに従います。
multiSubnetFailover 接続プロパティと同じ接続文字列内で instanceName 接続プロパティを使用した場合、ドライバーはエラーを生成します。 このエラーは、SQL Browser が可用性グループ内で使用されていないという事実を反映しています。 ただし、portNumber 接続プロパティも指定した場合、ドライバーは、instanceName を無視して、portNumber を使用します。
単一サブネットまたはマルチサブネットに接続する場合に multiSubnetFailover 接続プロパティを使用すると、両方の場合のパフォーマンスを向上させることができます。
可用性グループに接続するには、接続文字列でサーバーとして、可用性グループの可用性グループ リスナーを指定します。 たとえば、jdbc:sqlserver://VNN1 のように指定します。
64 個を超える数の IP アドレスが構成された SQL Server インスタンスに接続すると、接続エラーが発生します。
multiSubnetFailover 接続プロパティを使用するアプリケーションの動作は、認証の種類 (SQL Server 認証、Kerberos 認証、または Windows 認証) の影響を受けません。
loginTimeout の値を増やすことで、フェールオーバー時間に対応し、アプリケーションの接続試行回数を減らすことができます。
読み取り専用のルーティングが無効である場合、次の状況では可用性グループのセカンダリ レプリカの場所には接続できません。
セカンダリ レプリカの場所が、接続を許可するように構成されていない。
アプリケーションに applicationIntent=ReadWrite (後述します) が使用されているが、セカンダリ レプリカの場所が読み取り専用アクセスとして構成されている。
プライマリ レプリカが読み取り専用ワークロードを拒否するように構成されているとき、接続文字列に ApplicationIntent=ReadOnly が含まれていると、接続は失敗します。
データベース ミラーリングからマルチサブネット クラスターの使用へのアップグレード
現在、データベース ミラーリングを使用している SQL Server 用 Microsoft JDBC ドライバー アプリケーションをマルチサブネットのシナリオにアップグレードする場合、failoverPartner 接続プロパティを削除して multiSubnetFailover に置き換え、それを true に設定し、接続文字列内のサーバー名を可用性グループ リスナーに置き換える必要があります。 接続文字列で failoverPartner および multiSubnetFailover=true が使用されている場合、ドライバーによってエラーが生成されます。 ただし、接続文字列に failoverPartner と multiSubnetFailover=false (または ApplicationIntent=ReadWrite) が使用されている場合、アプリケーションではデータベース ミラーリングが使用されます。
AG のプライマリ データベースでデータベース ミラーリングが使用されている場合、および可用性グループ リスナーではなく、プライマリ データベースに接続する接続文字列内で multiSubnetFailover=true が使用されている場合、ドライバーによってエラーが返されます。
アプリケーションの意図を指定する
接続文字列内にキーワード ApplicationIntent を指定できます。 割り当て可能な値は ReadWrite (既定値) または ReadOnly です。
ApplicationIntent=ReadOnly を設定すると、接続時にクライアントによって読み取りワークロードが要求されます。 サーバーでは、接続時と USE データベース ステートメントの実行時にこの意図が適用されます。
ApplicationIntent キーワードは、従来型の読み取り専用データベースに対しては動作しません。
ReadOnly のターゲット
接続で ReadOnly が選択された場合、その接続は、データベースに存在する可能性のある次の特別な構成のいずれかに割り当てられます。
Always On。 データベースでは、対象の可用性グループ データベースのワークロードの読み取りを許可または禁止できます。 この選択は、
PRIMARY_ROLEおよびSECONDARY_ROLETransact-SQL ステートメントのALLOW_CONNECTIONS句を使用して制御できます。
これらの特別なターゲットがいずれも使用できない場合は、通常のデータベースから読み取られます。
ApplicationIntent キーワードを使用すると、"読み取り専用ルーティング" が有効になります。
読み取り専用ルーティング
読み取り専用ルーティングは、データベースの読み取り専用レプリカの可用性を実現する機能です。 読み取り専用ルーティングを有効にするには、次のすべてを適用します。
Always On 可用性グループ リスナーに接続する必要があります。
ApplicationIntent接続文字列キーワードをReadOnlyに設定する必要があります。データベース管理者は、読み取り専用ルーティングを有効にするように可用性グループを構成する必要があります。
複数の接続でそれぞれに読み取り専用ルーティングが使用されている場合、すべてが同じ読み取り専用レプリカに接続されるとは限りません。 データベースの同期変更またはサーバーのルーティング構成の変更は、異なる読み取り専用のレプリカに対するクライアントの接続につながることがあります。
Server 接続文字列キーワードに可用性グループ リスナーを渡さ "ない" ことにより、すべての読み取り専用要求が同じ読み取り専用レプリカに接続されるようにすることができます。 代わりに、読み取り専用のインスタンスの名前を指定します。
読み取り専用ルーティングには、プライマリへの接続よりも時間がかかることがあります。 これは、読み取り専用ルーティングではまずプライマリに接続し、次に使用できる最善の読み取り可能なセカンダリを検索するためです。 このような複数のステップがあるため、login タイムアウトを少なくとも 30 秒に増やす必要があります。
接続のプール
Microsoft JDBC Driver for SQL Server を接続プール ライブラリと組み合わせて使用する場合は、次の点を考慮する必要があります。
- 読み取り専用ルーティングが構成されており、読み取り専用サーバーのプールに負荷を分散する場合は、新しい接続が対象サーバーに分散される機会の数が接続プールによって減少します。
- プール内の 1 つのサーバーで負荷が高くなることを回避するには、プール内の接続を均等に分散することを促すプール オプションを選択します。
- 接続プールが接続の有効期間で構成されていることを確認します。 読み取り専用の接続が確立されているときに読み取り専用レプリカを使用できない場合は、接続が最終的に閉じられ、再び使用可能になったときに読み取り専用レプリカに再確立されるように構成する必要があります。
multiSubnetFailover および applicationIntent をサポートする新しいメソッド
次のメソッドを使用すると、プログラムから multiSubnetFailover、applicationIntent、transparentNetworkIPResolution 接続文字列キーワードにアクセスできます。
SQLServerDataSource.setTransparentNetworkIPResolution
SQLServerDataSource.getTransparentNetworkIPResolution
getMultiSubnetFailover、setMultiSubnetFailover、getApplicationIntent、setApplicationIntent、getTransparentNetworkIPResolution、setTransparentNetworkIPResolution の各メソッドも SQLServerDataSource クラス、SQLServerConnectionPoolDataSource クラス、SQLServerXADataSource クラス に追加されます。
TLS/SSL 証明書の検証
可用性グループは、複数の物理サーバーで構成されます。 Microsoft SQL Server 用 JDBC Driver 4.0 で、TLS/SSL 証明書に対する Subject Alternate Name のサポートが追加されたため、複数のホストを同じ証明書に関連付けることができるようになりました。 TLS の詳細については、「暗号化のサポートについて」を参照してください。