SQL SERVER 之快照复制,事务复制,合并复制
一、环境要求及说明
1、快照复制和事务复制是单向的(2005及以后的版本中加入了订阅端可更新的事务复制)。
2、合并复制是双向的。
3、快照复制对表结构没有要求。
4、事务复制要求表有主键。
5、合并复制要求表有 rowguid 列。
-------------------------------------------------------
快照复制
1、概念
快照复制是完全按照数据和数据库对象出现时的状态来复制和分发它们的过程。
快照复制不需要连续地监控数据变化,因为已发布数据的变化不被增量地传播到订阅服务器,而是周期性的被一次复制。
2、 适用情况
• 数据主要是静态的,比如将数据仓库复制到数据集市中
• 一段时间内允许有已过时的数据拷贝的情况
• 小批量数据
• 站点经常脱离连接,并且可接受高延迟
事务复制
1、概念
使用事务复制,初始快照数据将被传播到订阅服务器,因此该订阅服务器就具有了一个所谓的初始负载,这是可以开始工作的内容。
当出版服务器上发生数据修改时,这些单独的事务会被及时捕获并复制到订阅服务器。并保留事务边界,当所有的改变都被传播后,所有订阅服务器将具有与传播服务器相同的值。
2、适用情况
• 需要数据修改经常在其发生的几秒钟内被传播到订阅服务器
• 需要事务是原子性的
• 订阅服务器在通常是连接到出版服务器上的
• 应用程序不能忍受订阅服务器接收改变的高延迟
合并复制
1、概念
合并复制允许一组站点自治工作,在线或离线。然后在将来的某个时刻,数据按照在多个已复制站点上发生的修改或插入情况被合并成一个统一的结果。
在订阅服务器上应用初始快照,作为其初始负载,然后SQL Server跟踪在出版服务器上和订阅服务器上已发布数据的更改。
数据按照预先定义或调度的时间,或者按需在服务器间同步。然后更新被独立应用在多个服务器上。
这意味着相同的数据可能由出版服务器或多个订阅服务器进行了更新,因而当数据更新合并时将发生冲突。
2、适用情况
• 多个订阅服务器需要在不同时刻更新数据,并将这些数据传播到出版服务器和其他订阅服务器。
• 订阅服务器需要接收数据,脱机更改数据,然后将更改同步到出版服务器和其他订阅服务器
• 应用程序的延迟需求可高可低
• 站点的自治性很关键
--------------------------------------------------------
事务复制
• 将复制启用后的所有发布服务器上发布的内容在修改时传给订阅服务器;
• 数据更改将按照其在发布服务器上发生的顺序和事务边界,应用于订阅服务器;
• 在发布内部可以保证事务的一致性;
快照复制
• 将数据以特定时刻的瞬时状态分发,而不监视对数据的更新;
• 发生同步时,将生成完整的快照,并将其发送到订阅服务器;
合并复制
• 通常从发布数据库对象和数据的快照开始,并且用触发器跟踪在发布器和订阅服务器上所做的后续更改和架构修改;
• 订阅服务器在连接到网络时将与发布服务器进行同步,并交换自上次同步以来发布服务器和订阅服务器之间发生更改的所有行;
【推荐】国内首个AI IDE,深度理解中文开发场景,立即下载体验Trae
【推荐】编程新体验,更懂你的AI,立即体验豆包MarsCode编程助手
【推荐】抖音旗下AI助手豆包,你的智能百科全书,全免费不限次数
【推荐】轻量又高性能的 SSH 工具 IShell:AI 加持,快人一步
· 如何编写易于单元测试的代码
· 10年+ .NET Coder 心语,封装的思维:从隐藏、稳定开始理解其本质意义
· .NET Core 中如何实现缓存的预热?
· 从 HTTP 原因短语缺失研究 HTTP/2 和 HTTP/3 的设计差异
· AI与.NET技术实操系列:向量存储与相似性搜索在 .NET 中的实现
· 周边上新:园子的第一款马克杯温暖上架
· Open-Sora 2.0 重磅开源!
· 分享 3 个 .NET 开源的文件压缩处理库,助力快速实现文件压缩解压功能!
· Ollama——大语言模型本地部署的极速利器
· DeepSeek如何颠覆传统软件测试?测试工程师会被淘汰吗?