データベース ミラーリング中に発生する可能性のあるエラー
物理的な問題、オペレーティング システムの問題、または SQL Server の問題により、データベース ミラーリング セッションが失敗する場合があります。 データベース ミラーリングでは、Sqlservr.exe が依存しているコンポーネントを定期的にチェックして、それらのコンポーネントが正常に機能しているのか失敗したのかを確認する処理は行われません。 ただし、失敗の種類によっては、影響を受けたコンポーネントからエラーが Sqlservr.exe に報告されます。 他のコンポーネントから報告されるエラーを ハード エラーといいます。 データベース ミラーリングでは、通知されないその他の失敗を検出するために、独自のタイムアウト メカニズムを実装しています。 ミラーリングでタイムアウトが発生すると、データベース ミラーリングでは失敗が発生したと想定し、 ソフト エラーを宣言します。 ただし、SQL Server のインスタンス レベルで発生する一部の失敗ではミラーリングがタイムアウトしないため、失敗が検出されない場合があります。
重要
ミラー化されたデータベース以外のデータベースで発生した障害は、データベース ミラーリング セッションでは検出されません。 さらに、データ ディスクの障害によりデータベースが再起動した場合を除き、データ ディスクの障害はほとんど検出されません。
したがって、エラー検出の速度と、ミラーリング セッションの失敗への反応時間は、ハード エラーかソフト エラーかによって異なります。 ハード エラーの中には、ネットワーク障害など、直ちに報告されるものもあります。 しかし、場合によっては、コンポーネント固有のタイムアウト時間のために報告が遅くなるハード エラーもあります。 ソフト エラーの場合は、ミラーリング タイムアウト時間の長さによってエラー検出の速度が決まります。 既定では、この時間は 10 秒間です。 これは推奨最小値です。
ハード エラーによるエラー
次のような状況が、ハード エラーの原因になる可能性があります (ただし、これだけではありません)。
接続またはケーブルの切断
不適切なネットワーク カード
ルーターの変更
ファイアウォールの設定変更
エンドポイントの再構成
トランザクション ログの保存先ドライブの消失
オペレーティング システムまたはプロセスのエラー
たとえば、プリンシパル データベースのログ ドライブが応答を停止し障害が発生すると、オペレーティング システムから Sqlservr.exe に、深刻なエラーが発生したことが通知されます。
ネットワーク コンポーネントや一部の IO サブシステムなど、コンポーネントによっては、障害を特定するための独自のタイムアウトを実装しているものもあります。 このようなタイムアウトはデータベース ミラーリングとは独立して機能します。データベース ミラーリングでは、そのタイムアウトを認識したり、その動作を完全に把握することはありません。 このような場合、タイムアウトの遅延により、障害が発生してから、データベース ミラーリングがハード エラーを受け取るまでの時間が増加します。
注意
ソフト エラーの場合には、データベース ミラーリングに対して実行されるアクティブなエラー チェックだけが発生します。 詳細については、このトピックの後半の「ソフト エラーによるエラー」を参照してください。
ネットワーク上で発生しているエラー状態を把握できるように、次のようなイベントが TCP 接続で発生した場合にはどのようなエラー メッセージがポートに送信されるのかを、ネットワーク エンジニアに問い合わせてください。
DNS が動作していません。
ケーブルが接続されていません。
Microsoft Windows に存在します。
ポートを監視しているアプリケーションで障害が発生しています。
Windows ベースのサーバーの名前が変更されています。
Windows ベースのサーバーが再起動されています。
Note
サーバーにアクセスするクライアント専用のパブリック NIC の障害はミラーリングによって保証されません。 たとえば、パブリック ネットワーク アダプターがプリンシパル サーバー インスタンスへのクライアント接続を処理していて、プライベート ネットワーク インターフェイス カードがサーバー インスタンス間のすべてのミラーリング トラフィックを処理している場合を考えます。 この場合、パブリック ネットワーク アダプターに障害が生じると、クライアントはデータベースにアクセスできなくなります。ただし、データベースのミラー化は引き続き行われます。
ソフト エラーによるエラー
次のような状況が、ミラーリング タイムアウトの原因になる可能性があります (ただし、これだけではありません)。
TCP リンクのタイムアウト、パケットの紛失または破損、不正な順序のパケットなどのネットワーク エラー。
オペレーティング システム、サーバー、またはデータベースの応答の停止。
Windows サーバーのタイムアウト。
CPU やディスクの過負荷、いっぱいになったトランザクション ログ、メモリやスレッドが不足しているシステムなど、コンピューティング リソースの不足。 このような場合は、タイムアウト期間を長くするか、ワークロードを軽減するか、ハードウェアを交換してワークロードを処理できるようにする必要があります。
ミラーリング タイムアウトのメカニズム
サーバー インスタンスはソフト エラーを直接検出できないので、ソフト エラーのために、サーバー インスタンスが無限に待機する可能性があります。 このような状態を防ぐため、データベース ミラーリングではタイムアウト メカニズムが実装されており、ミラーリング セッション内の各サーバー インスタンスは、一定の間隔で、開いている各接続に対して ping を送信します。
接続が開いた状態を維持するためには、定義されたタイムアウト期間と、ping をもう 1 回送信するために必要な時間を足した時間内に、その接続でサーバー インスタンスが ping を受信する必要があります。 タイムアウト時間内に ping を受信した場合は、その接続がまだ開いており、サーバー インスタンスがその接続により通信していることを示します。 ping を受信すると、サーバー インスタンスはその接続に対するタイムアウト カウンターをリセットします。
タイムアウト時間内に接続で ping を受信しない場合、サーバー インスタンスは接続がタイムアウトしたものと見なします。サーバー インスタンスは、タイムアウトした接続を閉じ、セッションの状態と動作モードに従ってタイムアウト イベントを処理します。
他のサーバーが実際には正常に動作し続けていたとしても、タイムアウトは障害と見なされます。 いずれかのパートナーの通常の応答時間に対し、セッションのタイムアウト値が短すぎる場合は、誤認エラーが発生する可能性があります。 あるサーバー インスタンスが別のサーバー インスタンスに正常に接続しても、接続先の応答時間が遅すぎて、タイムアウト時間が経過する前に ping を受信できない場合、誤認エラーが発生します。
高パフォーマンス モードのセッションでは、タイムアウト時間は常に 10 秒です。 これは一般的に誤認エラーを避けるには十分な時間です。 高い安全性モードのセッションでは、既定のタイムアウト時間は 10 秒ですが、変更できます。 誤認エラーを避けるために、ミラーリングのタイムアウト時間を常に 10 秒以上にすることをお勧めします。
タイムアウト値を変更するには (高い安全性モードのみ)
- ALTER DATABASE <データベース> SET PARTNER TIMEOUT <整数値> ステートメントを使用します。
現在のタイムアウト値を表示するには
- sys.database_mirroring の mirroring_connection_timeoutにクエリを行います。
エラーへの対応
エラーを検出したサーバー インスタンスは、エラーの種類に関係なく、インスタンスのロール、セッションの動作モード、およびセッション内の他のすべての接続の状態に基づいて、適切な応答を行います。 パートナーと通信できなくなった場合の処置の詳細については、「 Database Mirroring Operating Modes」を参照してください。
参照
役割の交代中に発生するサービスの中断時間の算出 (データベース ミラーリング)
Database Mirroring Operating Modes
データベース ミラーリング セッション中の役割の交代 (SQL Server)
データベース ミラーリング (SQL Server)