Sql server SQL Server 2005/08中的对等复制

有没有人有过使用SQLServer2005或2008进行设置的经验

具体而言，我感兴趣的是是否考虑了其他选项/替代方案，以及为什么最终选择了P2P复制

如果您使用过P2P复制：

您在同步过程中是否遇到任何问题，是否易于监控

解决冲突有多容易

您是否必须更改架构（即替换标识列等）？

或者，如果您考虑了P2P复制，并选择了不同的选项，为什么要排除它呢？

（免责声明：我是开发人员，不是DBA）

我们已将SQL Server 2005合并复制设置为在两个活动/活动的地理位置上分离的节点之间进行复制，以实现遗留系统中的恢复能力

我不知道监控是否容易；超出我的职权范围

它在每个表上创建触发器来执行发布/订阅机制，每个机制都调用自己的存储过程

在我们的例子中，它被设置为在节点0中使用标识1-1bn，在节点1中使用标识1-2bn以避免标识冲突（而不是为每个表使用NodeId+EntityId的复合键，或者将键更改为GUID）

我认为复制延迟大约为15秒（在伦敦和纽约之间，通过专用带宽）

与之共事是一种巨大的痛苦：

• 一位高薪承包商花了一年时间才完成了安装（当然，部分原因是DB设计的遗留性质）
• 我们内部缺少任何具有支持它的专业知识的人（我们花了约6个月的时间学习它的内部DBA，并从那时起继续学习）
• 架构更新现在是痛苦的。据我所知：
  • 某些更新只能在一个节点上执行；然后，复制负责确定在其他节点上执行的操作
  • 必须在两个节点上执行某些更新
  • 数据更新只能在一个节点上执行（我认为）
  • 现在，所有更新都需要更长的时间来执行—从运行DDL更改脚本所需的瞬间到大约30分钟
• 我不确定，但我认为复制的带宽要求非常高（在MBit/s范围内）
• 它在数据库中引入了许多“噪波”对象（每个表3个存储过程，每个表3个触发器），使得在对象资源管理器中查找要处理的项变得不方便
• 我们绝不会为这个系统设置第三个节点，这主要是基于部署时可能带来的困难和额外的痛苦
• 我们现在还缺少一个镜像生产的暂存环境，因为设置起来太麻烦了
• 轶事：进行设置的DBA经常会诅咒这是一个他被迫使用的“MSV1”
• 模模糊糊地记得：DBA需要提出几个优先支持票证，以便直接从MS获得帮助

---

诚然，其中一些痛苦是由于我们的特定环境和没有内部人才支持此设置。您的里程可能会有所不同。

（PTP复制与合并复制无关。它与transactionnel rep配合使用，其中所有服务器都是发布者/订阅者）。我对你们关于合并复制、模式更新和带宽问题的评论感到非常惊讶。您能确认一下吗，或者这些只是您听到的事情吗？这些是我必须在凌晨5点使用衰退期部署期间帮助解决的问题。（感谢您澄清了PTP与合并复制的区别；我没有意识到它们是两件不同的事情。）Rob-您是否设置过点对点复制，或者获得了更好的响应（Peter的响应涉及到他使用合并复制的经验，而不是P2P）不幸的是，没有！我真的很想获得反馈/经验，因为我还没有在生产环境中看到P2P复制。