考えられる可用性レプリカ間の接続エラーの原因を判断する

  • [アーティクル]

適用対象:SQL Server

物理的な問題、オペレーティング システムの問題、または SQL Server の問題により、2 つの可用性レプリカ間のセッションが失敗する場合があります。 可用性レプリカでは、sqlservr.exe が依存しているコンポーネントを定期的にチェックして、それらのコンポーネントが正常に機能しているのか失敗したのかを確認する処理は行われません。 ただし、失敗の種類によっては、影響を受けたコンポーネントからエラーが sqlservr.exe に報告されます。 他のコンポーネントから報告されるエラーを ハード エラーといいます。

Always On 可用性グループでは、通知されないその他の失敗を検出するために、独自のセッション タイムアウト メカニズムを実装しています。 セッション タイムアウト期間は秒単位で指定されます。 このタイムアウト時間は、別のインスタンスからの PING メッセージを受信するために、サーバー インスタンスが待機する最大時間です。この時間を過ぎると、待機していたインスタンスは接続解除されたものと見なされます。 2 つの可用性レプリカ間でセッション タイムアウトが発生すると、可用性レプリカはエラーが発生したと想定し、 ソフト エラーを宣言します。

重要

プライマリ データベース以外のデータベースで発生した障害は検出されません。 さらに、データ ディスクの障害によりデータベースが再起動した場合を除き、データ ディスクの障害はほとんど検出されません。

したがって、エラー検出の速度と、失敗への反応時間は、ハード エラーかソフト エラーかによって異なります。 ハード エラーの中には、ネットワーク障害など、直ちに報告されるものもあります。 しかし、場合によっては、コンポーネント固有のタイムアウト時間のために報告が遅くなるハード エラーもあります。 ソフト エラーの場合は、セッション タイムアウト期間の長さによってエラー検出の速度が決まります。 既定では、この時間は 10 秒間です。 これは推奨最小値です。

ハード エラーによるエラー

次のような状況が、ハード エラーの原因になる可能性があります (ただし、これだけではありません)。

  • 接続またはケーブルの切断
  • 不適切なネットワーク カード
  • ルーターの変更
  • ファイアウォールの設定変更
  • エンドポイントの再構成
  • トランザクション ログの保存先ドライブの消失
  • オペレーティング システムまたはプロセスのエラー

たとえば、プライマリ データベースのログ ドライブが応答を停止し障害が発生すると、オペレーティング システムから sqlservr.exe に、深刻なエラーが発生したことが通知されます。

ネットワーク コンポーネントや一部の I/O サブシステムなど、コンポーネントによっては、障害を特定するための独自のタイムアウトを実装しているものもあります。 このようなタイムアウトは Always On 可用性グループとは独立して機能します。そのタイムアウトが認識されたり、その動作が把握されることはありません。 このような場合、タイムアウトの遅延により、障害が発生してから、可用性レプリカがハード エラーを受け取るまでの時間が増加します。

Note

ソフト エラーの場合には、可用性レプリカに対して実行されるアクティブなエラー チェックだけが発生します。 詳細については、このトピックの後半の「ソフト エラーによるエラー」を参照してください。

ネットワーク上で発生しているエラー状態を把握できるように、次のようなイベントが TCP 接続で発生した場合にはどのようなエラー メッセージがポートに送信されるのかを、ネットワーク エンジニアに問い合わせてください。

  • DNS が機能していません。
  • ケーブルが接続されていません。
  • Microsoft Windows に存在します。
  • ポートを監視しているアプリケーションで障害が発生しています。
  • Windows ベースのサーバーの名前が変更されています。
  • Windows ベースのサーバーが再起動しました。

Note

Always On 可用性グループは、サーバーにアクセスするクライアントに固有の問題からは保護されません。 たとえば、プライマリ レプリカへのクライアント接続をパブリック ネットワーク アダプターが処理していて、可用性グループのレプリカをホストしているサーバー インスタンス間のトラフィックをプライベート ネットワーク インターフェイス カードが処理している場合を考えます。 この場合、パブリック ネットワーク アダプターに障害が生じると、クライアントはデータベースにアクセスできなくなります。

ソフト エラーによるエラー

次のような状況が、セッション タイムアウトの原因になる可能性があります (ただし、これだけではありません)。

  • TCP リンクのタイムアウト、パケットの紛失または破損、不正な順序のパケットなどのネットワーク エラー。

  • オペレーティング システム、サーバー、またはデータベースの応答の停止。

  • Windows サーバーのタイムアウト。

  • CPU やディスクの過負荷、いっぱいになったトランザクション ログ、メモリやスレッドが不足しているシステムなど、コンピューティング リソースの不足。 このような場合は、タイムアウト期間を長くするか、ワークロードを軽減するか、ハードウェアを交換してワークロードを処理できるようにする必要があります。

セッション タイムアウトのメカニズム

サーバー インスタンスはソフト エラーを直接検出できないため、ソフト エラーが原因で、可用性レプリカがセッションでの他の可用性レプリカからの応答を無限に待機する可能性があります。 このような状態を防ぐため、 Always On 可用性グループ ではセッション タイムアウト メカニズムが実装されており、接続されている可用性レプリカは、一定の間隔で、開いている各接続に対して ping を送信します。 タイムアウト時間内に ping を受信した場合は、その接続がまだ開いており、サーバー インスタンスがその接続により通信していることを示します。 ping を受信すると、レプリカはその接続に対するタイムアウト カウンターをリセットします。 可用性モードとセッションのタイムアウトの関係については、「可用性モード (AlwaysOn 可用性グループ)」を参照してください。

プライマリ レプリカとセカンダリ レプリカは、アクティブであることを通知するために互いに ping を実行します。セッション タイムアウト制限を設定することにより、相手レプリカからの ping を受信するまで無期限に待機することがなくなります。 セッション タイムアウト制限はユーザーが構成できるレプリカ プロパティで、既定値は 10 秒です。 タイムアウト時間内に ping を受信した場合は、その接続がまだ開いており、サーバー インスタンスがその接続により通信していることを示します。 可用性レプリカは、ping を受信すると、接続のタイムアウト カウンターをリセットします。

セッション タイムアウト期間中に相手のレプリカから ping を受信しなかった場合、接続はタイムアウトします。接続は閉じられ、タイムアウトしたレプリカは DISCONNECTED 状態になります。 切断されたレプリカが同期コミット モード用に構成されている場合でも、トランザクションは、そのレプリカが再接続および再同期するのを待機しません。

エラーへの対応

エラーを検出したサーバー インスタンスは、エラーの種類に関係なく、インスタンスのロール、セッションの可用性モード、およびセッション内の他のすべての接続の状態に基づいて、適切な応答を行います。 パートナーの損失による影響については、可用性モード (AlwaysOn 可用性グループ) に関する説明を参照してください。

関連項目

次のステップ