SQLServer中的高可用性（3）----复制

在本系列文章的前两篇对高可用性的意义和单实例下的高可用性做了阐述。但是当随着数据量的增长，以及对RTO和RPO要求的严格，单实例已经无法满足HA/DR方面的要求，因此需要做多实例的高可用性。本文着重对SQL Server的复制进行阐述。 复制? 复制起初并不是用

&＃160;&＃160;&＃160; 在本系列文章的前两篇对高可用性的意义和单实例下的高可用性做了阐述。但是当随着数据量的增长，以及对RTO和RPO要求的严格，单实例已经无法满足HA/DR方面的要求，因此需要做多实例的高可用性。本文着重对SQL Server的复制进行阐述。

&＃160;

&＃160;&＃160;&＃160; 复制起初并不是用于作为高可用性功能而设计的，实际上复制的概念就像其名称一样，用于复制数据。比如将某个库中的数据“复制”到另一个库，到另一个实例中，由OLTP复制到OLAP环境中，由某数据中心复制到位于地球另一侧的另外一个数据中心中。因此，由于复制所提供的功能，复制可用被用来剥离负载，用于做数据冗余，直至把复制用于作为高可用性拓扑中的一个环节。（切记，复制的功能可以被用做高可用性，而不是复制是高可用性功能。）

&＃160;&＃160;&＃160; 不同于其它SQL Server可以被用作高可用性的特性，复制可以做的非常灵活。您可以复制某些列，过滤某些行，复制表中的部分数据。复制是基于数据库对象的，而不像日志传送、镜像、集群、AlawysOn等需要以库和实例作为基本对象，此外更新的订阅还允许订阅端合并数据，没有任何一种其它的高可用性技术能做到这一点。

&＃160;

&＃160;&＃160;&＃160; 关于复制的基本概念，我在之前已经有一篇文章进行了阐述：。但这里我还是想再次对基本的概念进行阐述。

&＃160;&＃160;&＃160; 复制的模型参考的杂志发布的模型，由出版社发型杂志，由经销商分发杂志，由订户来消费这些杂志。这个概念看似简单，但可以归结出复制下面一些特点：

&＃160;

&＃160;&＃160;&＃160; 下面来简单介绍几种复制类型在高可用性中可以作为的角色。

&＃160;

快照发布

&＃160;&＃160;&＃160; 快照复制本质上就是通过快照目录(共享目录)共享一堆文件(因为需要多个订阅端共享)，在早起版本,快照复制仅仅是一个文件，而相对更新的版本，复制会将文件分为多个。快照就是文章某一时间点发布的Article

&＃160;&＃160;&＃160; 是一种创建报表数据库的好方式。

&＃160;&＃160;&＃160; 对于快照复制的简单概念，如图1所示。

&＃160;&＃160;&＃160;

图1.快照发布的概念

&＃160;

&＃160;

事务复制

&＃160;&＃160;&＃160; 在初始化订阅后（可通过快照初始化，或者由备份初始化，请参阅：），由发布服务器上将需要被复制的部分的日志标记为复制.由分发服务器的log reader agent来读取发布服务器上这部分日志,当分发服务器将所有的日志传递给订阅服务器，则发布服务器上的日志就可以清空了

&＃160;&＃160;&＃160; 通过原理不难看出,每个数据库只能有一个log reader agent,因此数据库中发布内容过多，或者重复发布，则会产生严重的性能问题。此外log reader agent需要读取所有的日志，不会有任何奇迹发生来跳过那些没有被标记为复制的日志.因此当对复制的文章进行了筛选的话，会影响性能(这里可不像索引,设置了筛选条件能够提高查询速度)。

&＃160;&＃160;&＃160; 性能因素取决于很多地方,发布服务器的速度，更改频率，分发服务器的速度等等。

&＃160;&＃160;&＃160; 通常可以用于做实时报表，虽然会有些许延迟，但效果非常好。

&＃160;

合并复制

&＃160;&＃160;&＃160; 合并复制可以实现数据的多处更新，当更新冲突时，可以设置规则，比如北京和上海的服务器，我可以设置北京的服务器永远赢。

&＃160;

Peer-To-Peer复制

&＃160;&＃160;&＃160; P2P复制是基于事务日志之上的一种复制类型，他允许每个节点都成为对等的实体。因此可以非常好的用于HA和负载均衡，即使某一个节点宕机，完全不会影响其它节点的可用性。

&＃160;&＃160;&＃160; 自SQL Server 2012以来，PeerToPeer复制已经成为了一种单独的发布类型。

&＃160;&＃160;&＃160; 一个Peer-To-Peer的简单例子如图2所示。

&＃160;&＃160;&＃160;

图2.对等复制

&＃160;

&＃160;&＃160;&＃160; 从图2中可以看出，节点A、B、C、D分别对同一份数据保存相同的副本，并且每个节点上都可以进行读写操作。我们可以假设每个节点都是在不同的地理位置，因此假如说节点A宕机，，则可以直接将应用程序连接字符串重定向到其它节点，实现了高可用性。从图2中还可以看出，对于任一节点我们都可以进行读写操作，因此实现了负载均衡的效果。此外，NodeB进一步将数据发布到只读服务器上，进一步实现了读写分离。
&＃160;&＃160; 因此，这种方式具有极大的灵活性，和其它高可用性技术结合可以实现多种数据库拓扑。

&＃160;&＃160; 在SQL Server 2008之后的版本，当遇见数据更新冲突时，可以通过冲突查看器进行查看并解决冲突，还可以在数据更新冲突出现后，进行报警。

&＃160;

&＃160;&＃160;&＃160; 每一种高可用性技术都有其自身的优点和缺陷，如果某种技术相较与其它技术只有有点，没有缺陷，那”其它技术“一定会被淘汰。

&＃160;&＃160;&＃160; 相比较其它高可用性技术而言，复制有如下好处：

&＃160;&＃160;&＃160; 但同样，复制也有其自身局限性，比如：

&＃160;

&＃160;&＃160;&＃160; 但不得不说，复制的确是非常的强大，套用京东“首席DB Replicationor(自造词)”陈璟的话说就是：“想复制什么复制什么，想复制多远复制多远，想怎么复制就怎么复制，想复制的多复杂就多复杂”，同时结合其它技术可以实现很多有意思的拓扑，比如图3（同样来自陈璟同学）。

&＃160;&＃160;&＃160;

&＃160;&＃160;&＃160; 图3.利用复制分发写数据，同时实现高可用性

&＃160;

&＃160;&＃160;&＃160; 通过图3这种方式，分发了写压力，同时相同的读库实现了负载均衡以及高可用性，当某个读库宕机后，会有足够的时间进行修复。

&＃160;

&＃160;&＃160;&＃160; 本篇文章对复制在高可用架构的角色做了一个概述。复制作为高可用性中最为灵活的技术，与其它技术结合，可以实现很多有意思的拓扑。