SQL Server 2005 または 2008 を使用してピア ツー ピア レプリケーションをセットアップした経験のある人はいますか?
具体的には、他のオプション/代替案が検討されたかどうか、および最終的に P2P レプリケーションが選択された理由に興味があります。
P2P レプリケーションを使用している場合:
あるいは、P2P レプリケーションを検討して別のオプションを選択した場合、それを除外したのはなぜですか?
1852 次
1 に答える
2
(免責事項: 私は開発者であり、DBA ではありません)
SQL Server 2005 マージ レプリケーションを設定して、レガシー システムの回復力を確保するために、地理的に離れた 2 つのアクティブ/アクティブ ノード間でレプリケートします。
監視が簡単かどうかはわかりません。私の権限外。
すべてのテーブルにトリガーを作成してパブリッシュ/サブスクライブ メカニズムを実行し、それぞれが独自のストアド プロシージャを呼び出します。
私たちの場合、ノード 0 で ID 1-1bn、ノード 1 で 1bn-2bn を使用して ID の衝突を回避するように設定されました (各テーブルに NodeId + EntityId の複合キーを使用したり、キーを GUID に変更したりするのではなく、例えば）。
レプリケーションの遅延は約 15 秒だと思います (専用帯域幅を使用したロンドンとニューヨークの間)。
で作業するのは大きな苦痛です:
- それをセットアップするのに、高給の請負業者が1年かかりました（確かに、これの一部はDB設計のレガシーな性質によるものでした）
- それをサポートするための専門知識を備えた社内の人材が不足しています (社内の DBA は、それを習得するのに約 6 か月かかり、その後異動しました)。
- スキーマの更新は今や苦痛です。私が理解していることから：
- 特定の更新は、1 つのノードでのみ実行する必要があります。次に、レプリケーションは、他のノードで何をすべきかを考え出します
- 両方のノードで特定の更新を実行する必要があります
- データの更新は 1 つのノードでのみ実行する必要があります (と思います)
- すべての更新の実行にかかる時間が大幅に長くなりました - DDL 変更スクリプトの実行にかかる一瞬から最大 30 分まで
- 確かなことはわかりませんが、レプリケーションに必要な帯域幅は非常に高いと思います (MBit/s の範囲)。
- 多くの「ノイズ」オブジェクト (テーブルごとに 3 つの sprocs、テーブルごとに 3 つのトリガー) が DB に導入され、オブジェクト エクスプローラーで作業したいアイテムを見つけるのが不便になります。
- このシステムに 3 番目のノードをセットアップすることは決してありません。これは主に、展開時に導入されると認識されている困難と追加の苦痛に基づいています。
- また、セットアップに手間がかかるため、本番環境を反映したステージング環境も不足しています。
- 逸話: セットアップを行っている DBA は、自分が強制的に使用しているのが "MS v1" であるという事実を頻繁にののしりました。
- ぼんやりと思い出しました: DBA は、MS から直接支援を受けるために、いくつかの優先サポート チケットを発行する必要がありました。
確かに、関連する問題の一部は、私たちの特定の環境が原因であり、このセットアップをサポートする社内の人材がいないためです. あなたのマイレージは異なる場合があります。
于 2008-10-26T15:38:11.977 に答える