SQL Server 主从技术介绍

SQLServer 主从技术包含：复制、日志传送、镜像、AlwaysOn  这4种方式。主要取决于客户需求。

       复制 一般说的事务复制。 是针对表级别，表上必须有主键。同步延迟低，不可自动故障转移。第二个节点可以读

       日志 同步延迟高，不可用自动故障转移。 第二个节点可以读，针对数据库级别
       镜像 有同步模式，延迟低，可用故障转移，但第二个节点不可读，针对数据库级别

       AlwaysOn 技术集中了故障转移群集、数据库镜像和日志传送三者的优点

下面将分别介绍这几种主从技术的概念及优缺点:

1 复制 

1.1 使用复制的场景：

1).负载均衡----通过将数据复制到其它数据库服务器来减少当前服务器的负载，比如说最典型的应用就是分发数据来分离OLTP和OLAP环境。
2).分区----将经常使用的数据和历史数据隔离，将历史数据复制到其它数据库中
3).授权----将一部分数据提供给需要使用数据的人，以供其使用
4).数据合并-每个区域都有其各自的数据，将其数据进行合并。比如一个大公司，每个地区都有其各自的销售数据，总部需要汇总这些数据。
5).故障转移----复制所有数据，以便故障时进行转移。

1.2 复制类型

1.2.1 快照复制

快照复制是完全按照数据和数据库对象出现时的状态来复制和分发它们的过程。快照复制不需要连续地监控数据变化，因为已发布数据的变化不被增量地传播到订阅服务器，而是周期性的被一次复制，快照复制将发布的所有表做成一个镜像，然后一次性复制到订阅服务器。中间的更新不会像其它复制类型那样自动传送到订阅服务器。由这个概念不难看出，快照复制的特点会是:

1).占用网络宽带，因为一次性传输整个镜像，所以快照复制的内容不应该太大。
2).适合那些更新不频繁，但每次更新都比较大的数据。比如企业员工信息表，每半年更新一次这类的业务场景。
3).适合订阅服务器是OLAP只读的环境。

当符合以下一个或多个条件时，使用快照复制本身是最合适的：
很少更改数据。
在一段时间内允许具有相对发布服务器已过时的数据副本。
复制少量数据。
在短期内出现大量更改。
在数据更改量很大，但很少发生时，快照复制是最合适的。例如，如果某销售组织维护一个产品价格列表且这些价格每年要在固定时间进行一两次完全更新，那么建议在数据更改后复制完整的数据快照。对于给定的某些类型的数据，更频繁的快照可能也比较适合。例如，如果一天中在发布服务器上更新相对小的表，但可以接受一定的滞后时间，则可以在夜间以快照形式传递更改。
发布服务器上快照复制的连续开销低于事务性复制的开销，因为不用跟踪增量更改。但是，如果要复制的数据集非常大，那么若要生成和应用快照，将需要使用大量资源。评估是否使用快照复制时，需要考虑整个数据集的大小以及数据的更改频率。

1.2.2 事务复制

使用事务复制，初始快照数据将被传播到订阅服务器，因此该订阅服务器就具有了一个所谓的初始负载，这是可以开始工作的内容。当出版服务器上发生数据修改时，这些单独的事务会被及时捕获并复制到订阅服务器。并保留事务边界，当所有的改变都被传播后，所有订阅服务器将具有与传播服务器相同的值。事务复制就像其名字一样，复制事务。在第一次设置好事务复制后，发布的表、存储过程等将会被镜像，之后每次对于发布服务器所做的改动都会以日志的方式传送到订阅服务器。使得发布服务器和订阅服务器几乎可以保持同步。因此，可以看出事务复制的特点是:

1).发布服务器和订阅服务器内容基本可以同步
2).发布服务器，分发服务器，订阅服务器之间的网络连接要保持畅通。
3).订阅服务器也可以设置成请求订阅,使得订阅服务器也可以不用一直和分发服务器保持连接。
4).适用于要求实时性的环境。

事务性复制通常用于服务器到服务器环境中，在以下各种情况下适合采用事务性复制：
希望发生增量更改时将其传播到订阅服务器。
从发布服务器上发生更改，至更改到达订阅服务器，应用程序需要这两者之间的滞后时间较短。
应用程序需要访问中间数据状态。例如，如果某一行更改了五次，事务性复制将允许应用程序响应每次更改（例如，激发触发器），而不只是响应该行最终的数据更改。
发布服务器有大量的插入、更新和删除活动。
发布服务器或订阅服务器不是 SQL Server 数据库（例如，Oracle）。
默认情况下，事务性发布的订阅服务器应视为只读，因为更改将不会传播回发布服务器。但是，事务性复制确实提供了允许在订阅服务器上进行更新的选项

1.2.3 合并复制

合并复制即允许发布服务器更新数据库，也允许订阅服务器更新数据。定期将这些更新进行合并，使得发布的数据在所有的节点上保持一致。因此，有可能发布服务器和订阅服务器更新了同样的数据，当冲突产生时，并不是完全按照发布服务器优先来处理冲突，而是根据设置进行处理。  

合并复制通常用于服务器到客户端的环境中。合并复制适用于下列各种情况：
多个订阅服务器可能会在不同时间更新同一数据，并将其更改传播到发布服务器和其他订阅服务器。
订阅服务器需要接收数据，脱机更改数据，并在以后与发布服务器和其他订阅服务器同步更改。
每个订阅服务器都需要不同的数据分区。
可能会发生冲突，并且在冲突发生时，您需要具有检测和解决冲突的能力。
应用程序需要最终的数据更改结果，而不是访问中间数据状态。例如，如果在订阅服务器与发布服务器进行同步之前，订阅服务器上的行更改了五次，则该行在发布服务器上仅更改一次来反映最终数据更改（也就是第五次更改的值）。
合并复制允许不同站点自主工作，并在以后将更新合并成一个统一的结果。由于更新是在多个节点上进行的，同一数据可能由发布服务器和多个订阅服务器进行了更新。因此，在合并更新时可能会产生冲突，合并复制提供了多种处理冲突的方法。

2 日志传送

概述
SQL Server 使用日志传送，您可以自动将“主服务器”实例上“主数据库”内的事务日志备份发送到单独“辅助服务器”实例上的一个或多个“辅助数据库”。 事务日志备份分别应用于每个辅助数据库。 可选的第三个服务器实例（称为“监视服务器”）记录备份和还原操作的历史记录及状态，还可以在无法按计划执行这些操作时引发警报。
优点
为单个主数据库以及一个或多个辅助数据库（每个数据库都位于单独的 SQL Server 实例上）提供灾难恢复解决方案。
支持对辅助数据库的受限的只读访问权限（在还原作业之间的间隔期间）。
允许用户将延迟时间定义为：从主服务器备份主数据库日志到辅助服务器必须还原（应用）日志备份之间的时间。 例如，如果主数据库上的数据被意外更改，则较长的延迟会很有用。 如果很快发现意外更改，则通过延迟，您可以在辅助数据库反映此更改之前从其中检索仍未更改的数据
日志传送的使用情景：
作为热备服务器：
高可用的本质就是“冗余”，而冗余的最现实的实现就是备份。由于DBMS的结构，日志往往会更加大，也更加重要，所以高可用往往都是针对日志的。当使用日志传送作为热备的时候，可以在主服务器宕机的后【手动】转移到辅助服务器。使其能够尽可能地保持业务连续。高可用中，集群和镜像是可以自动转移。但是日志传送和复制是一个手动过程。需要人工干预，但是集群配置和使用都相当复杂，这就导致了它的局限性。
同时，由于日志传送建立在日志基础上，所以可以在误操作的时候“有可能”恢复到某一时刻。
作为灾难恢复解决方案：
灾难恢复是高可用最主要的目的。在日志传送中，最大的瓶颈和上面说的一样，就是网络带宽。由于各个高可用方案有其不足和优点，所以一般不会单纯用一种方式来保证业务连续性。
作为报表系统解决方案：
为减少主服务器的压力，可以在辅助服务器上创建报表服务器，前提是数据库的恢复模式为standby。但是在还原过程中库是不可访问的，这也会影响客户的使用。如果不实时更新，那么数据也是非实时的，且上面的数据是只读。这些会影响正常的报表使用，所以除非比较特殊的应用情景之外，这个不是作为报表系统的好的解决方法。

3 镜像

数据库镜像概述

数据库镜像维护一个数据库的两个副本，这两个副本必须驻留在不同的 SQL Server 数据库引擎服务器实例上。 通常，这些服务器实例驻留在不同位置的计算机上。 启动数据库上的数据库镜像操作时，在这些服务器实例之间形成一种关系，称为“数据库镜像会话” 。
其中一个服务器实例使数据库服务于客户端（主体服务器）。 另一个服务器实例则根据镜像会话的配置和状态，充当热备用或温备用服务器（镜像服务器）。 同步数据库镜像会话时，数据库镜像提供热备用服务器，可支持在已提交事务不丢失数据的情况下进行快速故障转移。 未同步会话时，镜像服务器通常用作热备用服务器（可能造成数据丢失）。
在“数据库镜像会话 ”中，主体服务器和镜像服务器作为“伙伴 ”进行通信和协作。 两个伙伴在会话中扮演互补的角色：“主体角色” 和“镜像角色” 。 在任何给定的时间，都是一个伙伴扮演主体角色，另一个伙伴扮演镜像角色。 每个伙伴拥有 其当前角色。 拥有主体角色的伙伴称为“主体服务器” ，其数据库副本为当前的主体数据库。 拥有镜像角色的伙伴称为“镜像服务器” ，其数据库副本为当前的镜像数据库。 如果数据库镜像部署在生产环境中，则主体数据库即为“生产数据库 ”。
数据库镜像涉及尽快将对主体数据库执行的每项插入、更新和删除操作“重做 ”到镜像数据库中。 重做通过将活动事务日志记录的流发送到镜像服务器来完成，这会尽快将日志记录按顺序应用到镜像数据库中。 与逻辑级别执行的复制不同，数据库镜像在物理日志记录级别执行。 从 SQL Server 2008开始，在事务日志记录的流发送到镜像服务器之前，主体服务器会先将其压缩。 在所有镜像会话中都会进行这种日志压缩。
数据库镜像的优点
数据库镜像是一种简单的策略，具有下列优点：
提高数据库的可用性。
发生灾难时，在具有自动故障转移功能的高安全性模式下，自动故障转移可快速使数据库的备用副本联机（而不会丢失数据）。 在其他运行模式下，数据库管理员可以选择强制服务（可能丢失数据），以替代数据库的备用副本。 
增强数据保护功能。
数据库镜像提供完整或接近完整的数据冗余，具体取决于运行模式是高安全性还是高性能。
在 SQL Server 2008 Enterprise 或更高版本上运行的数据库镜像伙伴会自动尝试解决某些阻止读取数据页的错误。 无法读取页的伙伴会向其他伙伴请求新副本。 如果此请求成功，则将以新副本替换不可读的页，这通常会解决该错误。 有关详细信息，
提高生产数据库在升级期间的可用性。
为了尽量减少镜像服务器的停机时间，您可以按顺序升级承载故障转移伙伴的 SQL Server 实例。 这样只会导致一个故障转移的停机时间。 这种形式的升级称为“滚动升级 ”。 

4 AlwaysOn

SQL Server AlwaysOn原理
SQL Server2012所支持的AlwaysOn技术集中了故障转移群集、数据库镜像和日志传送三者的优点，但又不相同。故障转移群集的单位是SQL实例，数据库镜像和日志传送的单位是单个用户数据库，而AlwaysOn支持的单位是可用性组，每个组中可以包括一个或者是多个用户数据库。也就是说，一旦发生切换，则可用性组中的所有数据组会作为一个整体进行切换。
AlwaysOn底层依然采用Windows 故障转移群集的机制进行监测和转移，因此也需要先建立Windows Cluster，只不过可用性组中的数据库不一定非要再存放在共享存储上了。可以是存储在本地磁盘上。
下面，先看一下AlwaysOn的关键特性：
1. 同故障转移群集一样，也需要一个虚拟网络名称用于客户端的统一连接。
2.一个主服务器可以最多对应四个辅助服务器，总数达到五个，而且辅助服务器支持只读功能。
3.辅助服务器可以独立执行备份和DBCC维护命令。通过配置，可以实现客户端的只读请求可以被自动定向到辅助服务器。
4.主服务器和辅助服务器之间的数据会被加密和压缩，以提高安全性和网络传输效率。
5..支持自动、手动和强制三种故障转移方式。
6.有仪表盘用于监控AlwaysOn的运行状态。
7.可以实现多站点的部署，即主站点和辅助站点可以跨物理网络。
AlwaysOn的基本架构
在Windows MSCS故障转移群集的基础上部署AlwaysOn高可用组，用户可以在群集节点上安装SQL Server单机实例，也可以安装SQL Server群集实例，AlwaysOn仅要求所有SQL Server实例都运行在同一个MSCS中，但SQL Server实例本身是不需要群集模式的，这与SQL Server2008 群集的实例完全不同。在此推荐使用单机模式的SQL Server，好处是：可用性副本是个单机实例，那么数据库副本就存放在该运行该实例节点的本地磁盘上；如果可用性副本是个群集实例，那么数据库副本就存放在共享磁盘上。
可用性组从Windows群集角度来看，就是一个群集资源，其中的所有数据库作为一个整体在节点间进行故障转移，当然这不包括系统数据库，系统数据库是不能加入高可用性组中的。
因为需要借助Windos群集实现监控和转移，所以AlwaysOn会受到一些限制：
一个可用性组中的所有可用性副本必须运行在单一的Windows群集上，跨不同Windows群集的SQL Server实例不能配置成一个AlwaysOn可用性组。
一个可用性组的所有可用性副本必须运行在Windows群集的不同节点上。运行在同一个节点上的两个不同实例不能用作同一个可用性组的副本。
如果某个可用性副本实例是一个SQL群集实例，那同一个SQL群集的其他非活跃节点上安装的任何其他SQL实例都不能作为它的辅助副本。
一个数据库只能属于一个可用性组。
AlwaysOn最多可以支持五个副本，但只有一个可用性副本上运行的数据库是处于可读写状态。这个可读写的数据库被称为主数据库（PrimaryDatabase），同时这个可用性副本被称为主副本（primaryreplica）。其余的副本都被称为辅助副本（secondaryreplica），辅助副本上的数据库可能是不可访问的，或者是只能接受只读操作（取决于可用性组的配置），这些数据库被称为辅助数据库。一但发生故障转移，任何一个辅助副本都可以成为新的主副本实例。主副本会不断地将主数据库上的数据变化发送到辅助副本，来实现副本间的数据库同步。下图就显示了一个可用性组中各副本之间的关系。

《SQL Server 2012 实施与管理实战指南》上的一个表格来总结一下：