6

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

具体来说，我感兴趣的是是否考虑了其他选项/替代方案以及最终选择 P2P 复制的原因。

如果您使用过 P2P 复制：

  • 您在同步过程中是否遇到任何问题，是否易于监控？
  • 解决冲突有多容易？
  • 您是否必须进行架构更改（即替换身份列等）？

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

    4

    1 回答 1

    2

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

    我们将 SQL Server 2005 合并复制设置为在两个活动/活动地理上分离的节点之间进行复制，以实现旧系统中的弹性。

    不知道是否容易监控；在我的职权范围之外。

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

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

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

    使用它是一个巨大的痛苦：

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

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

    于 2008-10-26T15:38:11.977 回答