【问题标题】:Where Merge Replication actually stores data?合并复制实际存储数据的位置在哪里?
【发布时间】:2018-11-07 12:08:32
【问题描述】:

我读过一些非官方的文章说合并复制实际上将数据存储为事务并将它们复制为事务。但是在 MSDN 或任何我能接触到的官方来源上都没有关于这方面的官方信息。

拜托,有人能帮我说清楚吗?如果它存储交易 - MSMerge_contents 中是否有任何链接到相应交易?它怎么会像here 所说的那样过滤插入/更新/删除?

如果它不复制事务,它会将实际数据存储在哪里以进行复制?

我个人认为合并复制不使用事务日志来存储数据。

表触发器(MSmerge 触发器)将每个事务转换为增量生成信息,并将该信息存储在系统元数据表 MSmerge_contents、MSmerge_tombstone 和 MSmerge_genhistory 中,您可以在其中通过 tablenick 连接每个表并使用 rowguid 列查找行(用于 MSmerge_contents 和 MSmerge_tombstone) .

Replication Agent 为发布者和订阅者比较 MSmerge_contents 的内容,它复制新行并根据 rowguid 列和每行的代号更改现有行。它使用实际表中的实际行,通过 rowguid 连接。 MSmerge_tombstone 表也是如此。

它不使用事务日志。它甚至没有激活日志阅读器。

【问题讨论】:

标签: sql-server merge-replication


【解决方案1】:

合并复制或任何类型的复制总是从快照初始化的初始步骤开始,在发布者上创建所有数据和对象的快照并发送给所有订阅者。 (在这一步中,实际数据从发布者转移到订阅者)。

事务复制

一旦初始快照交付给订阅者,SQL Server 会从发布者读取交易日志并将其推送到分发者,然后分发者发送(或订阅者拉取,取决于订阅者的类型)日志到所有订户。这些日志通过触发器和一些元数据表在订阅者上重放。

合并复制

在合并复制中将初始快照交付给订阅者后,SQL Server 开始从发布者和所有订阅者读取事务日志并将它们发送到合并代理(此代理仅特定于合并复制,它不存在于任何其他类型的复制中),Merge Agent 使用特定的算法来整理应用插入/更新/删除的顺序(通常首先是删除,然后是更新,最后是应用插入)到所有参与的订阅者和发布者,一旦合并代理整理了订单,日志就会像事务复制一样在分发者上排队,并被推送/拉到订阅者。

数据移动只发生在第一步(快照初始化),之后就是日志和代理移动和同步数据。我希望这有帮助。

【讨论】:

  • 那么Merge table triggers for Merge Replication的目的是什么?他们维护 Merge Agent 对操作进行排序的顺序?如果一个事务有插入和删除 - 是否会对 thouse 操作进行排序以及合并代理将如何中断该事务以对 thouse 操作进行排序?
  • 我改变了我的问题 - 添加了“我自己的意见”部分。
  • @SergeyLobanov 我认为您帖子中的意见部分是合并复制的工作原理。我认为你说得对。
猜你喜欢
  • 1970-01-01
  • 1970-01-01
  • 2020-11-08
  • 1970-01-01
  • 1970-01-01
  • 2015-01-22
  • 1970-01-01
  • 1970-01-01
  • 2016-06-17
相关资源
最近更新 更多