2

原則として、SQL Server フェールオーバー クラスターは、SQL Server が実際にはサーバーのクラスターであるという事実に気付かずに、アプリケーションが接続できる仮想マシンとして自身を提示します。したがって、原則として、アプリケーションのデータベース アクセス層内に追加のロジックは必要ありません。 .

私の質問は、上記が正しいかどうか、およびフェールオーバー クラスターを使用する場合に DB アクセス層がどのように動作するかについてのベスト プラクティスの変更があるかどうかです。たとえば、フェイルオーバーが発生すると、遅延が発生し、DB アクセス層でタイムアウト エラーが発生する可能性があります。その層にロジックを配置して、タイムアウトが発生したときに [一部の] DB 呼び出しを再試行することを検討しています (既に再試行があります)。 DB デッドロックのロジック)。これにより、アプリケーションに影響を与えるエラーから別のレベルの保護が提供されます。

フェールオーバー スイッチが発生し、サービス コールでタイムアウト エラーを受け取った上位のアプリケーション レベルが発生した場合、それはシームレスなスイッチオーバーではありません。フェイルオーバーが可能な期間にタイムアウトを設定するだけでよいのでしょうか?

ありがとう。

4

1 に答える 1

1

原則として、SQL Server フェールオーバー クラスターは、SQL Server が実際にはサーバーのクラスターであるという事実に気付かずに、アプリケーションが接続できる仮想マシンとしてそれ自体を提示します。

ああ？本当に？それはドキュメンテーションと矛盾します。クラスターは基本的に、異なるサーバーに異なるインストールを行う移動 IP アドレスにすぎず、ほとんど仮想マシンではありません。

原則として、アプリケーションのデータベース アクセス層内に追加のロジックは必要ありません。

はい、いいえ - 失敗したノードは進行中のすべてのトランザクションと接続を強制終了します。明らかに、クライアントはそれに反応して再試行できる必要があります。接続がダウンして再試行しないためにクライアントがクラッシュした場合、1、2 秒後にサーバーに再び到達できるようになることは役に立ちません。

フェイルオーバーが可能な期間にタイムアウトを設定するだけでよいのでしょうか?

いいえ、進行中のトランザクションの状態が失われるため、フェールオーバーによって接続が切断されます。接続を再確立してから、トランザクションで発行されたすべての Sql コマンドを再度開始する必要があります。

セキュリティの観点から、クラスタリングは不適切であり、ミラーリングを使用する必要があることに注意してください。クラスタ ノードに障害が発生すると、データベース ファイルが破損し、フェイルオーバーが失敗するという特定のリスクがあります。ミラーリングはより堅牢です。

于 2012-07-04T09:04:23.813 に答える