SAN SQL Serverのディザスタリカバリにレプリケーション/スナップショットを使用していますか？
単一のデータベースサーバーでSQLServer2008を利用するWebアプリケーションがあります。すべてのストレージはローカルです。過去1年間、あらゆる形式のSQL Serverレプリケーションを構成で機能させるように努めてきましたが、機能しません。その理由は、常に更新されている2,000を超えるデータベース（クライアントごとに1つ）があるため、テストでは、すべての形式のレプリケーションがリソースを大量に消費することが示されています。
この質問をするたびに、データベースが多すぎるという事実に人々が集中します。これは（規制やその他の理由で）変更できないものなので、データを複製する方法に焦点を当てたいと思います。
1つのオプションは、すべてのデータをSANに移動し、SANにデータを複製させる（または頻繁にスナップショットを作成する）ことです）と言われています。 、データベースサーバーに障害が発生した場合、この場合データベースが破損するリスクはありますか？別のSANに複製されたSANを活用して、まともなDRソリューションを提供することは可能ですか（この場合、最大で約30分のデータですが、1日の価値を失うことはありません...つまり、前夜のバックアップに進むことはできません）。
他の回答で述べたように：
古いスタイルのデータベースミラーリングと新しいスタイルのAlwaysOnにはスレッドが必要であり、2000データベースのスレッドは間違いなく不足します。実際の制限は200データベースをはるかに下回っていることを大いに思い出します。 （これについてのホワイトペーパーはどこかにありますが、私は今それを探すのが面倒なので、この答えはすでに非常に長くなっています。）もちろん、インスタンスあたり200個のデータベース。理論的には、20個のインスタンスを起動し、各インスタンスで100個のデータベースを実行できます。これらすべてを管理するのは面倒であり、これらすべてのインスタンス間のメモリを管理するのは頭痛の種になると思います。
SQL Serverレプリケーション（ファイルではなくテーブル（またはテーブルのサブセット）の複製）は、実際にはDRを対象としたものではありません。たとえ少数のデータベースであっても、セットアップと管理は困難です。データモデルを機能させるには、データモデルを変更する必要がある場合があります。これは、アプリの変更を意味する場合があります。 2000（おそらく同一またはほぼ同一の）データベースのそれぞれに同じ複製構成を適用する自動化された方法が必要です。レプリケーションを構成するために使用する必要のあるストアドプロシージャは面倒です。 GUIを介したレプリケーション用に構成された2000データベースの管理は、悪夢になります。フェイルオーバーする場合、すべてを再び機能させるために変更を加える必要がある場合があります。フェイルオーバー時間は、回避できる厄介な変更や作業を行いたいときではありません。すべてをできるだけ早く復旧させて実行したいとします。それは問題のパックのように思えます。
SANストレージユニット間のレプリケーションは、特にEMCのような服装のハードウェアについて話している場合、コストがかかる可能性があります。ベンダーから始めると、アップグレード、メンテナンス、追加スペースなど.
提案＃1： SteeleyeのDataKeeperのようなものを見ましたか？これは、Windowsフェールオーバークラスタリングを活用する、サーバー上で実行されるソフトウェアベースのレプリケーション製品です。私は実際にそれを使ったことがなく、いくつかの犬と子犬のショーに座っている以外は会社とは関係がありません。それはあなたの状況に理想的に見えます。
提案＃2：それが私であり、予算がまったくない場合、自家製のログ配送システムを調べます。組み込みのログ配布が2000データベースを適切に処理するかどうかは疑問です。ログ配布システムを作成することはそれほど難しくなく、環境に固有のすべての問題に対処できます。 （たとえば、ファイルをsftp経由でDRサイトに送信する必要がある場合があります。）
基本的に、システムには3つの部分があります。各パーツは定期的に実行する必要があります。
一部はトランザクションログのバックアップを取り、各データベースのtlogバックアップファイルを異なるフォルダーに配置します（ファイルシステムのスケーリング用）。私はこれにメンテナンスウィザードを使用しません。何度も不安定になり、データベースをスキップし始め、一般的に誤動作するのを見てきました。 30分の保証を提供したい場合、これはおそらく15分ごとに実行されます。
一部は、バックアップファイルをステージング領域からDRサイトにコピーします。 DRへのVPNがある場合、これはrobocopyCMDファイルのような単純なものである可能性があります。より洗練されたものが必要な場合は、パッケージまたはpowershellスクリプトを作成できます（sftpまたはssh/scp、または組み込みのバックアップ圧縮がない場合はZip/unzip）。これは、すべてを確実に取得するために、より高速に、おそらく5分ごとに実行できます。何かがオフサイトにコピーされると、それは「安全」です。
- 一部は、DRサイトで検出したtlogバックアップをセカンダリサーバーに復元します。復元されたtlogを識別し、それらを移動するか、スケジュールに従って削除する必要があります。そうしないと、最終的にスペースが不足します。これはそれほど頻繁に実行する必要はありませんが、問題が発生したときにDRのセカンダリ「ライブ」を宣言する前に、使用可能なすべてのtlogバックアップが適用されていることを確認する必要があります。
3つのステップすべてを監査するテーブル、何が起こったかを示すいくつかのレポート/スクリプトが必要です（特定のデータベースがプライマリサイトまたはセカンダリサイトで実行されていますか？セカンダリ上のデータベースで、たとえば2時間以内にtlogの復元が見られませんか？ ）およびアラートスキーム。
その上で、フェイルオーバーする特定のデータベースを選択できるようにしたいだけでなく、すべてをフェイルオーバーできるようにしたいと思います。フェイルオーバーするデータベースを選択できると、テストが簡単になり（顧客のデータベースではなく、テストデータベースをフェイルオーバーできます）、スケーリングの問題が発生した場合に、基本的な負荷分散スキームが提供される可能性があります。また、プライマリとセカンダリの間で「再同期」する自動化された方法が必要になります（プライマリから完全バックアップを取り、それをセカンダリに適用し、tlogフローを開始するなど）。これらの機能は、リリース2.0に適している場合があります。
（MSがサポートした最古のtlog配布は、SQL 7.0でダウンロードして実行できるいくつかのスクリプトによって実装されたことを誰もが忘れていました。GUIがあり、UIはいくつかのSQLレポートといくつかのストアドプロシージャでした。）
小さなtsqlコードを書く以外に、ここでの課題は次のとおりです。
完全復旧モデルへの変更（単純復旧モデルで実行しているように思われます）と、ログバックアップ、データベースサイズの増加、何をしているのかなど、ストレージ使用量の増加。
ストレージシステムが頻繁なtlogバックアップの負荷を処理できることを確認し、それらをタイムリーにDRサイトにコピーします。 IOW、2000のデータベースがあり、最後の1時間までのデータを保証したい場合は、それらの2000のデータベースのそれぞれのトランザクションログバックアップを1つ作成して、ネットワークストレージ（プライマリサーバーにない場所）に保存する必要があります。 ）。
すべてが一般的に追いつくことを確認してください。
これらすべてが機能するようになったら、フェイルオーバーの自動化、特定の顧客のデータベースのライブバージョンが実行されている場所をWebサイトに通知する方法などを検討し始めます。クラスター化されたシステムを実行していない場合は、すべてのログイン/パスワード、ジョブ、リンクサーバーなどの同期を維持することはPITAです。
はい、データベースが破損している可能性があります。これは、ボックスの電源が切れた場合と同じです（「クラッシュの一貫性」があります）。
ただし、データベースエンジンには多くの予防策があります。データベースのデータを変更するたびに、「私は変更を加える」と表示され、次に変更が行われ、「変更を加えた」と表示されます。細分性のレベルは設定方法によって異なりますが、（意図したとおりに）ログを再生することにより、ほとんどの場合、一貫した状態にロールバックできます。
それはあなたがデータを失わないという意味ではありません、それはただそこにあるものが正確であることを意味します。
この状況でおそらく必要なのは（10分程度元に戻せば数千ドルを失うことがないと仮定すると）非同期レプリケーションです（リモートストレージによってデータベースへの書き込みが確認されるのを待たないでください）。 ）。ほとんどの一般的なストレージシステムでは、「X分ごとのスナップショット」と言うだけで設定できます。
最後に、これは100％ではありません。従来のバックアップを作成する必要があります。しかし、それはかなり信頼できます。この設定は非常に一般的であり、データベースだけでなく仮想マシンでもうまく機能します。
詳細については、インテントログ、再生、ログ配布、最高水準点、および整合性チェックポイントを確認してください。
これは間違いなく実行可能です。無料の方法はわかりませんが、 [〜＃〜] this [〜＃〜] を使用します。これにより、基本的にMSSQLボックスで静止できます。次に、3Parアレイにスナップを実行するように指示します。これは本質的にコヒーレントであり、続行します。次に、配列はスナップを取り、必要な数だけ持つことができます。現実的には、24時間程度しか必要ないので、それに基づいてダンプします。無料とは言えませんが、毎回100％機能し、このような目的のために特別に設計されています。 NetAppが類似/同一のことを行うと確信しています-その製品については申し訳ありません。
はい、破損の可能性があります。短いバージョン：クラッシュ後、SQLはトランザクションログを再生してデータの整合性を検証します。ログファイルが破損している場合、データベースは問題ありとしてマークされます。 （もっとあります ここ 。）
レプリケーションに関しては、ログ配布がおそらく最善の策のようです。 30分を失う可能性がある場合は、おそらく（データベースのサイズとデータベースのビジー状態に応じて）、30分のウィンドウで10分ごとに1/3を出荷できます。 （言い換えると、クラッシュした場合、データベースの3分の1が10分、さらに3分の1が20、さらに3分の1が30になります。）
私は似たようなアプリケーションに取り組みました。私たちが偽っていたマルチテナントアプリケーションはマルチテナントではなかったので、顧客ごとに1つのDBがありました。吸い込まれました。
データベースを複数のSQLサーバーに分割して、ミラーリング/複製/ログ配布時にワーカースレッドが不足したり、他のボトルネックの1つに遭遇したりしないようにすることができます。
SQL 2012でAlwaysOnを調べましたが、ワーカースレッドの2008ミラーリングと同じ要件があるようです。そのため、アップグレードしても役に立ちません。
あなたが尋ねているように、あなたはストレージレイヤーレプリケーションを試すことができます。私はそれらについてあまり経験がありません。