发布类型
https://www.cnblogs.com/yaopengfei/p/13330482.html
https://www.cnblogs.com/syncnavigator/p/10189543.html
快照发布
- 很少更改数据,更改数据不频繁
- 短期大量数据更新
- 复制的数据量很少(快照本身较小)
- 允许订阅的副本与发布实例存在数据差异(订阅的副本存在数据延迟)
将数据库作为一个整体进行发布,所以数据量小会保证发布和订阅的及时性。另外如果数据库更新较多会造成不能及时同步给订阅节点,造成数据延迟。
快照处理通常用于为事务和合并发布提供初始的数据集和数据库对象。
事务发布
- 数据库增删改的请求较多
- 订阅节点的实时性要求较高
- 发布或订阅服务器不是 SQL Server(例如,Oracle)
- 应用程序需要访问中间数据状态
与 MySQL 复制同步方式类似,同时事务发布订阅服务器应只负责只读类型请求,因更改并不发回发布服务器。 但是,事务复制确实提供了允许在订阅服务器上进行更新的选项。
此方式会对主服务器性能造成很大影响(实时同步每次变更,而不是最终变更),适用于对数据及时性要求比较严格主备方案,但是目前已被微软提供的集群 Always On 所取代。
对等发布
对等发布支持多主复制。发布服务器将事务流式传输到拓扑中的所有对等方。所有对等节点可以读取和写入更改,且所有更改将传播到拓扑中的所有节点。
合并发布
- 多个订阅服务器可能会在不同时间更新同一数据,并将这些更改传播到发布服务器和其他订阅服务器
- 订阅服务器需要接收数据,脱机进行更改,并在随后与发布服务器和其他订阅服务器同步更改
- 每个订阅服务器都需要不同分区的数据
- 可能会发生冲突,并且在冲突发生时,您需要具有检测和解决冲突的能力
- 应用程序需要最终的数据更改结果,而不是访问中间数据状态
快照代理
订阅类型
推送订阅
主数据库数据有变更的时候,会将增量数据脚本主动发给各个从数据库(性能优于请求订阅模式,建议使用)。
请求订阅
从数据库按照既定的周期来请求主数据库,将增量数据脚本获取回去执行,从而实现数据的同步。