SQL Server 2005/08でのピアツーピアレプリケーション

Question

ピアツーピアレプリケーションのセットアップの経験がありますか SQL Server 2005または2008を使用していますか

具体的には、他のオプション/代替案が検討されているかどうか、そして最終的にP2Pレプリケーションが選択された理由に興味があります。

P2Pレプリケーションを使用した場合：

同期中に問題が発生しましたが、監視は簡単でしたか？

競合の解決はどれほど簡単でしたか/そうですか？

スキーマの変更（ID列の置換など）が必要ですか？

別の方法として、P2Pレプリケーションを検討し、別のオプションを使用した場合、なぜそれを除外したのですか？

Answer 1

（免責事項：私はDBAではなく開発者です）

レガシシステムの復元力のために、地理的に分離された2つのアクティブ/アクティブノード間でレプリケートするように、SQL Server 2005マージレプリケーションがセットアップされています。

監視が簡単かどうかわかりません。私の権限外。

すべてのテーブルにトリガーを作成してパブリッシュ/サブスクライブメカニズムを実行し、それぞれが独自のストアドプロシージャを呼び出します。

この場合、ノード0のID 1-1bn、ノード1の1bn-2bnを使用してIDの衝突を回避するように設定されました（各テーブルにNodeId + EntityIdの複合キーを使用するか、 GUIDなどです）。

レプリケーションの遅延は約15秒です（ロンドンとニューヨーク間で専用帯域幅を使用）。

連携するのは非常に苦痛です：

• 高額な請負業者がセットアップするのに1年かかりました（このことの一部はDB設計のレガシーな性質によるものでした）
• サポートする専門知識を持つ社内の人材が不足しています（社内のDBAが習得するまでに約6か月かかりましたが、その後に移行しています）
• スキーマの更新は痛みを伴うになりました。私が理解していることから：
  • 特定の更新は1つのノードでのみ実行する必要があります。その後、レプリケーションが他のノードで何をすべきかを判断します。
  • 特定の更新は両方のノードで実行する必要があります
  • データの更新は1つのノードでのみ実行する必要がある（私は思う）
  • すべての更新の実行に非常に長い時間がかかるようになりました-DDL変更スクリプトを実行するのにかかる時間がわずか30秒から約30分
• 確かではありませんが、レプリケーションの帯域幅要件は非常に高いと思います（MBit / sの範囲）
• 多くの＆quot;ノイズ＆quot;オブジェクト（テーブルごとに3つのsproc、テーブルごとに3つのトリガー）をDBに追加し、オブジェクトエクスプローラーで作業したいアイテムを見つけるのは不便です。
• このシステム用に3番目のノードをセットアップすることは、決してはありません。主に、展開時に導入されると思われる難しさと追加の痛みに基づいています。
• また、本番環境をミラーリングするステージング環境が不足しています。セットアップするのが大変すぎるためです。
• 逸話：DBAがセットアップを行うと、「MS v1」であるという事実が頻繁に呪われます。彼は働くことを余儀なくされていました。
• 記憶に残っている：DBAは、MSから直接サポートを受けるために、いくつかの優先サポートチケットを上げる必要がありました。

許可済み-関係する痛みの一部は、特定の環境にあり、このセットアップをサポートする社内の才能がないためです。走行距離は異なる場合があります。