今後数か月以内に SQL Server 2005 クラスターを実装する予定です。これを達成しようとするときに、データベース開発者としてどのような手順/予防措置を講じる必要があるか知りたいですか? ado.net コード (フロント エンド) やストアド プロシージャなどを変更する必要はありますか? 従うべきベストプラクティスはありますか?
私がこの質問をしている理由は、asp.net 負荷分散の場合、セッション/アプリケーション/キャッシュのすべてのコードが負荷分散環境に準拠していることを確認する必要があるためです。(したがって、インプロセス セッションを使用している場合は、負荷分散された環境で動作するようにそのコードを書き直す必要があります)。これは Web サーバー レベルです。データベース サーバー レベルでスケールアウトしようとするときに、正しいことをしたかっただけです。
この質問がばかげている場合は申し訳ありません。この件に関する私の限られた知識を許してください:-)
SQL Server クラスターを実装するためにフロント エンドを変更する必要はありません。通常どおり SQL Server インスタンスに接続するだけです。
ただし、SQL Server フェールオーバー クラスタリングは負荷分散ではありません。これは、プライマリ ノードでハードウェアに障害が発生した場合に冗長性を追加するために使用されます。もう一方の (セカンダリ) ノードは、プライマリに障害が発生するまで何も実行しません。プライマリに障害が発生した場合、フェールオーバーが自動的に発生し、データベースは 10 ～ 20 秒の遅延後に再び接続を提供します。
もう 1 つの問題は、セカンダリ ノードのキャッシュが空であるため、フェールオーバー後にパフォーマンスに影響が出る可能性があることです。SQL Server データベース ミラーリングを使用してミラー サーバーに "ウォーム" キャッシュを実装できますが、クラスタリングで同様のことを行う方法はありません。
データベースのクラスタリングは、ロード バランシングとは異なります。「スケールアウト」ではなく、高可用性です
基本的：
ノード 1 がオフラインになると、ノード 2 が引き継ぎます。または、手動でフェイルオーバーすることもできます。
これは、サービスがノード 1 でシャットダウンされ、ノード 2 がディスクとサービスを制御して起動することを意味します。すべての接続が切断され、状態またはセッションは転送されません。