SQL Server 2008フェイルオーバー戦略-ログ配布またはレプリケーション？
SQL Server2000からSQLServer2008に移行しました。
2000年には、フェイルオーバーに独自のログ配布を使用していました。 2008年には、独自のログ配布、組み込みのログ配布、またはレプリケーションを使用することを決定する必要があります。
サーバーには多くのデータベースがあります（400以上）。小さいものもあれば大きいものもあります。
DBサーバーの障害はまれであり、15〜30分のデータ損失を受け入れることができます。さらに重要なのは、2番目のDBサーバーを高速に起動することです。
上記の基準に基づいて、ログ配布またはレプリケーションの方が優れていますか？
ログ配布の場合、すべてのDBを確実に移動する簡単な方法はありますか？
ミラーリングを提案しているすべての人にとって、400個のデータベースをミラーリングすることは不可能です。 32ビットでも64ビットでも、400に達する前に、ワーカースレッドが不足します。プリンシパルのデータベースごとに少なくとも2つのワーカースレッドがあり、ミラー上のデータベースごとに少なくとも3つのワーカースレッドがあります。
それは実際にはDBAのスキルとは何の関係もありません。これは、ビジネスまたはアプリケーションのHA要件が何であるかに完全に依存します。これらは、DBAが対処できるものではなく、推進要因です。より複雑なソリューションが必須の場合、それを処理するDBAを取得することも必須です。 DBAのスキルのためにHAソリューションを制限することは無意味です。
データベースのミラーリングも高速検出や高速フェイルオーバーではありません。障害が何であるか、ミラーリングパートナーのタイムアウトが何であるか、SENDキューとREDOキューが何であるかに完全に依存します。ミラーがプリンシパルになることを決定したフェイルオーバーが完了するまでには、かなりの時間がかかる可能性があります。私は、2007年に退職して以来、多くのお客様がミラーリングを実装するのを支援してきました（Microsoftで、データベースミラーリングを他のストレージエンジンと一緒に所有していたときの両方）。
その数のデータベースのミラーリングを忘れてください。
推奨事項を提示する前に、回答する必要のある基本的な質問がいくつかあります。
- データベース全体または一部のみの冗長コピーが必要ですか？
- 冗長コピーを使用できるようにしますか？書き込み用ですか、それとも読み取り用ですか？
- データベースのトランザクションログ生成率はどれくらいですか？
- 2つのサイト間のネットワーク帯域幅はどれくらいですか？
ログ配布は、セットアップ、監視、および冗長コピーを迅速かつデータ損失の制限内でのみ実行できるという点で、おそらく最も簡単です。ログ配布では、データ損失を受け入れることにより、復元のためにキューに入れられたすべてのトランザクションログバックアップの復元を完了せずに、冗長コピーをオンラインにすることを選択できます。
また、中間層ルーティングテクノロジーを使用して単純なフェイルオーバーを実行したり、0/100構成のWindows NLBのような単純なものを実行したり、100/0に切り替えたりすることもできます。また、サーバー名を変更できない場合にDNSスイッチングを使用してフェイルオーバーを実行しているお客様もいます。
レプリケーションでは、パブリケーションデータベースのトランザクションログから収集され、ディストリビューションデータベースにアクセスしてから、ディストリビューションエージェントによってサブスクリプションデータベースにプッシュ/プルされるトランザクション間の予測できない遅延に対処する必要があります。レプリケーションは、それ自体がねじれてしまい、理解してリセットするのが面倒になる可能性もあります。ログの配布は非常に簡単です。
独自のログ配布を使用していることを考えると、トランザクションログの生成率とネットワーク帯域幅は問題ではないと思います。ログ配布に固執し、レプリケーションを避けたいと思います。データベースのミラーリングはボリュームでは機能しないため、考えないでください。
これがお役に立てば幸いです-マイクロソフト内のDBAにHAを教えるとき、これは本当に2日間の議論に値します-これに答えるのに5分に要約されます。コメントでより具体的な質問をフォローアップしてください。
ここにいくつかの追加の考えがあります：
レプリケーションが進むべき道だとは思いません。私は通常、レプリケーションをDRソリューションではなく、データを配布する方法と見なしています。 400個のデータベースを複製しようとすると、ディストリビューターとパブリッシャーの役割にストレスがかかる可能性が高く、最終的にサーバーがひざまずく可能性があります。さらに、各データベースのパブリッシャーとサブスクライバーを設定する必要があるため、スキーマの変更を実装、管理、および処理することは悪夢になります。
ログ配布の観点からは、はい、実行できますが、各データベースにログ配布を実装する必要があるため、実装と管理が困難になります。障害が発生した場合は、各データベースを手動でオンラインにし、すべてのアプリケーションを再ポイントする必要があります。ワークロードによっては、ソリューションが400データベースに拡張されない可能性があります。だからテストしてください。
これだけ多くのデータベースを扱う場合は、Geo-Clusterソリューションを実装するか、何らかの形式のSANレプリケーションを使用して、ボリュームまたはブロックレベルで作業することをお勧めします。 SANがない場合は、InMageやDoubletakeなどのサードパーティソフトウェアでうまくいく可能性があります。
ログ配布、データベースミラーリング、レプリケーションなどの各テクノロジーは、ワークロードを大幅に増加させ、サーバーのパフォーマンスに悪影響を与える可能性があることを忘れないでください。したがって、本番環境に移行する前にパフォーマンステストを実施してください。
ログ配布を決定した場合は、フェイルオーバーを含むプロセス全体をスクリプト化できます。
ロスミストリー、SQL MVP
作成者-SQLServer2008の管理と管理およびWindowsServer2008のリリース
Twitter- @ RossMistry
最大2番目のオンサイトリカバリにはミラーリングを使用します。
WANオフサイトバックアップ（高遅延など））では、組み込みのログ配布を使用します。
どちらのオプションでも、これをデータベースごとに設定する必要があることに注意してください。これは、400 DBの場合、後部で大きな問題になります。
ストレージアレイ（SANまたはNAS）を使用していますか？最も簡単な方法は、ストレージアレイスナップ（適切なSQL Server静止プラグインを使用）を介したブロックレベルのレプリケーションであるようです。これにより、すべてのデータベースが自動的にキャプチャされます。
あなたの会社にはいくらのお金がありますか？
それらがフラッシュしていて、データベースのallを移動する必要がある場合は、ウォームSAN別のオフサイトアクティブ/パッシブへのレプリケーションを備えた2ノードアクティブ/パッシブクラスタークラスターはトリックを行います:)
そうでない場合は、ログ配布に固執します-2008 Enterpriseは、圧縮されたログバックアップ（CPUを犠牲にして）の利点を提供し、2005年以降のSQLのすべてのエディションには、完全バックアップと同時にログバックアップを作成する機能があります（これは問題がありました）大量のトランザクションアクティビティがある2000ボックス）。
それは主にあなたのDBAのスキルに依存します。
熟練したDBAがある場合、ミラーリングが最も安全なオプションであり、監視サーバーで構成すると、「クライアント」はわずかな遅延以外は何も気付かないはずです。 DBAのスキルが低い場合は、ログ配布が最適ですが、プライマリデータファイルにまだコミットされておらず、転送されていないトランザクションの再生を伴う、より複雑なフェイルオーバールーチンがあります。 15〜30分以内のデータを失うことを検討している場合は、ミラーリングが最善のオプションです。
2台のサーバーのみでこれを行う場合は、高セキュリティモードに設定する必要があります。3番目のオプションのWitnessサーバーはSQL2008 Expressインスタンスにすることができるため、最小限のハードウェアコストしか発生しないため、これを除外しないでください。オプションとして。
このモードでドメインのメンバーではない2つのSQL2005サーバーをミラーリングする方法に関するガイドを作成しました。@ http://danmacs.blogspot.com/2009/05 /database-mirroring-for-non-domain-ms.html
このシナリオでは、フェイルオーバーは手動（ただし高速）であり、1つのトランザクションが失われる可能性があります（ミラーが正しく動作していると仮定）[〜＃〜]しかし[〜＃〜]それに接続しているクライアントは手動で移動する必要があります（またはTCP/IPを実行していて、名前付きパイプを使用していない場合はDNS変更を介して、名前付きパイプが非常にうまく機能しますが、はっきりとは言えませんでした）
http://msdn.Microsoft.com/en-us/library/ms366349（SQL.90）.aspx
10個のミラーリングされたDBが32ビットマシンの最大値であると言います。
純粋にフェイルオーバー用の2番目のDBですか、それともで使用できるようにしたいですか？ MIレポート用。
ミラーリングも検討しましたか？
これに予算がありますか、それとも内部ツールの使用を検討していますか。私は過去にログ配布とレプリケーションの両方を使用しましたが、現在はこれまで素晴らしいダブルテイクを使用しています。
400以上のデータベースを手動でログに記録するシステムの作成に多くの時間を費やしていて、それが機能する場合は、それを使い続けます。それが一緒に石畳になっていて、（そこにいて）走り続けるのが苦痛であるなら、変化の時であり、ミラーリングを続けるかもしれません。
データベースミラーリングを使おうとすると、400以上は言うまでもなく、100のデータベースに到達するかなり前にワーカースレッドが不足すると思います。 this を見てください。
ミラーリングされたすべてのデータベースは2つのスレッドを使用し、SQLServerはデフォルトで255スレッドでのみ実行するように構成されています。ワーカースレッドが不足すると、不幸なことが起こります。より多くのスレッド（512、IIRC）で構成されたサーバーを実行しましたが、MSが非常に神経質になっているようです。 MSを神経質にする何かをすることはひどく終わる傾向があります。
ログトラフィックがあまり多くなく、データベースの設定と監視に役立つツールをいくつか作成していると仮定すると、400個のログ配布データベースを使用できると思います。ツールは、tsqlまたはpowershellのようなもので作成できます。
私にとって、ログ配布の本当の問題は、他のサーバーに同じログイン/パッケージ/リンクサーバーなどがあることを確認し、フェイルオーバーサーバーに同じジョブがあることを確認することです（ただし、必要になるまで無効にします）それらを有効にするには、それらを有効または無効にする方法が必要です）、元のプライマリサイトに戻る失敗する、ログ配布を再確立する方法なんらかの理由でログシーケンスが壊れた場合、そのようなことです。展開を行うとき、他のサーバーを実行することを忘れがちです。