トランザクションレプリケーションについてさらに追加するには：
- sQLエージェントログリーダージョブを使用して、パブリケーションデータベースのトランザクションログからコミットされたトランザクションを収集します。これは、ログレコードが読み取られるまでログをクリアできないことを意味します。ログリーダーエージェントの周期が変更されると、ログが予期せず大きくなる可能性があります。もちろん、ログリーダーエージェントは、OLTPサブシステムによっては、大量のIOシステムで、トランザクションログで競合を引き起こす可能性があります。
- ログレコードを読み取り、ディストリビューターを介してサブスクライバーに渡すのに遅延が発生するため、レプリケーションはデータ損失がゼロであることを保証しません。データ損失がゼロの場合は、同期データベースミラーリングまたは同期SANレプリケーション
- ピアツーピアレプリケーションは、クエリワークロードをスケールアウトするための優れた方法であり、データに冗長性を追加することもできます。
- 異なるノードでの同様の変更によって引き起こされる衝突を回避するために、ピアツーピアで注意深いスキーマ設計を行う必要があります。そのためにパーティション化されたIDを使用しないでください。複合代理キーを使用する（例：ノード識別子+ bigint）
- ピアツーピアでは、トポロジ内のさまざまなノードに冗長性を追加するのが難しい場合があります。パブリッシャーはミラーリングでき、サブスクライバーはミラーリングできますが（2008年にはかなり簡単に、2005年にはそれほど簡単ではありません）、ディストリビューターはミラーリングできません。冗長性を追加するには、クラスター化する必要があります。
ほんの少しの考え。また、昨年私が書いたミラーリング+ replに関するホワイトペーパーをチェックアウトすることもできます http://download.Microsoft.com/download/d/9/4/d948f981-926e-40fa-a026-5bfcf076d9b9/ReplicationAndDBM.docx
編集：わかりました-ランチタイムです。追加するものがいくつかあります。
- ピアツーピアレプリケーション：2005年にトポロジを変更する（ノードを追加または削除する）場合は、トポロジ全体を静止する必要があります。 2008年には、そうする必要はありません。
- ピアツーピアレプリケーションでは、2008年まで競合が検出されませんが、それでも競合の解決はかなり頭がおかしくなります。IDが最も高いノード（ピアオリジネーターIDと呼ばれます）が優先されます。おそらく、必要なものではありません。
- ピアツーピアレプリケーション：すべてのノードは、他のノードからのすべての変更を確認します。これは、たとえば、シアトル、ロンドン、東京の3ウェイトポロジでは、シアトルがダウンしても、ロンドンと東京は継続することを意味します。その後、東京がダウンしてシアトルがオンラインになると、ロンドンからすべてのロンドンの更新が取得され、ロンドンが知っているすべての東京の更新がロンドンから取得されます。かなりきちんと。
- 障害検出やレプリケーションによる自動フェイルオーバーの形式はありません。代わりにミラーリングを見てください。なんらかの形のNLBを使用できると思います。
あらゆる種類のHAソリューションを選択する場合（今日、社内のMicrosoft DBAのHAクラスを教えているので、タイミングが良い）、テクノロジを評価する前に、要件分析から始める必要があります。すべての要件を知らずに推奨事項を提示するのは少し難しいです。
HA戦略を考え出すときに自問する質問についてブログに書きました。 http://www.sqlskills.com/BLOGS/PAUL/post/HA-Where-do-you-start-when-choosing-を参照） a-high-availability-solution.aspx
もう一度編集します。
- その使用例：中間層の負荷分散を備えたデータ層のさまざまなサーバー。ピアツーピアにより、すべてのノードが（最終的に）同期を維持できます。
- ただし、厄介な問題：ユーザーがノード1にルーティングされてトランザクションを実行する場合、データが他のノードに複製されるまでにどのくらいの時間がかかりますか？ユーザーがサービスに再度接続する場合、どのノードにルーティングしますか？以前と同じノード、または任意のノードに安全にルーティングし、彼女が行った前のトランザクションがすべてのノードに複製されたことを保証するのに十分な時間が経過しましたか？
わかりました-これ以上の編集はありません！ :-)
レプリケーションは非常に多様なテクノロジーであり、さまざまなシナリオに対応するために使用できます。その選択によって、実装されるレプリケーションの特定のタイプが決まります。
たとえば、マージレプリケーションを使用して、アプリケーションのワークロードを複数のサーバー、つまり分散処理アーキテクチャに分散させることにより、分散処理をサポートできます。
マージレプリケーションでは、多くの場合、その環境を比較的認識しているアプリケーションが必要です。統合環境全体でデータの整合性を確保するには、競合解決などの手法も考慮する必要があります。
トランザクションレプリケーションは、ログ配布と同様の方法で使用できますが、サブスクライバーにレプリケートされる特定のオブジェクトを制限できます。これは、レポートの目的でテーブルのサブセットのみが必要な場合に役立ちます。
使用可能なアーキテクチャの完全なリストについては、次のMicrosoftReplicationリファレンスを参照してください。
http://msdn.Microsoft.com/en-us/library/ms151827.aspx
使用するレプリケーションのフレーバーによって、発生する可能性があり、考慮する必要のある問題のタイプが決まります。たとえば、マージレプリケーションでは、データベースにスキーマの変更を加える必要があります。
データをパブリックインターネット経由で複製する場合や、通信を暗号化する必要があるかどうかなど、考慮すべきセキュリティ上の考慮事項もあります。
レプリケーションは大きなトピックですが、この情報が正しい方向にあなたを導くことを願っています。
何らかの理由でレプリケーションを停止して再起動する必要がある場合（または、最初に起動したばかりの場合）、処理中に両方のサーバーがほとんど応答しなくなる傾向があります。一度起動して実行すると（そしてそのままにしておくと）、それは目立ちません（少なくとも私たちにとっては）。