高可用性とディザスター リカバリーのための SqlClient のサポート
この記事では、Always On 機能 (SQL Server 2012 以降での Always On 可用性グループ (AG) と Always On フェールオーバー クラスター インスタンス (FCI)) を使用した高可用性とディザスター リカバリーのための SqlClient のサポート (.NET Framework 4.5 で追加) について説明します。
接続プロパティで、可用性グループ リスナーまたは FCI の名前を指定できるようになりました。 フェールオーバーが発生したデータベースに SqlClient アプリケーションが接続される場合、元の接続が途切れるため、アプリケーションがフェールオーバーの後に処理を続行するには、新しい接続を開く必要があります。
AG または FCI に接続しておらず、ホスト名に複数の IP アドレスが関連付けられている場合、SqlClient は DNS エントリに関連付けられているすべての IP アドレスを順次繰り返し処理します。 DNS サーバーが最初に返した IP アドレスがネットワーク インターフェイス カード (NIC) にバインドされていない場合、この処理に時間がかかる可能性があります。 FCI または可用性グループのリスナーに接続している場合、SqlClient は、同時にすべての IP アドレスとの間で接続の確立を試行します。 接続試行が成功すると、ドライバーは保留状態の接続試行をすべて破棄します。
Note
接続タイムアウトの増加および接続の再試行ロジックの実装により、アプリケーションが可用性グループに接続する可能性は向上します。 また、接続がフェールオーバーによって失敗する可能性があるので、接続の再試行ロジックの実装は、失敗した接続が再接続するまで試行されるようにする必要があります。
次の接続プロパティが、.NET Framework 4.5 の SqlClient に追加されました。
ApplicationIntentMultiSubnetFailover
プログラムによって、これらの接続文字列キーワードを次のとおりに変更できます。
Note
.NET Framework バージョン 4.6.1 以降では、MultiSubnetFailover を true に設定する必要はありません。 これは .NET Core と .NET 5 以降で必要です。
MultiSubnetFailover を使用した接続
FCI または AG のリスナーに接続するときに、常に MultiSubnetFailover=True を指定します。 MultiSubnetFailover により、SQL Server 2012 以降のすべての AG および FCI で高速フェールオーバーが可能になり、単一およびマルチサブネットの Always On トポロジのフェールオーバー時間が大幅に短縮されます。 マルチサブネット フェールオーバーの場合、クライアントは複数の接続を並列で試行します。 サブネット フェールオーバーの間、クライアントにより TCP 接続が頻繁に再試行されます。
MultiSubnetFailover 接続プロパティにより、アプリケーションが AG または FCI を使用していること、およびすべての IP アドレスへの接続を試みることで、SqlClient がプライマリ SQL Server インスタンス上のデータベースへの接続を試行することが示されます。 MultiSubnetFailover=True を接続に指定すると、クライアントは、オペレーティング システムの既定の TCP 再転送間隔よりも高速に接続試行を再試行します。 これにより、AG または FCI のフェールオーバーの後でより高速に再接続でき、単一およびマルチサブネットの AG と FCI の両方に適用可能です。
SqlClient の接続文字列キーワードの詳細については、ConnectionString を参照してください。
AG または FCI 意外のものに接続するときに MultiSubnetFailover=True を指定すると、パフォーマンスが低下するため、これはサポートされません。
Always On の機能のいずれかを使用してサーバーに接続するときは、次のガイドラインを使用してください。
単一のサブネットまたは複数のサブネットへの接続時には、
MultiSubnetFailover接続プロパティを使用します。これにより、両方の場合でパフォーマンスが向上します。AG に接続するには、使用する接続文字列でサーバーとして可用性グループのリスナーを指定します。
64 個を超える数の IP アドレスが構成された SQL Server インスタンスに接続すると、接続エラーが発生します。
MultiSubnetFailover接続プロパティを使用するアプリケーションの動作は、認証の種類 (SQL Server 認証、Kerberos 認証、または Windows 認証) によって影響を受けません。フェールオーバー時に対応し、アプリケーションの接続の再試行を減らすには、
Connect Timeoutの値を増やします。分散トランザクションはサポートされていません。
読み取り専用のルーティングが有効でない場合は、セカンダリ レプリカの場所への接続は、次の場合に失敗します。
セカンダリ レプリカの場所が接続を受け入れないように構成されている場合。
アプリケーションが
ApplicationIntent=ReadWrite(後で説明) を使用している場合、セカンダリ レプリカの場所は読み取り専用アクセスとして構成されます。
SqlDependency は、読み取り専用セカンダリ レプリカではサポートされていません。
プライマリ レプリカが読み取り専用のワークロードを拒否するように設定され、接続文字列が ApplicationIntent=ReadOnly を含んでいる場合、接続は失敗します。
データベース ミラーリングから複数のサブネット クラスターを使用するためのアップグレード
接続エラー (ArgumentException) は、MultiSubnetFailover および Failover Partner 接続のキーワードが接続文字列内に存在する場合や、MultiSubnetFailover=True および TCP 以外のプロトコルが使用された場合に発生します。 また、MultiSubnetFailover が使用されているとき、SQL Server から、データベース ミラーリング ペアに属していることを示すフェールオーバー パートナー応答が返された場合にも、エラー (SqlException) が発生します。
現在データベース ミラーリングを使用している SqlClient アプリケーションを複数のサブネットのシナリオへとアップグレードする場合、Failover Partner 接続プロパティを削除し、MultiSubnetFailover に設定した True で置き換え、接続文字列のサーバー名を可用性グループ リスナーと置き換える必要があります。 接続文字列が Failover Partner および MultiSubnetFailover=True を使用していると、ドライバーがエラーを生成します。 ただし、接続文字列が Failover Partner および MultiSubnetFailover=False (または ApplicationIntent=ReadWrite) を使用している場合、アプリケーションはデータベース ミラーリングを使用します。
データベース ミラーリングが AG のプライマリ データベースで使用される場合、および MultiSubnetFailover=True が可用性グループ リスナーではなくプライマリ データベースに接続する接続文字列で使用される場合、ドライバーはエラーを返します。
アプリケーションの目的の指定
ApplicationIntent=ReadOnly の場合、クライアントは AlwaysOn が有効になったデータベースに接続する場合に、読み取られたワークロードを要求します。 サーバーは、接続時および USE データベース ステートメントの間、その目的を強制しますが、AlwaysOn が有効になったデータベースに対してのみ、これを行います。
ApplicationIntent キーワードは従来の読み取り専用のデータベースでは機能しません。
データベースは、対象となる AlwaysOn データベースのワークロードの読み取りを許可または拒否できます。 (これは、PRIMARY_ROLE および SECONDARY_ROLE Transact-SQL ステートメントの ALLOW_CONNECTIONS 句を使用して実行されます。)
ApplicationIntent キーワードは、読み取り専用のルーティングを有効にするために使用されます。
読み取り専用ルーティング
読み取り専用ルーティングは、データベースの読み取り専用レプリカの可用性を実現する機能です。 読み取り専用のルーティングを有効にするには次のことが必要です。
- AlwaysOn 可用性グループの可用性グループ リスナーに接続する必要があります。
ApplicationIntent接続文字列キーワードをReadOnlyに設定する必要があります。- 可用性グループは、データベース管理者によって、読み取り専用のルーティングを有効にするように構成される必要があります。
読み取り専用のルーティングを使用する複数の接続のすべてが、同じ読み取り専用のレプリカに接続しないようにすることができます。 データベースの同期変更またはサーバーのルーティング構成の変更は、異なる読み取り専用のレプリカに対するクライアントの接続につながることがあります。 すべての読み取り専用の要求が、確実に同じ読み取り専用のレプリカに接続するようにするには、Data Source 接続文字列キーワードに可用性グループ リスナーを渡さないでください。 代わりに、読み取り専用のインスタンスの名前を指定します。
読み取り専用のルーティングでは、最初にプライマリに接続し、最適な可用性の読み取り可能なセカンダリを検索するため、プライマリに接続するよりも時間がかかる場合があります。 そのため、ログインのタイムアウトを増やす必要があります。