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 获得帮助。

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