SQL Server复制——概述（一）
最近正好做到SQL Server同步，研究研究SQL Server的复制功能记下文档。
复制引入于SQL Server 2000，首先说明它不是为灾备而设计的功能，其强大之处在于灵活多变的数据同步方式。
一、 复制的组件与基本概念
复制借用了出版业术语表示其组件和概念，包括：
1. 项目(Articles)
被复制的数据库对象。可以是表（可过滤需要同步的列和行）、视图、存储过程等。
2. 发布(Publication)
复制的基本单位，它是DB中一个或多个项目构成的集合(如上图)。 通常我们将逻辑上相关联的对象组合成一个发布，确保被复制内容逻辑一致性。
3. 发布服务器(Publisher)
通过复制向其他服务器提供数据的DB实例（源端），发布服务器可以有一个或多个发布。
4. 分发服务器(Distributer)
服务于一个或多个发布服务器的DB实例， 每个发布服务器都对应分发服务器中的一个数据库（称作分发数据库），分发数据库存储复制的状态信息以及每个发布的元数据。从发布服务器发往订阅服务器的数据会在分发服务器上排队，依次发送。
分发服务器有两种类型：
- 本地分发服务器：一个DB实例既作为发布服务器又作为分发服务器两个角色。
- 远程分发服务器：发布服务器和分发服务器分别位于不同DB实例
5. 订阅(Subscription)
订阅是将发布从分发服务器传递到订阅服务器的请求，它定义了“什么时间、从哪里、得到哪些发布”。
订阅也有两种类型：
- 推送订阅：发布服务器或分发服务器主动将数据更改发送到订阅服务器，无须订阅服务器发起请求。
- 请求订阅：订阅服务器主动请求发布服务器上所做的更改。这种模式下，接收发布的时间是由订阅服务器决定的。
6. 订阅服务器(Subscriber)
订阅服务器是接收复制数据的DB实例（目标端，可以是其他类型的DB），可以接收多个发布服务器的数据。 根据所选的复制类型，订阅服务器还可以将更改复制过来的数据然后传回发布服务器或将数据发布到其他订阅服务器。
二、 复制的类型
需要根据各类复制的特点，结合具体需求选择合适方法。
SQL Server复制有三种基本类型：
1. 快照复制(Snapshot Replication)
顾名思义，相当于给DB打一个瞬时快照，并将这个快照发送到订阅服务器。快照复制是SQL Server中额外维护检查成本最低的一种复制类型。
适合场景：
- DB数据量小
- 订阅服务器只有读需求
- 数据同步实时性要求不强（例如每天一两次）
- 短期内有大量更改
缺点：
- 只能全量复制，复制时间可能较长，IO、网络等资源开销较大
- 快照是静态的，不会监视数据是否变化
2. 事务复制(Transactional Replication)
弥补了快照复制全量同步和数据静态的缺陷，所有数据更改都会以“事务”为单位，按照其在发布服务器上发生的顺序同步到订阅服务器。这是最常用的复制方法。
适合场景：
- DML操作较多
- 订阅服务器只有读需求（标准事务复制有此要求）
- 数据同步实时性要求高
- 订阅服务器上的应用环境需要追踪数据更改的中间状态
- 发布或订阅服务器之一不是SQL Server数据库
缺点：
- 参与事务复制的表必须有主键或唯一索引
- SQL Server中额外维护检查成本较大
为满足更多同步场景，事务复制还可细分为以下类型：
- 对等事务复制(Peer-to-peer)
SQL Server 2005引入，允许多台服务器实例互为发布服务器和订阅服务器，对于彼此间的更新冲突也定义了解决机制
- 双向事务复制(Bidirectional)
允许两台服务器实例互为发布服务器和订阅服务器。在 SQL Server 2005 (9.x) 和更高版本中，对等事务复制也支持此拓扑，但采用双向复制可提高性能。
- 可更新订阅事务复制(Updatable Subscriptions)
可以通过事务复制的“立即更新”或“排序更新”选项实现。使用排队更新选项时，SQL Server在事务复制中引入了第三种代理程序——队列读取器代理(Queue Reader Agent)。队列读取器代理运行于分发服务器，将订阅服务器上所做的更改传回发布服务器（可能造成更新冲突）。此功能在2016版本中仍然受支持，但可能会在将来版本中被删除。
3. 合并复制(Merge Replication)
最大的特点是在发布服务器和订阅服务器上均可写，并把这些修改“合并”成一个统一的结果，还可以通过触发器进行跟踪。 由于两端均可写，在合并更新时可能产生冲突，为此合并复制还提供了多种冲突处理方法。
适合场景（订阅服务器需要各种改数据并将修改合并）：
- 多个订阅服务器可能会在不同时间更新同一数据，并将其更改传播到发布服务器和其他订阅服务器。
- 订阅服务器需要接收数据，脱机更改数据，并在以后与发布服务器和其他订阅服务器同步更改。
- 每个订阅服务器都需要不同的数据分区。
- 多个服务器更改同一数据可能会发生更新冲突，在冲突发生时，您需要具有检测和解决冲突的功能。
- 应用程序需要最终的数据更改结果，而不是访问中间数据状态。 例如，如果在订阅服务器与发布服务器进行同步之前，订阅服务器上的行更改了五次，则该行在发布服务器上仅更改一次来反映最终数据更改（也就是第五次更改的值）。
- 订阅服务器是移动客户端，需要通过web service从发布服务器同步数据
缺点：
- SQL Server中额外维护检查成本最大的复制类型
- 对于其中复杂功能实现，需要在DB设计阶段就规划好在表中如何定义和部署
三、 复制与灾难恢复
一开始就说过复制并不是为灾备而设计的功能，但如果非要用的话，在所有表都有主键或唯一索引的前提下，事务复制是各类复制中最佳的灾备选择。一般来说：
- 同步延迟时间：镜像<事务复制<日志传送
- 资源消耗：日志传送<镜像<事务复制
事务复制其实最适合作为对象级灾备而不是复制整个数据库，例如DB中只有几个表非常重要，或者只有某个表中某些行非常重要。事务复制可以只同步某些对象甚至只同步表中某些行，这是镜像和日志传送包括后来的AlwaysOn都无法达到的功能。
复制作为灾备存在的问题
- 复制只能同步表、存储过程、视图，而不会同步其他数据库对象（例如索引、外键、触发器），仅仅使用复制无法得到一个完整DB
- 不是所有表都能被复制，参与事务复制的表必须有主键或唯一索引
- 复制需要将事务日志内容解析为二进制格式命令写入系统表，然后再将这些命令发送到订阅服务器执行（相当于其他DB的逻辑复制），造成了两次数据传递过程，增加了延迟。
- 复制使用系统表来维护发布对象的变更信息，需要大量的额外开销（如触发器等）来监控数据变更及维护系统表。如果将一个大库所有内容都发布出去，通常你得不偿失。
- 复制需要一个额外的分发服务器，还需要使用不同的代理程序来传送数据，这些都增加了同步开销并使滞后时间更长。
- 分发数据库增加了灾备方案失败和数据损失的可能性。复制非常依赖分发数据库作为数据中转，一旦分发数据库故障而又未启用sync with backup功能，保存在分发数据库中尚未分发出去的数据将全部丢失。另外一旦分发数据库故障，整个复制需要重建，费时费力。
- 订阅数据库数据可靠性不能得到很好的保证。订阅数据库本身不限制写操作，从系统层面无法杜绝订阅数据库更新，只能依靠人为管理和安全措施。
参考
https://docs.microsoft.com/zh-cn/sql/relational-databases/replication/publish/replication-publishing-model-overview?view=sql-server-ver15
《SQL Server 2012实施与管理实战指南》