部署AlwaysOn第二步：配置AlwaysOn，创建可用性组

AlwaysOn是在SQL Server 2012中新引入的一种高可用技术，从名称中可以看出，AlwaysOn的设计目标是保持数据库系统永远可用。AlwaysOn利用了Windows服务器故障转移集群（Windows Server Failover Clustering，简称WSFC）的健康检测和自动故障转移的特性，因此，必须建立在WSFC之上，搭建WSFC的过程，请参考《部署AlwaysOn第一步：搭建Windows服务器故障转移集群》。

AlwaysOn支持的高可用单位是可用性组（Availability Group，简称AG），AG是包含了一个或多个用户数据库（User Database）的容器，AG里不能包含系统数据库；AG以用户数据库的集合为单位进行健康检测和故障转移，就是说，AG中的所有数据库作为一个整体发生故障转移。

一，AlwaysOn的基本架构

1，了解AlwaysOn的关键特性

AlwaysOn支持的故障转移，不是以整个SQL Server实例为单位，而是以AG为单位，AG中的多个用户数据库一起进行故障转移；
AG提供虚拟的服务器网络名，也就是AG Listener，无论哪台服务器是当前的Primary Server，客户端都可以使用统一的AG Listener进行连接；
AlwaysOn在辅助服务器（Secondary Server）上维护用户数据库组的副本，同步提交方式能够使Primary Server和Secondary Server上的数据保持完全同步；
在特定的配置情况下，客户端的只读请求可以被自动定向到辅助服务器，减少了Primary Server的IO压力；
一台主服务器最多对应4台辅助服务器，总共5台服务器，发生故障转移时，可以切换到任意一台辅助服务器上；

2，推荐安装SQL Server单机实例（stand-alone）

部署AlwaysOn之前，必须搭建WSFC环境；在Windows集群的结点上，推荐安装SQL Server单机实例，AlwaysOn仅要求所有的SQL Server实例都运行在同一个Windows集群环境中，但SQL Server实例本身不需要是集群模式的，推荐安装SQL Server单机实例。在SQL Server安装中心中，选择“全新SQL Server独立安装或向现有安装添加功能（New SQL Server stand-alone installation or add features to an existing installation）”。

3，可用性数据库（Availability Database）

AlwaysOn可用性组里包含一个或多个用户数据库，称作可用性数据库（Availability Database），每个可用性副本上都存储可用性数据库的副本，这些数据库副本彼此之间互相同步，如果可用性副本是SQL Server单机实例，那么数据库副本就存储在实例的本地磁盘（Local Disk）中。可用性组不能包括系统数据库，就是说，系统数据库不能通过AlwaysOn实现高可用性。

在多个可用性副本上，只有一个可用性副本上运行的数据库处于可读写状态，这个可读写的数据库称作Primary Database，这个可用性副本称作Primary Replica，其余的副本都称作辅助副本（Secondary Replica），辅助副本上的数据库可能是不可访问的，或者是只读的，这些数据库称作辅助数据库。一旦发生故障转移，任何一个辅助副本都可以成为新的Primary Replica，主副本会不断地将Primary database上的数据更新发送到辅助副本，实现副本间的数据同步。

4，AG是集群的资源组

从WSFC的角度来看，AG是集群的资源组，因此，AG中包含的所有用户数据库是作为一个整体在集群的结点之间进行故障转移的，这使得AlwaysOn非常适合那些需要用到多个数据库的应用程序。

5，侦听器（Listener）

在故障转移集群管理器（Failover Cluster Manager）中，WSFC只能看到一个资源组，就是AlwaysOn的可用性组（AG），但是应用程序不能使用资源组的名字登录SQL Server实例，必须知道当前主副本（Primary Replica）的名字，使用这个服务器名称连接SQL Server实例。一旦发生可用性组（AG）的故障转移，应用程序必须通过修改连接字符串（Connection String）重新连接到新的Primary Replica上，这很麻烦。通过可用性组侦听器（Availability Group Listener，简称Listener），能够解决该问题。Listener是一个虚拟的服务器，用于让应用程序透明的连接到主副本而不会受到故障转移的影响，一个Listener包含虚拟的网络名（DNS Name），虚拟IP地址和端口号。创建了Listener之后，WSFC就会为可用性组资源添加虚拟IP地址和虚拟网络名资源，应用程序通过连接虚拟网络名，连接主副本（Primary Replica）上的SQL Server实例。

应用程序使用Listener的虚拟网络名连接SQL Server实例，是以一个默认实例的形式访问的，只有服务器名，没有SQL Server实例名，因此应用程序不会尝试使用SQL Brower 服务。推荐AlwaysOn的各个副本都使用默认实例，默认端口。如果Listener使用的端口号是默认端口1433，那么应用程序能够直接使用虚拟网络名连接到SQL Server实例。

二，AlwaysOn的数据同步原理

AlwaysOn会在各个副本上维护数据库的副本，主副本上发生的数据更新，都会同步到辅助副本上，为了实现数据同步，AlwaysOn需要完成三个任务：

把主副本上发生的数据更新的事务日志记录下来；
把事务日志记录传输到各个辅助副本；
在各个辅助副本上重做数据更新；

在主副本和辅助副本上，SQL Server都会启动相应的线程来完成相应的任务。

1，日志持久化

任何一个SQL Server都有个Log Writer线程，当事务提交一个数据更新时，Log Writer把数据更新的日志写入到物理事务日志文件。

2，主副本的日志传输

对于配置AlwaysOn 主副本的数据库，SQL Server创建一个Log Scanner线程，负责将日志记录从日志缓冲区或者事务日志文件读出，打包成日志块，发送到各个辅助副本，由于Log Scanner线程的不间断工作，使得主副本上的数据变化，不断地向辅助副本上传播。

3，辅助副本上的固化（Harden）和重做（Redo）

在辅助副本上，同样有两个线程固化线程和重做线程完成相应的数据更新操作。固化线程将主副本上Log Scanner传入的日志块写入辅助副本的硬盘上的事务日志文件里，而重做线程，负责从硬盘上读取事务日志，将日志记录翻译成数据更新操作，在辅助副本的数据库上重做主副本的数据更新操作。

当重做线程完成工作之后，辅助副本上的数据库和主副本保持同步，重做线程每隔固定的时间间隔，就会向主副本报告自己的工作进度，主副本根据各个辅助副本的工作进度，就能计算数据的差异。

在AlwaysOn中，在固化线程和重做线程是完全独立工作的，固化线程负责将主数据库传递的日志写入到硬盘上的日志文件中，将日志持久化存储；而重做线程负责读取和翻译已被固化线程存储的日志，将主数据库上的数据更新操作在辅助数据库上重新执行。

三，AlwaysOn的可用性模式

可用性模式决定了主副本在提交事务之前，是否需要等待某个辅助副本将事务日志记录固化到硬盘，AlwaysOn可用性组支持两种可用性模式：异步提交模式和同步提交模式。

1，异步提交模式

当辅助副本处于异步提交模式时，主副本无需等待辅助副本完成日志固化，就可以提交事务，因此，主副本事务提交不会受到辅助数据库的影响而产生等待，但是，辅助数据库的更新会滞后于主数据库，如果发生故障转移，可能会导致某些数据更新丢失。

在异步提交模式下，辅助副本会尽量和主副本的日志记录保持一致，不过，即使辅助数据库和主数据库上的数据是同步的，可用性组始终认为辅助数据库处于“在同步”（SYNCHRONIZING）状态，因为，理论上在异步模式下，辅助数据库在任何时间点都可能滞后于主数据库。

2，同步提交模式

在同步提交模式下，主数据库在提交事务之前，主副本必须等待辅助副本将日志固化到硬盘上，主副本只有收到来自辅助副本的日志固化成功的确认信息之后，才能提交事务；只要辅助副本没有向主副本报告日志固化完成，主副本上的事务就不能提交。这样能够保持主副本和辅助副本的数据始终是同步的，只要一直进行数据同步，辅助数据库就会保持”已同步“（SYNCHRONIZED）状态。

同步提交模式能够实现辅助数据库和主数据库上的数据的完全同步，但是，代价是主数据库上的事务提交延迟增加，可以说，同步提交模式相对于性能来说，更强调高可用性。

3，可用性副本之间的短线连接状态

”DISCONNECTED“连接状态：AlwaysOn可用性组之间有一个会话超时机制，默认值10s。主副本和辅助副本之间，按固定的时间间隔相互发送ping，在会话超时时间内，如果主副本收到辅助副本的ping命令，就说明副本之间的连接正常；一旦某个辅助副本因为故障而不能响应，产生会话超时，主副本将该辅助副本的连接设置为”DISCONNECTED“连接状态，即使使用同步提交模式，主副本的事务也不需要等待该副本的响应就可以提交。

4，辅助数据库的”NOT SYNCHRONIZING“状态

无论使用什么可用性模式，如果一个事务在辅助数据库上重做失败，就会导致辅助副本进入”NOT SYNCHRONIZING“状态，即使处于同步提交模式，主副本的事务也不需要等待该副本的响应就可以提交。

如果用户想中断数据库的数据同步，而不想影响可用性组中的其他数据库，可以通过在SSMS中选择Suspend Data Movement来手动挂机，挂起之后，该数据库在各个可用性副本上的状态都会变成”NOT SYNCHRONIZING“状态。

四，AlwaysOn的故障转移

当WSFC触发故障转移之后，一个辅助副本被选择成为新的主副本角色，该副本上的SQL Server实例对可用性数据库执行恢复操作，使其成为新的主数据库；在故障转移完成之后，如果原先的主副本还可用，那么它就成为辅助副本，它上面的数据库就成为了辅助数据库。

但AlwaysOn发现故障之后，是否立即出发故障转移呢？这取决于可用性副本的可用性模式和故障转移模式，如图：

只有主副本和转移的目标副本都配置为”同步提交模式+自动故障转移“模式时，才能实现两个可用性副本之间的自动故障转移。在三种故障转移模式中，只有强制故障转移可能丢失数据。自动故障转移和手动故障转移，都必须配置在同步提交模式下，必须数据库都处于SYNCHRONIZED状态。对于异步提交模式的辅助副本，无论数据是否已经达到同步，都只会处于SYNCHRONIZING状态，只能支持强制故障转移。

五，创建可用性组

1，在创建AG之前，配置SQL Server实例启用AlwaysOn

在SQL Server配置管理器（SQL Server Configuration Manager）中打开SQL Server 实例的属性，输入Windows 故障转移集群的名称，并勾选“Enable AlwaysOn Availabilitty Groups”选项启用AlwaysOn 可用性组，在所有可用性副本上都启用SQL Server实例的AlwaysOn 可用性组。