SQL Server 2005/08中的对等复制

Question

有没有人有使用SQL Server 2005或2008 建立对等复制的经验？

具体来说,我对是否考虑其他选项/备选方案以及最终选择P2P复制的原因感兴趣.

如果您使用过P2P复制:

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

解决冲突有多容易？

您是否必须进行架构更改(即替换标识列等)？

或者,如果您考虑使用P2P复制并使用其他选项,为什么要将其排除在外？

Answer 1

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

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

不知道是否方便监控；超出我的职权范围。

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

在我们的例子中，它被设置为在节点 0 中使用身份 1-10 亿，在节点 1 中使用 10 亿-20 亿身份，以避免身份冲突（而不是为每个表使用 NodeId + EntityId 的复合键，或将键更改为 GUID，例如）。

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

与以下人员一起工作是一个巨大的痛苦：

• 一个高薪承包商花了一年的时间来设置它（当然，部分原因是数据库设计的遗留性质）
• 我们内部缺乏任何具有专业知识的人来支持它（我们的内部 DBA 花了大约 6 个月的时间来学习它，并且已经离开了）
• 架构更新现在很痛苦。据我了解：
  • 某些更新必须仅在一个节点上执行；然后复制负责弄清楚在其他节点上做什么
  • 必须在两个节点上执行某些更新
  • 数据更新必须仅在一个节点上执行（我认为）
  • 现在，所有更新的执行时间都显着延长 - 从运行 DDL 更改脚本所需的瞬间增加到约 30 分钟
• 我不确定，但我认为复制的带宽要求非常高（在 MBit/s 范围内）
• 它在数据库中引入了许多“噪音”对象（每个表 3 个存储过程，每个表 3 个触发器），使得在对象资源管理器中查找想要处理的项目变得不方便。
• 我们永远不会为这个系统设置第三个节点，主要是因为在部署时会带来困难和额外的痛苦。
• 我们现在还缺乏一个反映生产的临时环境，因为设置起来太痛苦了。
• 轶事：进行设置的 DBA 经常会咒骂他被迫使用的是“MS v1”这一事实。
• 依稀记得：DBA需要提出几张优先支持票才能直接得到MS的帮助。

当然，所涉及的一些痛苦是由于我们的特定环境以及没有内部人才来支持这种设置造成的。你的旅费可能会改变。