在本系列文章的前两篇对高可用性的意义和单实例下的高可用性做了阐述。但是当随着数据量的增长，以及对RTO和RPO要求的严格，单实例已经无法满足HA/DR方面的要求，因此需要做多实例的高可用性。本文着重对SQL Server的复制进行阐述。
复制?
复制起初并不是用于作为高可用性功能而设计的，实际上复制的概念就像其名称一样，用于复制数据。比如将某个库中的数据“复制”到另一个库，到另一个实例中，由OLTP复制到OLAP环境中，由某数据中心复制到位于地球另一侧的另外一个数据中心中。因此，由于复制所提供的功能，复制可用被用来剥离负载，用于做数据冗余，直至把复制用于作为高可用性拓扑中的一个环节。（切记，复制的功能可以被用做高可用性，而不是复制是高可用性功能。）
不同于其它SQL Server可以被用作高可用性的特性，复制可以做的非常灵活。您可以复制某些列，过滤某些行，复制表中的部分数据。复制是基于数据库对象的，而不像日志传送、镜像、集群、AlawysOn等需要以库和实例作为基本对象，此外更新的订阅还允许订阅端合并数据，没有任何一种其它的高可用性技术能做到这一点。
复制的基本概念
关于复制的基本概念，我在之前已经有一篇文章进行了阐述：http://www.cnblogs.com/CareySon/archive/2012/06/20/IntroductToSQLServerReplicationPart1.html。但这里我还是想再次对基本的概念进行阐述。
复制的模型参考的杂志发布的模型，由出版社发型杂志，由经销商分发杂志，由订户来消费这些杂志。这个概念看似简单，但可以归结出复制下面一些特点：
- 杂志社是否大，比如说全国发行的杂志需要总代理（单独分发服务器），而一个机关内部发型的文章直接在杂志社（发布服务器和分发服务器在同一台服务器）消费
- 是由订户去经销商自取（订阅服务器去分发服务器请求订阅），还是由经销商送到订户那里（分发服务器推送到订阅服务器）
- 是一次性订阅一本书（快照发布），还是每当有新的文章后就发给订户（事务订阅）
- 杂志会首先到达经销商那里，然后再给订户（数据会在分发服务器那里转存，一定时间过后，则丢弃暂存的数据）
- 经销商保留多久就处理掉过期期刊（分发服务器数据保留时间）
- 出版社不可能仅仅将杂志发布给某个订户看，而是会给多个订户看（一个发布可以允许多个订阅，但要考虑性能问题）
- 从出版社发型文章到经销商再到订户需要一定时间（发布服务器到分发服务器到订阅服务器可能存在5秒10秒15秒等延迟，因此事务复制不能用于做热备，只能用于做冷备和暖备）
- 出版社到经销商到订户中间可能存在杂志丢失的问题，原因可能是由于出版社的问题，快递的问题，经销商的问题，由于环节比较多，不太容易找出问题（复制相对难以调错）
复制的几种类型
下面来简单介绍几种复制类型在高可用性中可以作为的角色。
快照发布
快照复制本质上就是通过快照目录(共享目录)共享一堆文件(因为需要多个订阅端共享)，在早起版本,快照复制仅仅是一个文件，而相对更新的版本，复制会将文件分为多个。快照就是文章某一时间点发布的Article
是一种创建报表数据库的好方式。
对于快照复制的简单概念，如图1所示。
图1.快照发布的概念
事务复制
在初始化订阅后（可通过快照初始化，或者由备份初始化，请参阅：http://www.sql-server-performance.com/2012/replication-without-creating-snapshot/），由发布服务器上将需要被复制的部分的日志标记为复制.由分发服务器的log reader agent来读取发布服务器上这部分日志,当分发服务器将所有的日志传递给订阅服务器，则发布服务器上的日志就可以清空了
通过原理不难看出,每个数据库只能有一个log reader agent,因此数据库中发布内容过多，或者重复发布，则会产生严重的性能问题。此外log reader agent需要读取所有的日志，不会有任何奇迹发生来跳过那些没有被标记为复制的日志.因此当对复制的文章进行了筛选的话，会影响性能(这里可不像索引,设置了筛选条件能够提高查询速度)。
性能因素取决于很多地方,发布服务器的速度，更改频率，分发服务器的速度等等。
通常可以用于做实时报表，虽然会有些许延迟，但效果非常好。
合并复制
合并复制可以实现数据的多处更新，当更新冲突时，可以设置规则，比如北京和上海的服务器，我可以设置北京的服务器永远赢。
Peer-To-Peer复制
P2P复制是基于事务日志之上的一种复制类型，他允许每个节点都成为对等的实体。因此可以非常好的用于HA和负载均衡，即使某一个节点宕机，完全不会影响其它节点的可用性。
自SQL Server 2012以来，PeerToPeer复制已经成为了一种单独的发布类型。
一个Peer-To-Peer的简单例子如图2所示。
图2.对等复制
从图2中可以看出，节点A、B、C、D分别对同一份数据保存相同的副本，并且每个节点上都可以进行读写操作。我们可以假设每个节点都是在不同的地理位置，因此假如说节点A宕机，则可以直接将应用程序连接字符串重定向到其它节点，实现了高可用性。从图2中还可以看出，对于任一节点我们都可以进行读写操作，因此实现了负载均衡的效果。此外，NodeB进一步将数据发布到只读服务器上，进一步实现了读写分离。
因此，这种方式具有极大的灵活性，和其它高可用性技术结合可以实现多种数据库拓扑。
在SQL Server 2008之后的版本，当遇见数据更新冲突时，可以通过冲突查看器进行查看并解决冲突，还可以在数据更新冲突出现后，进行报警。
为什么选用复制
每一种高可用性技术都有其自身的优点和缺陷，如果某种技术相较与其它技术只有有点，没有缺陷，那”其它技术“一定会被淘汰。
相比较其它高可用性技术而言，复制有如下好处：
- 复制是对象级别，您可以仅复制您需要复制的内容
- 复制可以工作在简单恢复模式下。
- 您可以拥有无限多个订阅（日志传送也可以实现，但要考虑到网络带宽和性能问题，通常来说，订阅数量稍微多一点就要考虑请求订阅，将Distribution Agent的负载OffLoad到订阅服务器）
- 复制允许在高可用的另一端（也就是用于冗余的一端）进行更新，没有其它高可用性技术可以做到这一点
- 在故障转移的时候，不需要Redo或Rollback日志，只需要将应用重定向到仍然在线的节点
但同样，复制也有其自身局限性，比如：
- 复制建立、调错都相对比较复杂
- 复制是对象级别（没错，这一点既可以是优势，同样也是劣势，基于不同的场景）
- 分发库上不能建立镜像，因此分发库有可能成为Single-Point-Of-Failure
- 复制很容易影响发布服务器的性能
- 不能进行热备，这意味着就不能进行故障检测和故障排除
- 对于复制来说，故障转移容易，想转移回来就比较麻烦，因此这种情况下可以考虑P2P复制
但不得不说，复制的确是非常的强大，套用京东“首席DB Replicationor(自造词)”陈璟的话说就是：“想复制什么复制什么，想复制多远复制多远，想怎么复制就怎么复制，想复制的多复杂就多复杂”，同时结合其它技术可以实现很多有意思的拓扑，比如图3（同样来自陈璟同学）。
图3.利用复制分发写数据，同时实现高可用性
通过图3这种方式，分发了写压力，同时相同的读库实现了负载均衡以及高可用性，当某个读库宕机后，会有足够的时间进行修复。
小结
本篇文章对复制在高可用架构的角色做了一个概述。复制作为高可用性中最为灵活的技术，与其它技术结合，可以实现很多有意思的拓扑。