方法：別のデータセンターのホットスタンバイSQL Server？
SaaSアプリの場合、データセンター全体の障害に備えてシステムを導入したいと考えています。
メインのデータセンターには、MSSQLデータベースミラーリング（同期）を使用してセットアップされた2つのサーバーがあります。これにより、サーバー障害に対して十分な高可用性ソリューションが提供されます。サーバーが停止した場合、数秒以内に（3番目の監視サーバーの助けを借りて）自動的にフェイルオーバーします。
ミラーリングされたデータベースからMSSQLレプリケーションまたはログ配布を使用してウォームスタンバイサーバーを別のデータセンターに維持することを考えていました-これは大西洋を横断することに注意してくださいしたがって、高pingは約100msです。私はいくつかのDNSフェイルオーバー短い（5分）TTL）サービスを使用できると思います。これにより、最初のデータセンターに障害が発生した場合にトラフィックが2番目のデータセンターに転送されます。 。
質問：
ミラーリングされたデータベースからのレプリケーションまたはログ配布を使用できますか（他のインスタンスにフェイルオーバーした場合、シームレスに機能します）？
どちらが優先されますか？レプリケーションまたはログ配布または他の何か？
フェイルオーバーデータベースに書き込みを受け入れさせることは可能ですか？
または、フェイルオーバーによってデータが失われる可能性があるため、メインのデータセンターにフェイルバックするまでこれを読み取り専用にするのが最善でしょうか。
ありがとう！
編集：スタンバイMSSQLサーバー構成について何かアイデアはありますか？
ログ配布またはレプリケーションのいずれかがDBミラーリングで機能します-どちらを使用するかは要件によって異なりますが、レプリケーションはログ配布よりもセットアップと管理が難しい場合があるため、個人的には、レプリケーションの機能がない限り、ログ配布を使用します本当に必要。以下のリンクは、それぞれを設定する方法の詳細を示しています。
フェイルオーバーデータベースに書き込みを受け入れさせることは可能ですか？
注：日常の通常の操作ではなく、フェイルオーバーが発生したことを意味すると思います。
確かに、ログ配布を使用すると、セカンダリにフェイルオーバーデータベースを配置することができますDC書き込みを受け入れます。プライマリで実行されているデータベースのテールログバックアップを取得して適用できる場合DC（データ損失を最小限に抑え、ログチェーンを完全な状態に保つため）、データベースの最新のコピーを実行しますが、ただしこの状況で公開されていることを忘れないでください。定期的なログバックアップが役立つ場合がありますが、トランザクションを失うことが目標でない場合は、他のDCのログ配布セカンダリのみで実行している場合は保証できません。 HAが再度セットアップされるまで、アプリケーションを読み取り専用状態で実行するだけです。この状態から、ログバックアップをプライマリデータセンターにコピーしてから、ミラーリングを再初期化できます。
便利なリンク：
http://msdn.Microsoft.com/en-us/library/ms187016.aspx -ログ配布とデータベースミラーリング http://msdn.Microsoft.com/en-us/ library/ms151799.aspx -レプリケーションとデータベースのミラーリング
注：ログシッピングデータベースへの書き込みアクセスを取得するには、DATBASE dbnameをリカバリで復元する必要があります。その後、マスターのように書き込むことができますが、これを行った後は追加のログを復元できません。ログシッピングを再び機能させるには、新しい完全バックアップを復元する必要があります。しかし、少なくともそれはあなたがそれにフェイルオーバーすることを可能にするでしょう。
私は、世界中ではなく、米国全体で、似たようなものの計画段階にあります。ログシッピングを予定しています。 （少なくとも私にとっては）レプリケーション（私が使用した）よりも堅牢で、管理が簡単で、セットアップがはるかに簡単であるように見えます（少なくとも私にとっては）。
長所/短所 のクイックリストは次のとおりです。私たちにとって最大の欠点は、ミラーリングのような自動フェイルオーバーがないことです。
通常、あなたは良いルートを進んでいますが、次のことを考慮してください。
- DNSキャッシングと
- tTLを尊重しない特定のサーバー
これらが、これによってHAの増加が制限される理由です。 24時間までのキャッシングは珍しいことではありません。フェイルバックも特定のクライアントに伝播するのに24時間かかるため、プライマリサイトが長期間影響を受ける場合にのみ実行したいので、これはよりDRアプローチであることをお勧めします。