私の会社にはSQL Server 2005インスタンスのフェールオーバーペアがあり、ULライセンスのアラーム/コールセンターにデータベースの可用性を提供します。稼働時間と可用性は生命の安全にとって重要です。
以下は、ビジネスクリティカルなアプリケーション(保護のためにサニタイズ)の1つのconnectionStringsからの行の例です。
<add name="MyCompany.MyApp.Properties.Settings.MyDbConnectionString"
connectionString="Data Source=Principal-DB;Failover Partner=Mirror-DB;
Initial Catalog=MyDb; Integrated Security=True; Persist Security Info=True;"
providerName="System.Data.SqlClient" />
約30分前、これは私たちが信じているシナリオです:
私たちの理論は、Principal-DBが接続要求に応答する状態になかったためまったくであり、復元状態にある場合は通常、このような接続を迅速に拒否するため、クライアントアプリケーションは終了しました。プライマリサーバーが応答するまで、割り当てられた接続タイムアウト全体(デフォルトは20秒)を待ってから、リストされているフェイルオーバーパートナーへの接続を試行せずにタイムアウトエラーを返します。
簡単な修正は、データソースとフェイルオーバーパートナーのインスタンスを交換するApp.configを含むクライアントアプリケーションに更新をプッシュすることでした。そのため、Mirror-DBは、アプリが最初に接続しようとしたサーバーになりました。 Principal-DBにフェールバックするとき、別のアプリケーションの更新でこの変更を取り消す必要があります。
より永続的な修正が必要です。これはフェイルオーバーペアの予想される動作ではなく、再び発生することは許されません。エラーを返す前に、この状況でフェールオーバーパートナーへの接続を正しく試みるようにクライアントアプリケーションを構成する方法が必要です。
問題が見つかりました。
SQL Native Clientと.NET SQLデータプロバイダーは、プライマリがダウンしている場合でも、シームレスにフェールオーバーパートナーに接続する必要があります。ただし、両方のプロバイダーの既定の構成では、TCP/IPと名前付きパイプの両方を試します。
この構成は問題なく、サーバーが両方とも利用可能であるが、プライマリがバックアップにフェイルオーバーしている場合に適切に機能します。ネットワーク層の接続は成功しますが、アプリケーションレベルの接続はすぐに拒否され、クライアントが試行します。鏡。ただし、プライマリが応答しない場合、クライアントは、プライマリサーバーが最初にTCP/IPを介して、次に名前付きパイプを介して(デフォルトでは20から30まで)応答するのを待つだけで、デフォルトの20秒のタイムアウト期間全体を浪費します。ネットワークレベルでの2秒のタイムアウト期間)。したがって、この状況では、バックアップミラーを試したことがなくてもエラーが返されます。
このTechNet記事 による解決策は、クライアントに何らかの方法で強制的にTCP/IPのみを使用して接続することです。これは、クライアントが両方のパートナーを試す十分な時間があるほど速く失敗します。 。これを行うようにデータプロバイダーを手動で構成するか、接続文字列で使用する適切なプロトコルを指定することにより、ケースバイケースでデフォルト設定を上書きできます。 TCP/IPを強制するインクルードするパラメータはNetwork=dbmssocn;
。それに加えて、SQLクライアントは、あきらめてフェイルオーバーミラーを試行する前に「3回のストライク」アプローチをとります。そのため、接続タイムアウトは、このプロセスを通過してフェイルオーバーパートナーを少なくとも1回試行するのに十分な長さに設定する必要があります。 30秒のタイムアウトで十分です。
プライマリDBサーバーの電源が再びオフになったときにこの修正を試みましたが、機能しました。現在、すべての社内アプリの構成ファイルを更新しています(このフェールオーバーペアを対象とするデスクトップアプリケーションとイントラネットサイトが少なくとも6ダースあります。これは非常に愛されているスタックです)。