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个月的时间来学习它，并且后​​来继续前进）。
• 架构更新现在痛苦。据我所知：
  • 必须仅在一个节点上执行某些更新;复制然后负责确定在其他节点上做什么
  • 必须在两个节点上执行某些更新
  • 数据更新必须仅在一个节点上执行（我认为）
  • 所有更新现在需要更长时间才能执行 - 从运行DDL更改脚本所需的分秒到~30分钟
• 我不确定，但我认为复制的带宽要求非常高（在MBit / s范围内）
• 它在数据库中引入了许多“噪声”对象（每个表3个sprocs，每个表3个触发器），这使得在对象资源管理器中找到想要处理的项目变得不方便。
• 我们将从不为此系统设置第三个节点，主要基于在部署时会产生的感知难度和增加的痛苦。
• 我们现在还缺少一个反映生产的临时环境，因为设置起来太痛苦了。
• 轶事：进行设置的DBA经常会诅咒这是他被迫使用的“MS v1”这一事实。
• 朦胧地记得：DBA需要提出几张优先支持票，以便直接从MS获得帮助。

当然 - 所涉及的一些痛苦是由于我们特定的环境而没有内部人才来支持这种设置。您的里程可能会有所不同。