高可用性、ディザスター リカバリーのための SqlClient のサポート

  • [アーティクル]

ADO.NET のダウンロード

このトピックでは、高可用性、ディザスター リカバリー Always On 可用性グループのための Microsoft SqlClient Data Provider for SQL Server のサポートについて説明します。 Always On 可用性グループの機能は SQL Server 2012 に追加されています。 Always On 可用性グループの詳細については、SQL Server オンライン ブックを参照してください。

現在は、接続プロパティで、(高可用性、障害回復) 可用性グループ (AG) の高可用性グループ リスナーまたは SQL Server 2012 フェールオーバー クラスター インスタンスを指定できます。 SqlClient アプリケーションを Always On データベースに接続しているときにフェールオーバーが発生した場合、元の接続は切断され、アプリケーションではフェールオーバー後に処理を続行するために新しい接続を開く必要があります。

可用性グループ リスナーまたは SQL Server 2012 フェールオーバー クラスター インスタンスに接続していない場合、複数の IP アドレスがホスト名に関連付けられていると、SqlClient は、DNS エントリに関連付けられたすべての IP アドレスを順に反復処理します。 これは、DNS サーバーによって返された最初の IP アドレスがネットワーク インターフェイス カード (NIC) にバインドされていない場合、時間がかかります。 可用性グループ リスナーまたは SQL Server 2012 フェールオーバー クラスター インスタンスに接続する場合、SqlClient ですべての IP アドレスへの接続確立を並列実行しようとして、接続試行が成功すると、ドライバーは保留状態の接続試行を破棄します。

Note

接続タイムアウトの増加および接続の再試行ロジックの実装により、アプリケーションが可用性グループに接続する可能性は向上します。 また、接続がフェールオーバーによって失敗する可能性があるので、接続の再試行ロジックの実装は、失敗した接続が再接続するまで試行されるようにする必要があります。

Microsoft SqlClient Data Provider for SQL Server では、次の接続プロパティがサポートされています。

  • ApplicationIntent

  • MultiSubnetFailover

プログラムによって、これらの接続文字列キーワードを次のとおりに変更できます。

MultiSubnetFailover を使用した接続

SQL Server 2012 可用性グループ リスナーまたは SQL Server 2012 フェールオーバー クラスター インスタンスに接続する際には、必ず MultiSubnetFailover=True を指定してください。 MultiSubnetFailover を指定することで、SQL Server 2012 のすべての可用性グループとフェールオーバー クラスター インスタンスに対して高速フェールオーバーが有効化され、単一サブネットおよびマルチサブネットの Always On トポロジにおけるフェールオーバー時間が大幅に短縮されます。 複数のサブネットのフェールオーバーでは、クライアントは並列接続を試みます。 サブネットのフェールオーバー中に、積極的に TCP 接続を再試行します。

MultiSubnetFailover 接続プロパティは、アプリケーションが可用性グループまたは SQL Server 2012 フェールオーバー クラスター インスタンスで展開されていること、およびすべての IP アドレスへの接続を試行することで SqlClient がプライマリ SQL Server インスタンスのデータベースに接続を試行することを示します。 接続に対して MultiSubnetFailover=True を指定した場合、クライアントは、オペレーティング システムの既定の TCP 再送信間隔より短い間隔で TCP 接続を再試行します。 これにより、Always On 可用性グループまたは Always On フェールオーバー クラスター インスタンスのフェールオーバー後、再接続されるまでの時間を短縮することができます。単一サブネットとマルチサブネットの可用性グループ インスタンスおよびフェールオーバー クラスター インスタンスに適用することができます。

SqlClient の接続文字列キーワードの詳細については、ConnectionString を参照してください。

可用性グループ リスナーまたは SQL Server 2012 フェールオーバー クラスター インスタンス以外の何かに接続する場合に MultiSubnetFailover=True を指定すると、パフォーマンスに負の影響が及ぶ可能性があるため、サポートされていません。

可用性グループまたは SQL Server 2012 フェールオーバー クラスター インスタンス内のサーバーに接続する際には、次のガイドラインに従います。

  • 単一のサブネットまたは複数のサブネットへの接続時には、MultiSubnetFailover 接続プロパティを使用します。これにより、両方の場合でパフォーマンスが向上します。

  • 可用性グループに接続するには、使用する接続文字列でサーバーとして可用性グループの可用性グループ リスナーを指定します。

  • 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 が指定されている場合、Always On が有効になっているデータベースにクライアントが接続するときに読み取りワークロードが要求されます。 サーバーは、接続時および USE データベース ステートメントの間、その目的を強制しますが、AlwaysOn が有効になったデータベースに対してのみ、これを行います。

ApplicationIntent キーワードは従来の読み取り専用のデータベースでは機能しません。

対象の AlwaysOn データベースのワークロードの読み取りを許可または禁止できます。 (これは、PRIMARY_ROLE および SECONDARY_ROLE Transact-SQL ステートメントの ALLOW_CONNECTIONS 句を使用して実行されます。)

ApplicationIntent キーワードは、読み取り専用のルーティングを有効にするために使用されます。

読み取り専用ルーティング

読み取り専用のルーティングはデータベースの読み取り専用のレプリカの可用性を確保できる機能です。 読み取り専用のルーティングを有効にするには次のことが必要です。

  • AlwaysOn 可用性グループの可用性グループ リスナーに接続する必要があります。

  • ApplicationIntent 接続文字列キーワードを ReadOnly に設定する必要があります。

  • 可用性グループは、データベース管理者によって、読み取り専用のルーティングを有効にするように構成される必要があります。

読み取り専用のルーティングを使用する複数の接続のすべてが、同じ読み取り専用のレプリカに接続しないようにすることができます。 データベースの同期変更またはサーバーのルーティング構成の変更は、異なる読み取り専用のレプリカに対するクライアントの接続につながることがあります。 すべての読み取り専用の要求が、確実に同じ読み取り専用のレプリカに接続するようにするには、Data Source 接続文字列キーワードに可用性グループ リスナーを渡さないでください。 代わりに、読み取り専用のインスタンスの名前を指定します。

読み取り専用のルーティングでは、最初にプライマリに接続し、最適な可用性の読み取り可能なセカンダリを検索するため、プライマリに接続するよりも時間がかかる場合があります。 そのため、ログインのタイムアウトを増やす必要があります。

次のステップ