この記事では、高可用性とディザスター リカバリー (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
ターゲットがAzure SQL Database、Azure SQL Managed Instance、Microsoft FabricのSQL database、可用性グループリスナー、またはFailover Cluster Instanceの場合、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が真の場合、最初の接続試行は500ミリ秒のタイムアウト値を用います。 その他の接続試行はmultiSubnetFailover機能と同じロジックに従います。
注記
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 アドレスとの接続は試行されません。
注記
接続タイムアウト値を大きくし、接続再試行ロジックを実装することにより、アプリケーションが可用性グループに接続する確立が高まります。 また、可用性グループのフェールオーバーにより接続が失敗する可能性があるため、接続再試行ロジックを実装して、再接続されるまで、失敗した接続の再接続を試行する必要があります。
multiSubnetFailover を使った接続
ターゲットがAzure SQL Database、Azure SQL Managed Instance、Microsoft FabricのSQLデータベース、SQL Server 2012(11.x)の可用性グループリスナー、またはSQL Server 2012(11.x)のフェイルオーバークラスタインスタンスの場合、必ずmultiSubnetFailover=trueを指定します。
接続文字列内のサーバー名が複数の IP アドレスに解決される場合、multiSubnetFailover=true を指定すると、Microsoft JDBC Driver for SQL Server はそれらすべてのアドレスへの接続を同時に開き、最初に応答したアドレスを使用します。 これがなければ、ドライバーはデフォルトで有効になっている透過ネットワークIP解決(TNIR)にフォールバックします。 TNIRは500ミリ秒のタイムアウトで単一のアドレスを試み、次の試みでのみすべての解決済みアドレスへの接続を開きます。 もし transparentNetworkIPResolution=falseに設定すると、ドライバーは完全な loginTimeout で1つのアドレスを試し、他のアドレスは試さないため、別のアドレスで成功するはずの接続が失敗します。 フェイルオーバーでデータベースが異なるアドレスのレプリカに移動すると、 multiSubnetFailover=true は最初の試みで新しいアドレスに到達します。
multiSubnetFailover=true は、クライアントがデータベースにサービスを提供するレプリカを見つける速度を変えます。 サーバーのフェイルオーバーにかかる時間は変わりません。
multiSubnetFailover=true は単一IPターゲットでは安全です。 DNSが単一のアドレスに解決されると、ドライバーは1回の接続試行を行い、並列接続スレッドを開始しません。つまり、不要な場合は設定コストがかかりません。
SQL Server 用 Microsoft JDBC ドライバーの接続文字列キーワードの詳細については、「接続プロパティの設定」を参照してください。
セキュリティ マネージャーがインストールされていない場合、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 の詳細については、「 ネットワークプロパティ」を参照してください。
可用性グループまたはフェールオーバー クラスター インスタンス内のサーバーに接続する際には、次のガイドラインに従います。
multiSubnetFailover接続プロパティをtrueに設定してください。
可用性グループに接続するには、接続文字列でサーバーとして、可用性グループの可用性グループ リスナーを指定します。 たとえば、jdbc:sqlserver://VNN1 のように指定します。
instanceName接続プロパティとmultiSubnetFailoverを組み合わせて使うことができます。 ドライバーは各解決アドレスでSQL Browserをクエリし、インスタンスのポートを探します。 portNumberも指定していれば、ドライバはportNumberを使用し、SQL Browserを照会しません。
64以上のIPアドレスで設定されたSQL Serverインスタンスへの接続は失敗します。 ドライバーはそれをサポートされていない構成として扱い、接続の再試行をしません。
データベースミラーリングでは multiSubnetFailover は使えません。 ドライバーは、接続文字列がfailoverPartnerを指定する場合や、サーバーがフェイルオーバーパートナーを返す際にエラーを返します。 データベースミラーリングは、サポートされているすべてのSQL Serverバージョンで推奨されていません。 代わりに Always On 可用性グループ を使用してください
multiSubnetFailover 接続プロパティを使用するアプリケーションの動作は、認証の種類 (SQL Server 認証、Kerberos 認証、または Windows 認証) の影響を受けません。
フェイルオーバー時間に対応し、アプリケーション接続再試行を減らすために loginTimeout の値を上げます。 Azure SQL Databaseのサーバーレスで自動一時停止を有効にする場合、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。 データベースでは、対象の可用性グループ データベースのワークロードの読み取りを許可または禁止できます。 この選択は、
ALLOW_CONNECTIONSおよびPRIMARY_ROLETransact-SQL ステートメントのSECONDARY_ROLE句を使用して制御できます。
これらの特別なターゲットがいずれも使用できない場合は、通常のデータベースから読み取られます。
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 の詳細については、「暗号化のサポートについて」を参照してください。