SQL Serverの高可用性、ソリューションの短所と長所？
私は自分の論文のためにSQLServerの高可用性について研究しています。これをアーカイブするためのいくつかの解決策があることを学びました：
- フェイルオーバークラスタリング
- ログ配送
- レプリケーション
私が知っているように、これらのソリューションは以前のバージョンのSQL Server 2008でサポートされていました。SQLS2008はデータベースミラーリングを提供します。これはより良いソリューションと想定されています。私はこれについて本当に疑っています。これらのソリューションの短所と長所、使用すべき戦略と使用すべきでない戦略を教えてください。詳細情報と説明は私に大いに役立ちます
どうもありがとうございました。
ブレントはログ配布とデータベースミラーリングをうまくカバーしていたので、それについては触れません。このトピックに関する必読は、Allan Hirtの本 Pro SQL Server 2005 High Availability です。これは2005年のものであることは知っていますが、SQL Server 2008にも95％関連しています。利用可能なオプションをよく理解するには、これを読む必要があります。ブレントの応答への私の追加は次のとおりです。
フェイルオーバークラスタリング
財務、電力、サーバールームのリソースに制約がない場合は、SQLServerの高可用性を実現するためにこれを選択することをお勧めします。共有ディスクストレージが必要です。通常、これを機能させるにはSAN）であり、DRを簡単にするためにCドライブをSANにも配置することを好みます。セットアップには、クォーラムLUN（Q）、MSDTC LUN（M）、およびクラスター内のSQL Serverの各インスタンスのマウントポイントが必要です。マウントポイント内に、SQLData、SQLLogs、SQLBackups、およびオプションでLUNをセットアップします。 SQLtempdb。1つのインスタンスの場合、最終的にD：\ SQLData、D：\ SQLLogs、D：\ SQLBackups、D：\ SQLtempdb（たとえば）になります。次のインスタンスの場合、E：\ SQLData、E：\ SQLLogsがあります。 、E：\ SQLBackups、E：\ SQLtempdb。すべての共有ディスクをクラスター内のすべてのノードに提示する必要があります。フェイルオーバーは自動で、実稼働環境では約20秒かかります。堅牢ですが、設定が難しい場合があります。経験が浅い場合はアップしてください。
仮想化されたSQL Server
まだ検討していないオプションは、vmwareESXサーバーを使用してデータベースサーバーをホストすることです。私はこのオプションが本当に好きですが、まだ実稼働環境にデプロイする自信がありません。私はそれを非実稼働環境で非常にうまく展開しました、そして技術は傑出しています。中程度から軽負荷のSQLServerにのみ適しており、パフォーマンスが重要な場合やワークロードが高い場合は使用しないでください。 SQL ServerからESXホストへの1対1のマッピングは、非常に望ましい構成です。 vmware VMotionは、フェールオーバークラスタリングよりもはるかに短いダウンタイムを備えた優れたテクノロジーです。サーバーでビデオが再生されているデモを見たことがありますが、サーバーはグリッチなしで実行されているビデオでフェイルオーバーされました。さて、それは印象的です！
SQL Serverレプリケーション
これは、スキーマの変更が必要になる可能性があるため、サードパーティのアプリケーションではうまく機能しない可能性があります。 SQL Serverレプリケーションは、高可用性を目的として設計されたのではなく、データのコピーを他の場所で利用できるようにするために設計されました。複雑であるため、高可用性のためにこれを使用することはお勧めしません。ただし、提供される粒度のレベルが低いため、特定のシナリオで役立つ場合があります。たとえば、データの水平および垂直分割を実行できます。
サードパーティのディスクレプリケーション
NSIのダブルテイクなどのソリューションは、高可用性についても検討できますが、SANベース以外のシステムのディザスタリカバリに使用することを好みます。基本的に、ブロックレベルでデータをターゲットサーバーに複製し、ターゲットサーバーはソースサーバーの可用性を監視します。使用できなくなると、フェイルオーバー状態がトリガーされ、自動的にフェイルオーバーするように設定したり、手動フェイルオーバーを警告したりできます。フェイルオーバー時間は、SQLServerクラスタリングと同様です。利点は、それを行うために特別なハードウェアを必要としないことですが、ソフトウェアライセンスは高価になる可能性があります。
バックアップと復元
実際には高可用性ソリューションではありませんが、要件が緩い一部の人々にとって、この非常に単純なソリューションは、必要なすべてを提供する可能性があります。スケジュールに従ってデータベースをバックアップサーバーにバックアップし、バックアップファイルがターゲットマシンで使用可能であることを確認するだけです。ファイルがバックアップされたときにファイルを復元するジョブを設定すると、安価で大まかな高可用性ソリューションが得られます。
ログ配布：
概要：プリンシパル上のトランザクションはディスクにキューに入れられ、レプリケーションスケジュールに基づいてミラーに送信されます。ログは、スケジュールに基づいてミラーデータベースに適用されます。
SQL Edition：Standard、Enterprise
管理者の努力：トランザクションログのドロップ場所としてミラー上のネットワーク共有をセットアップし、セットアップのためにSQLウィザードを実行します
自動フェイルオーバー：Witnessサーバーが存在しない場合は不可能
手動フェイルオーバー：コミットされていないトランザクションログファイルをデータベースに適用する必要があります
障害の懸念：ミラー上にネットワーク共有を提示するためにWindowsに依存しているため、中程度。ミラーでのトランザクションログの適用が停止すると、それらは蓄積されます
I/O：ミラーリングよりも高い
ミラーリング：
概要：プリンシパルのトランザクションはプリンシパルでコミットされ、ミラーに送信されます。ミラーがトランザクションをコミットすると、プリンシパルに別のトランザクションの準備ができていることを通知します。
SQLエディション：エンタープライズ
自動フェイルオーバー：Witnessサーバーが存在しない場合は不可能
手動フェイルオーバー：接続が存在する場合は、ミラーリングモードを同期に切り替えます。接続がない場合は、SQLステートメントを発行して強制サービス復元を実行します。その後、ペアを再同期できます
パフォーマンス：ログ配布と比較して低い
個人ラボ作業：
SQL 2005StandardおよびEnterpriseを使用して実施。
紙の上ではログ配布が良いアイデアだと思いましたが、ラボでフェイルオーバーをセットアップして実行するのは複雑でした。ミラーリングは非常にエレガントで、トランザクションが両方のペアにコミットされたという事実を知っていました。
ターゲットをプライマリとして立ち上げるときが来たら、トランザクションログファイルを適用することをいじくり回す必要はありません。短いRTOが必要な場合は、ミラーリングを試してみます。
ミラーリングされたペアのレプリケーションの同期（トランザクションは完了としてマークされる前に両方のペアにコミットされる）モードと非同期（プリンシパルでコミットしてからターゲットに送信される）モードについて詳しく読む必要があります。 LANを使用すると、同期モードで実行できますが、WAN）では、同期モード（10〜20ミリ秒未満）の場合は遅延を監視する必要があります。そうしないと、アプリケーションへの応答時間が長くなります。速度を落とす。
SQL 2005 Enterpriseエディションのみが非同期をサポートしていることに注意してください。これは、「ハイパフォーマンスモード」またはSQLサーバーのSAFETYプロパティを「オフ」にすることとも呼ばれます。
申し訳ありませんが、クラスタリングの経験はありません。
MSDNソース
データベースミラーリングの概要 http://msdn.Microsoft.com/en-us/library/ms189852%28SQL.90%29.aspx