SQL Server 2005/08中的對等複製

Question

有沒有人有使用SQL Server 2005或2008設置peer to peer replication的經驗？

具體而言，我對是否考慮其他選項/備選方案以及最終選擇P2P複製的原因感興趣。

如果您使用過P2P複製：

您是否在同步過程中遇到過任何問題，並且很容易監控？

解決衝突有多容易？

您是否必須進行模式更改（即替換標識列等）？

或者，如果您考慮P2P複製並使用其他選項，爲什麼要排除它？

Answer 1

（聲明：我是一個開發者，而不是一個DBA）

我們有SQL Server 2005的合併複製建立在傳統系統中的兩個主動/主動地理上分開的節點之間進行復制的彈性。

我不知道是否容易監控;在我的職權範圍之外。

它在每個表上創建觸發器來執行發佈/訂閱機制，每個機制都調用它自己的存儲過程。

在我們的例子中，它被設置爲使用節點0中的標識符1-1bn，節點1中的1bn-2bn以避免身份衝突（而不是爲每個表使用NodeId + EntityId的組合鍵，或者更改密鑰例如是GUID）。

我認爲複製延遲大約在15秒左右（倫敦和紐約之間的專用帶寬）。

這是一個巨大的痛苦與工作：

• 它採取了高薪合同一年來進行設置（當然，這部分是由於數據庫設計的傳統性質）
• 我們缺乏內部人的專業知識來支持它（內部DBA我們已經花了約6個月的學習它，並從此移動上）
• 架構更新現在痛苦是。據我所知：
  • 某些更新只能在一個節點上執行;然後複製照顧搞清楚到其他節點（S）
  • 某些更新必須在兩個節點
  • 數據更新必須在一個節點上只能執行（我認爲）
  • 所有更新的現在進行的怎麼辦需要更長的時間來執行 - 從分秒需要運行一個DDL更改腳本到約30分鐘
• 我不知道肯定，但我認爲複製的帶寬要求非常高（在MBit/s範圍內）
• 它引入了很多個「噪聲」對象（每個表格有3個sprocs，每個表格有3個觸發器）插入到數據庫中，這使得在對象瀏覽器中找到想要處理的項目不方便。
• 我們將從來沒有爲這個系統建立第三個節點，很大程度上基於感知的難度和它在部署時引入的額外痛苦。
• 我們現在還缺少反映生產的臨時環境，因爲設置起來太痛苦。
• 軼事：做DBA的設置經常會詛咒這個事實，那就是他被迫與之合作的「MS v1」。
• 記憶猶新：DBA需要提出幾個優先支持票才能直接從MS獲得幫助。

授予 - 一些所涉及的痛苦是由於我們的具體環境，而沒有內部人才來支持這種設置。你的旅費可能會改變。