AlwaysOn －Notes from Chapter 3 in 《 SQL Server 2012 实施与管理实战指南》and Others


1.  Overview


a.      HA (synchronous, local datacenter) and DR (asynchronous, remote datacenter) solution
b.     Protects against I/O subsystem failure on the primary server or datacenter
c.      Log Stream compression available for increased performance
d.     Automatic Page Repair
e.      Automatic redirection to secondary is possible via an AG listener
f.       Automatic failover is possible, does not require a 3rd witness server, windows cluster is used for quorum
g.     Up to 4 secondaries
h.     Quorum is based on all nodes of the underlying Windows Cluster
i.       Can failover a set of databases as a group (database set RLO)
j.       Can choose between several mirroring and failover options: synchronous or asynchronous streaming, automatic or manual failover
k.      Can offload T-Log backups  on secondary
l.       Considerations:
                                          i.     Database must be using the FULL recovery model
                                         ii.     Database on secondary is not writeable
                                       iii.     Database on secondary can be set as readable (Readable or READ-INTENT secondary options)
                                       iv.     Note that the system databases master, tempdb, and model cannot be part of an AG. Databases have dependencies on objects that reside in other databases such as the master database. These objects often include logins, jobs, certificates, and server audits but can include other objects. A process (normally involving scripts) needs to be adopted to keep objects that are external to the database synchronized across the servers. Suitable for environments where these external dependencies are not changed very often (which tends to be true in most environments).
                                         v.     Some features are not supported, such as cross database transactions (http://msdn.microsoft.com/en-us/library/ms366279.aspx).
                                       vi.     Special configuration considerations when using Replication (http://technet.microsoft.com/en-us/library/hh403414.aspx).
                                      vii.     Quorum model and node vote options should be configured to ensure an outage at the DR site will not cause the cluster to lose quorum

AlwaysOn具有以下这些关键特性：

像群集一样，AlwaysOn支持故障转移，但是它具有其独特的特点：
  • 多个用户数据库可以一同进行故障转移。这对要同时使用多个用户数据库的应用，例如Microsoft SharePoint，会很有帮助。
  • 提供一个虚拟的服务器网络名，无论哪个服务器是当前的主服务器，客户端都可以使用统一的虚拟服务器名进行连接。
  • 具有三种故障转移模式：自动，手动和强制，用户可以选择发生故障切换的条件。 
  • 一个主服务器可以对应最多达4个辅助服务器（总共5个服务器）。发生故障时可以切换到任意一个辅助服务器上。
  • 有Dashboard可用于监视AlwaysOn的运行状态。有丰富的信息可用于故障诊断（DMV,性能计数器，扩展事件日志等）
  • 得益于Windows Server 2008群集，可以实现多站点的部署。主服务器和辅助服务器之间可以在物理上相隔很远。
像镜像和日志传递一样，AlwaysOn在辅助服务器上有数据库的另外一份拷贝。所不同的是，这份拷贝可以支持更多的只读功能。
  •  每个辅助服务器上都有一份数据的拷贝，可以使服务器上的数据拷贝和主服务器上的数据完全同步。
  • 辅助服务器可用于只读的访问请求。
  • 辅助服务器可以执行备份和DBCC命令。
  • 在某些配置情况下，客户端的只读请求可以被自动定向到辅助服务器。
  • 可以自动修复某些类型的数据页面损坏问题。
  • 主服务器和辅助服务器之间的数据会被加密和压缩，提高了安全性又降低了网络流量。
2.  AlwaysOn的基本架构
a.  High Availability across Individual SQL Server Instances

(Example of High Availability across Individual SQL Server Instances)

b.  High Availability Groups across Individual SQL Server Instances and SQL Server Failover Clusters
在下例子中，Windows群集分布在两个子网（Network Subnet A和Network Subnet B）里。在子网A，有三个结点。子网B有两个结点。结点A1与结点A2上安装了一个群集的SQL Server实例Instance 1。其他结点上分别安装了三个单机的SQL Server实例。这四个实例，就可以组成一个可用性组（Availability Group）。这些实例都是这个可用性组的可用性副本（Availability Replica）。在图3-1中所显示的状态下，SQL实例Instance 1是主副本，其他实例都是辅助副本。这些实例上都存储有同样的一套用户数据库组（Availability Database），但是只有Instance 1上的数据库是可读写的。
如果Node A1或Node A2上安装有任何其他SQL实例，这些实例都不能被加入到这个可用性组中。
In the example below, a Windows cluster is across two subnets (Network Subnet A and Network Subnet B). Subnet A has three nodes. Subnet B has two nodes. Nodes A1 and A2 have shared a clustered SQL Server Instance 1. The other three nodes have installed stand-alone SQL Server. These four instances have formed an Availability Group. They are all Availability Replicas in the availability group. Among them, Instance 1 is the primary replica, whereas the other instances are secondary. These instances have the same set of user databases (Availability Database), but only the databases on Instance 1 are readable and writable.
If Node A1 or Node A2 A1 has installed any other SQL instances, these instances cannot be a part of the availability group.

A similar figure from http://msdn.microsoft.com/en-us/library/hh270278.aspx

(Example of High Availability Groups across Individual SQL Server Instances and SQL Server Failover Clusters)

c.  Listener

一个Listener包含虚拟IP地址、虚拟网络名（DNS名）和端口号三个要素。创建了Listener之后，就会为可用性组资源添加虚拟IP地址和虚拟网络名资源。应用程序通过连接虚拟网络名而非主副本的实例名来访问到主副本实例和其上面运行的数据库，这点和故障转移群集很像。和故障转移群集不同的是，除了虚拟网络名可以使用外，主副本本身的真实实例名依旧可以被用来连接到这个实例。

如果Listener使用的端口是默认端口1433，那么可用端程序可以很简单的直接使用虚拟网络名连接到主副本。但是如果Listener使用的端口是一个非默认端口，那么情况就有点复杂了。如果各个可用性副本所使用的端口不相同，有的副本使用1433端口，而有的副本使用非默认端口，你就必须在连接字符串中指定端口号。如果客户端仅使用虚拟网络名来进行连接，当主副本是使用默认端口的实例时，连接可以建立；但一旦发生故障转移，应用程序的连接就会失败。这会影响数据库服务的高可用性。所以按照现有的设计，我们建议加入AlwaysOn的SQL Server实例，最好使用同样的固定端口。

3.    AlwaysOn的数据同步原理
a.     像数据库镜像技术一样，AlwaysOn会在各个副本上都维护一套数据副本。主副本上发生的数据变化，会同步到辅助副本上。所以和镜像一样，AlwaysOn也要完成三件事:
                                         i.     把主副本上发生的数据变化记录下来。
                                       ii.     把这些记录传输到各个辅助副本。
                                     iii.     把数据变化在辅助副本上同样完成一遍。
b.    那AlwaysOn又是怎么做的呢？在主副本和辅助副本上，SQL  Server都会启动相应的线程来完成相应的任务。现在先从主副本谈起。
                                         i.     Primary Replica
1.    首先，当任何一个SQL用户提交一个数据修改事务时，Log Writer线程会负责把记录本次修改的日志信息先记入一段内存中的日志缓冲区，然后再写入物理日志文件（日志固化）。
2.    然后，Log Scanner工作线程将日志记录从日志缓冲区或者日志文件里中读出，打包成日志块，发送给各个辅助副本。由于它的不间断工作，才使主副本上的数据变化，可以不断地向辅助副本上传播。这2个线程在工作上各自独立，以达到更高的效率。Log Scanner负责传送日志块，而无须等待Log Writer完成日志固化
                                       ii.     Secondary Replica –也有两个线程，完成相应的数据更新动作，它们是：
1.    固化（Harden）线程 - 将主副本Log Scanner所发过来的日志块写入辅助副本的磁盘上的日志文件里（这个过程被称为"固化"）。
2.    重做（Redo）线程，则负责从磁盘上读取日志块，将日志记录翻译成数据修改操作，在辅助副本的数据库上完成。

4.  AlwaysOn的可用性模式
a.  可用性模式
可用性模式决定了主副本在提交事务之前是否需要等待某个辅助副本将事务日志记录固化到磁盘。AlwaysOn 可用性组支持两种可用性模式："异步提交模式"和"同步提交模式"。
                                         i.     异步提交模式
当辅助副本处于异步提交模式下时，主副本无须确认该辅助副本已经完成日志固化，就可以提交事务。因此，主数据库事务提交不会受到辅助数据库的影响而产生等待。但是，辅助数据库的更新可能会滞后于主数据库，如果发生故障转移，可能会导致某些数据丢失。如果为当前主副本配置了异步提交可用性模式，则它将通过异步方式为所有辅助副本提交事务，而不管这些副本各自的可用性模式设置如何。
                                       ii.        同步提交模式
在同步提交模式下，主数据库在提交事务之前，主副本要等待同步提交辅助副本确认它已将日志固化到磁盘上。只要辅助副本还没有告诉主副本日志固化完成，主副本上的事务就不能提交。这样就保证两边的数据始终是同步的。只要一直在进行数据同步，辅助数据库就会保持"已同步"（SYNCHRONIZED）的状态。
在同步提交模式下，日志块必须在主副本和辅助副本上都被固化到磁盘上，事务才能真正在主数据上提交。但是它并不要求日志在辅助副本上完成重做，这样可以减轻对主副本的性能影响。
另外，AlwaysOn会定期检查各个副本，以及副本上的各个数据库的健康情况。如果某个副本不能正常通信，那这个主副本和辅助副本间的连接进入DISCONNECTED状态。如果某个数据库不能正常进行数据同步，则这个数据库会进入"NOT SYNCHRONIZING"状态。
b.      可用性副本之间的"DISCONNECTED"连接状态
AlwaysOn可用性组有一个会话超时机制。所有的主副本和辅助副本之间，会按固定间隔互相发送 ping。在会话超时期限内，如果收到 ping命令，就说明副本之间的连接正常。收到 ping 后，副本将重置此连接上的超时计数器。主副本和辅助副本之间就通过 ping来判断彼此是否依旧处于活动状态。
一旦某个副本因为网络故障、操作系统、SQL Server宕机等原因失去响应，它将不能按时把ping命令发给它的伙伴。如果主副本和某个辅助副本间的会话发生超时（没有收到辅助副本的ping），主副本和这个辅助副本之间的连接就会进入DISCONNECTED 状态。进入DISCONNECTED状态后，即使可用性副本处于同步提交模式，事务也不需要等待该副本的响应就可以在主副本上提交。
会话超时限制是一个可用性组级别的设置，你可以通过在SQL Server Management Studio中打开可用组的属性来修改它的值，默认值为10秒，允许的最小值为5秒。通常建议你将超时期限设置为10秒或更长。因为如果低于10秒，SQL Server在运行地非常繁忙，响应变慢的时候，可能会错误地进入DISCONNECTED状态。
c.       辅助数据库的"NOT SYNCHRONIZING"状态
无论使用什么可用性模式，如果一个事务在辅助数据库上重做失败，就会导致辅助数据库进入"NOT SYNCHRONIZING"状态。和DISCONNECTED状态类似，此时即使可用性副本设置为同步提交模式，事务也可以在主副本上之间直接提交而无须等待辅助副本响应。
如果你想中断某个数据库的数据同步，而不想影响可用性组中的其他数据库，可以通过在Management Studio中选择Suspend Data Movement来手动挂起，如图3-5所示。挂起之后，该数据库在各个可用性副本（无论是什么可用性模式）上的状态都会变成"NOT SYNCHRONIZING".
5.    AlwaysOn的故障转移形式 
a.      AlwaysOn是如何发现可用性组出现问题的? - Hadrres.Dll会建立并保持一个连接到SQL Server，并通过这个连接运行sp_server_diagnostics，然后不断的获得诊断信息。
由于AlwaysOn可用性组是建立在Windows故障转移群集之上的，因此和SQL Server群集类似的，AlwaysOn可用性组也需要一个群集Resource DLL来连接Windows群集和SQL Server实例。由于可用性组是一个群集资源，Windows群集需要透过AlwaysOn的Resource DLL来控制资源的上线/离线，检查资源是否失败，更改资源的状态和属性，以及发生各种命令给可用性副本实例。你可以通过故障转移群集管理器查看可用性组资源的各种属性。
AlwaysOn可用性组的资源类型是"SQL Server Availability Group"，该资源类型使用的Resource DLL的叫作Hadrres.Dll，在Hadrres.exe中定义了如何对AlwaysOn可用性组经行Isalive检查的方法。和SQL Server群集的Resource DLL（sqsrvres.dll）一样，Hadrres.Dll也是由群集的RHS.exe进程加载的。由于AlwaysOn可用性组使用的是非Windows群集自带的资源类型和Resource DLL，默认情况下Windows群集单独产生一个RHS.exe来专门加载hadrres.dll。这样即使该RHS.exe由于异常而崩溃，整个群集的其他资源也不会受到影响。
那么AlwaysOn可用性组是如何执行Isalive检查来判断它的健康状况的呢？AlwaysOn也是使用了sp_server_diagnostics来检查可用性组的健康状况。Hadrres.Dll会建立并保持一个连接到SQL Server，并通过这个连接运行sp_server_diagnostics，然后不断的获得诊断信息。sp_server_diagnostics的评估结果会被用来和AlwaysOn可用组的FailureConditionLevel设置向比较，来约定是够符合发生故障转移的条件。一旦条件满足，则可用性组就被切换到新的可用性副本上。
有几点需要注意的是：
·        可用性组也是一种群集资源，但是它的HealthCheckTimeout属性默认是30000毫秒，而不像群集资源那样是60000毫秒。所以可用性组的获取诊断信息并记录到扩展事件日志的频率更高。
·        无论你在一个实例上配置多少个可用性组，该实例上只会运行一条sp_server_diagnostics语句来诊断所有的可用性组。如果每个可用性组的HealthCheckTimeout设置不同，Hadrres.Dll会挑选最小的那个值并除以3来作为sp_serevr_diagnostics返回诊断信息的间隔（max(5, min(HealthCheckTimeout/3))）。这个最小的HealthCheckTimeout值被称为"有效HealthCheckTimeout"。
·        sp_server_diagnostics只是检测实例的健康状态，而不是检测每个数据库的状态。所以如果当前SQL Server实例还能正常工作，但可用性组所包含的数据库发生诸如数据文件损坏、置疑等问题而不能被正常使用，sp_server_diagnostics是无法发现问题的。就算你为当前的可用性副本配置了自动故障转移，这种情况下也是不会触发故障转移的。
当Windows群集触发故障转移后，故障转移目标（原先的辅助副本）能够接管主副本角色，对自己管理的数据库进行恢复操作，使它们作为新的主数据库。原先的主副本如果在故障转移后还可用，就会成为辅助副本，它上面的数据库就成为了辅助数据库。
b.     AlwaysOn发现故障之后，是否会立刻触发故障转移呢？这取决于可用性副本的可用性模式和故障转移模式。
根据副本间数据同步的模式，可用性模式有两种：同步提交和异步提交。根据故障转移的方式，可用性副本也有两种故障转移模式：自动故障转移和手动故障转移。自动故障转移模式只有当副本的可用性模式为"同步提交"时才可以选择。
可用性模式和故障转移模式的组合形成了可用组的三种故障转移形式：自动故障转移、计划的手动故障转移（统称为"手动故障转移"）、强制手动故障转移（统称为"强制故障转移"）。
异步提交模式
同步提交模式以及手动故障转移模式
同步提交模式以及自动故障转移模式
自动故障转移
不支持
不支持
支持
手动故障转移
不支持
支持
支持
强制故障转移
支持
支持
支持


需要注意的是，故障转移形式是由主副本和故障转移目标两者的模式所共同决定的。两个副本间要发生自动故障转移，需要两者都配置为同步提交模式+自动故障转移模式。两者中有一个配置了手动故障转移，则自动故障转移就不能发生。两者间有一个配置了异步提交模式，则它们之间就只能发生强制故障转移。
在三种故障转移形式中，只有强制故障转移可能会丢失数据。自动故障转移和手动故障转移会保证数据的安全。为了防止丢失数据，自动故障转移和手动故障转移都要求故障转移目标是使用同步提交模式的辅助副本且当时处于SYNCHRONIZED状态。如果已处于SYNCHRONIZED状态的辅助副本发出强制故障转移命令，其行为与手动故障转移时的行为相同。对于异步提交模式的辅助副本，无论数据是否已经达到同步，它永远只会处于SYNCHRONIZING状态，于是它只能支持强制故障转移这一种形式。
c.      自动故障转移形式
自动故障转移使得AlwaysOn可用组成为了一种高可用方案，确保在丢失主副本之后快速使数据库再次变为可用。要发生自动故障转移，要满足这些条件：
·        当前主副本和一个辅助副本都设置为同步提交模式以及自动故障转移模式。
·        辅助副本必须与主副本同步。即辅助数据库处于SYNCHRONIZED状态。
·        主副本变得不可用，此时将发生自动故障转移。
当发生自动故障转移时，整个步骤是：
·        如果运行当前主副本的副本实例仍在运行，则它会将主副本和辅助副本的连接状态更改为 DISCONNECTED 并断开所有客户端的连接。
·        如果在故障转移目标副本上还有任何日志记录处于重做队列中，辅助副本会继续执行重做，以完成对辅助数据库的前滚操作。
·        完成前滚操作后，辅助副本就转换为了主副本，其数据库成为了主数据库。新的主副本将尽快回滚任何未提交的事务。
·        新的主副本在连接到一个辅助副本形成新的对话之前，会把自己置为 NOTSYNCHRONIZED状态。无论回滚操作是否已经结束，只要有辅助副本可以连接到新的主副本，主数据库就会转换为 SYNCHRONIZED 状态。
·        当原来的主副本解决了故障重新开始运行后，它会发现其他某个可用性副本现在变成了主副本，于是它就把自己转换为辅助副本，而其数据库将成为辅助数据库。当新的辅助数据库连接上新的主数据库后，辅助数据库就开始进行同步来赶上主数据库的日志末尾。
d.    手动故障转移形式
当主副本和辅助副本连接在一起并且数据库处于SYNCHRONIZED状态，就可以执行手动故障转移。如果辅助副本停止运行，主副本不会受到影响。如果主副本停止运行，辅助副本将进入一种特殊的角色--"RESOLVING"角色（注意，RESOLVING是可用性副本的一种角色，而不是它所处的状态）。此时该副本既不是主副本也不是辅助副本，但可以执行强制故障转移把辅助副本转换成主副本，不过可能会因此承受数据损失。
当发生手动故障转移时，整个步骤和自动故障转移基本是一样的。它们的区别仅仅是在"谁触发了故障转移"。
你有四种途径来执行手动故障转移：
·        通过Windows的故障转移群集管理器来切换可用性组所在的资源组。
·        通过T-SQL语句。
·        通过SQL Server Management Studio使用UI来进行手动故障转移。
·        使用Powershell脚本。
我们建议始终通过SQL Server Management Studio来执行包括手动故障转移在内的所有可用性组的操作，这样能有效地防止Windows故障转移群集管理器上的错误操作而导致的意外。
e.     强制故障转移形式
从数据安全的角度来讲，强制故障转移是一个风险很大的操作。一旦执行了强制故障转移，主副本尚未发送到原来的辅助副本的任何事务日志都会丢失。这意味着，新的主数据库可能会缺少一些最近提交的数据。需要特别注意的是，强制故障转移后，剩余的所有辅助副本上的辅助数据库都处于挂起状态。在最坏的情况下，你可能需要重新初始化所有的辅助副本才能重新恢复可用性组。举例来说，假设你有三个可用性副本，主副本A和一个辅助副本B是同步提交模式，另一个辅助副本C是异步提交模式。当主副本A和辅助副本B的日志都比辅助副本C更加新的时候（这很容易发生），你执行了强制故障转移把主副本转移到C上。于是新的主副本C的日志晚于其余两个副本，这使得副本A和B无论如何都无法继续和副本C的对话。要重新恢复三个副本的配置，你必须以某个副本上的数据库为基础，重新在三个副本上配置可用性组。
你只能通过SQL Server Management Studio来执行强制故障转移。在转移开始前，SQL Server Management Studio会通过向导来和你确认你是否已经了解且愿意接受强制故障转移可能带来的后果。
f.      多子网可用性组的故障转移
可用性组支持多子网环境，即可用性副本可以处于不同的子网当中。多子网的SQL Server群集一旦发生了故障转移，为了使得客户端能够更快的重新连接到新的活跃结点，你可以在连接字符串中使用MultiSubnetFailover参数并将其置为true。对于多子网的可用性组而言，在客户端程序中使用MultiSubnetFailover参数也能帮助客户端在可用性组发生不同子网间的故障转移时快速的恢复连接。要使用MultiSubnetFailover参数，除了客户端要使支持该参数的驱动程序外，还要使用TCP协议并通过Listener来连接可用性副本。
无论可用性组是单子网还是多子网，都建议在客户端的连接字符串中将MultiSubnetFailover设置为true。对于单子网的环境，MultiSubnetFailover能够为迁移至多子网环境做好预先准备。一旦发生这样的迁移，你无须再去更改连接字符串。
g.    Split Brain（大脑分裂）
在理论上，如果发生故障转移，原先的主副本会先离线，然后某个辅助副本会上线。网络里不会同时出现两个主副本。但是在意外情况下，如果原先的主副本还没有离线，新的主副本就上线了，那一个可用组就出现了两个主副本。客户端可以连接其中的任何一个，做数据修改动作。就像人的大脑，被分裂成了两个。所以这种情况被起名为Split Brain（大脑分裂），是AlwaysOn要坚决杜绝的。所以在可用性组资源的属性中，你还能看到一个叫作LeaseTimeout的属性。Windows群集服务会定期跟它认为的主副本通信。如果主副本在"Lease Timeout"之前没有收到Windows群集服务的消息，它就自认为自己已经被群集服务切换掉了。这个SQL Server会自动终止自己的运行。因为Windows群集服务在任何一个时间点只会认定一个主副本，所以这样的方法可以避免"大脑分裂"。
h.     连接的状态、可用性副本的状态和可用性数据库的状态
在前面的介绍中，你会发现AlwaysOn中的各种对象在不同的情况会处于各自不同的状态。如果你已经眼花缭乱，这里我们做一个小小的归纳。
连接状态：
·        Disconnected--说明辅助副本和主副本间已经断开了连接。
o   如果主副本发现辅助副本断开了和它的连接，在主副本上会将那些辅助副本上的辅助数据库标记为"未同步"，主副本等待辅助副本重新连接。
o   当辅助副本检测到它和主副本的连接断开后，辅助副本会尝试重新连接主副本。
·        Connected--辅助副本和主副本间连接正常。
可用性副本状态：
·        Not Synchronized--副本中的一个或多个数据库未同步或尚未连接到可用性组。
·        Synchronizing--正在同步副本中的一个或多个数据库。
·        Synchronized--辅助副本中的所有数据库均与主副本上的相应主数据库同步。
可用性数据库状态：
·        Not synchronizing
o   如果是主数据库处于该状态，说明该数据库未做好准备将其事务日志与相应的辅助数据库进行同步。
o   如果是辅助数据库处于该状态，说明数据库可能（1）由于连接问题或者重做失败，不再进行日志同步，（2）和主数据库的日志同步被"挂起"，（3）由于角色切换，正处于转换的中间状态。
·        Synchronizing
o   如果是主数据库处于该状态，说明该数据库已做好接受来自辅助数据库的同步请求的准备。
o   如果是辅助数据库处于该状态，说明该辅助数据库和主数据之间有正在进行同步的数据。
·        Synchronized
o   如果是主数据库处于该状态，说明它至少同步了一个辅助数据库。
o   如果是辅助数据库处于该状态，说明该数据库与相应的主数据库保持同步。
要注意，在异步提交模式下，可用性数据库和可用性副本永远不会处于"Synchronized"状态。
6.    创建一个AlwaysOn可用性组
a.      How to create an Availability Group?
                                         i.     T-SQL语句、
                                       ii.     Powershell脚本和
                                     iii.     SQL Server Management Studio的向导等方式来创建可用性组
b.     Steps in SSMS
                                         i.     Step 1 - SQL Server Configuration Manager打开SQL Server实例的属性并勾选"AlwaysOn High Availability"选项卡中的"Enable AlwaysOn Availability Groups"选项。你需要在所有将成为可用性副本的实例上都执行这个操作。每个实例都需要是一个建立在群集环境上的单机或群集实例。
                                       ii.     Step 2 - 使用SQL Server Management Studio连接任意可用性副本实例，在Availability Group上单击右键，选择"New Availability y Group Wizard…".
                                     iii.     Step 3 - 在新建可用性组的向导中，输入可用性组的名字。这个名字会成为群集中可用组性资源的名称，以及资源组的名称。
                                     iv.     Step 4 - 勾选那些你想要添加到可用组中的数据库。在一个可用性组里最多可以添加100个数据库。数据库要满足的要求包括：
·        需要是用户数据库，系统数据库不能加入可用性组。
·        数据库可以读写。只读的数据库不允许加入可用性组。
·        数据库要处于多用户模式。
·        数据库没有使用AUTO_CLOSE。
·        数据库的恢复模式是完全恢复。
·        数据库已经做过完整备份。
·        不属于任何其他的可用性组。
·        数据库上没有配置数据库镜像。
                                       v.     Step 5 - 在"Specify Replicas"这个步骤的"Replicas"选项卡中，你可以把所有你想要的可用性副本都添加进来（最多可以有5个可用性副本），并且指定每个可用性副本的模式：
·        同步提交模式。该模式决定了主副本和辅助副本之间是否要保持完全同步。最多可以有3个同步提交副本。
·        自动故障转移模式。该模式决定了当主副本失败时是否将可用性组转移到指定的辅助副本上。最多可以将两个可用性副本配置为自动故障转移。
·        可读辅助副本。该模式决定了该副本作为辅助副本时是否可读。
                                     vi.      Step 6 - 在Endpoints选项卡中，你会看到向导会为每个副本创建一个端点。 AlwaysOn使用的端点和数据库镜像的端点是完全一样的，因此默认使用的端口号也是5022。
                                   vii.     Step 7 - AlwaysOn允许在辅助副本上执行备份操作。
在一台非常繁忙的服务器上做备份操作可能会给I/O和CPU（使用备份压缩时）带来一定的压力。由于AlwaysOn各个副本间的数据应该都是一致的，如果将备份工作转移到已同步或正在同步的辅助副本上完成，不但能得到跟主副本上一样的数据，而且也可以使得主副本有更多的资源用于处理来自应用程序的工作负载。这是AlwaysOn能为我们带来的一个性能上的提升。
辅助副本上可以执行日志备份和数据库完整备份。不过完整备份（BACKUP DATABASE）仅支持数据库、文件或文件组的"仅复制"备份（Copy-only backup）。仅复制备份不影响日志链，也不清除差异备份位图。辅助副本不支持差异备份。
AlwaysOn允许数据库管理员设置他希望备份在哪个副本上执行。其工作原理是：AlwaysOn引入了一个函数sys.fn_hadr_backup_is_preferred_replica。在TSQL脚本里运行这个函数，就可以判断出当前运行的这个副本，是否是希望做备份的那个副本。你可以在可用性组的所有副本上都创建相同的备份作业，且这些备份作业使用同样的日程安排来运行。在每个副本的备份作业脚本中，你需要调用 sys.fn_hadr_backup_is_preferred_replica 函数，来确定当前副本是否为首选的备份副本。如果运行该脚本的实例是备份的首选副本，则函数将返回 1；否则，函数返回 0。当函数返回"1"时，就可以继续运行备份作业。
IF (NOT sys.fn_hadr_backup_is_preferred_replica(@DBNAME)) 
BEGIN 
      Select 'This is not the preferred replica, exiting with success'; 
      RETURN 0  
END 
BACKUP DATABASE @DBNAME TO DISK=<disk>
   WITH COPY_ONLY; 

通过这样的逻辑，即使同一时间多个副本都在运行备份作业，实际上只有一个作业将前进到真正的备份阶段。

sys.fn_hadr_backup_is_preferred_replica 函数的返回值是由Backup Preferences选项卡上的下列设置决定的：
（1）Prefer Secondary
如果有任何辅助副本可用，备份都应该在辅助副本上执行。如果主副本是唯一还处于在线状态的副本，那么备份才会在主副本上执行。
（2）Secondary Only
备份永远不会在主副本上执行。如果所有辅助副本都不可用，备份就不会进行。
（3）Primary
备份永远在主副本上执行。主要用于那些不能在辅助副本上执行的备份类型，如差异备份。
（4）Any Replica
在选择要执行备份的副本时备份作业忽略可用性副本的角色。 不过，备份作业可能会根据其他因素来决定使用哪个副本来做备份，例如每个可用性副本的备份优先级，同步状态以及连接状态。
另外，在Backup Replica Priorities设置区内，你可以为每个副本设定不同的优先级。当在辅助副本上执行备份时，会根据副本的优先级及一些其他因素来选择合适的辅助副本。你还可以Exclude Replica - 如果你想要某个可用性副本永远不会执行备份。
                                 viii.     Step 8 - 在Listener选项卡中，你可以选择是否要为可用性组创建一个Listener。创建了Listener后，可用性组就有了一个虚拟网络名。应用程序通过这个虚拟网络名就可以连接到主副本实例。如果你在这里选择不创建Listener，在可用性组开始运行后你依旧可以随时添加一个Listener
                                     ix.     Step 9 - 选择如何在其他的副本上初始化可用性组中的数据库。
（1）Full
你可以选择让向导自动在其他的副本上初始化数据库。这要求你提供一个当前的服务器上的共享目录。向导会对自动数据库做完整备份和日志备份并将备份文件存放到这个目录。其他的副本通过这个共享目录获得数据库的备份并在各自的实例上进行还原。这个和日志传送进行初始化的步骤很像。这里你要确保每个副本实例的服务账户对共享目录和本地目录有合适的读写权限。另外要注意，通过这种方式初始化，你要确保主副本上存放主数据库文件的路径在辅助副本上也存在。
（2）Join only
如果你已经手动在各个辅助副本上还原了数据库，那么你就可以使用这个选项，将各个辅助副本直接加入到可用性组中。这样你可以控制初始化可用性组所花费的时间，而且也可以把数据库文件放置在辅助副本上的任何目录，无须和确保辅助数据库和主数据库具有一样的文件路径。这个初始化方式类似于数据库镜像。
（3）Skip initial data synchronization
完全跳过这个步骤。你需要之后手动的在主副本上对数据库做完整备份和日志备份并还原到所有辅助副本上，然后通过Powershell脚本，或SQL Server Management Studio的向导或者T-SQL语句把数据库加入到可用性组中。
然而无论你选择什么方式，如果有可能最好还是确保主数据库和副本数据库的文件路径一致。在可用性组可以运作后，当你为主数据库添加一个文件时，辅助数据库也会将文件添加在相同的路径。如果主副数据库路径不一致，就可能发生辅助数据库添加文件失败的情况，这会直接导致可用性副本进入NOT SYNCHRONIZING状态。
                                       x.     Step 10 - 在创建可用性组之前做一次验证，确保之前的配置都有效且符合要求。
                                     xi.     Step 11 - 最后终于创建完成，单击"Close"按钮结束整个向导。
向导完成后，在SQL Server Management Studio中就可以看到你所创建的可用性组的各种信息，包括有哪些可用性副本、每个副本当前的角色、有哪些数据库、虚拟网络名（Listener的名字）等。在创建完可用性组之后，你可以随时对可用性组中的各种设置进行更改，可以添加或删除可用性组中的数据库，添加或删除可用性副本，更改可用性副本的同步提交设置、自动故障转移设置、可读设置、备份首选项设置等，也可以添加或删除该可用性组的Listener，这些都是可以通过SQL Server Management Studio的UI来完成。
                                   xii.     Step 12 （optional） - check 可用性组中的对象 in Windows Cluster Manager
如果打开Windows群集管理器，你会看到可用性组对应的资源组。在本节的例子中，我们创建了一个有Listener的可用性组，Listener的IP地址是10.10.10.175，名称是testAGvname。于是，在资源组中，你会看到三个资源：虚拟IP地址、虚拟网络名、可用性组。
7.    可读的辅助数据库
要让只读操作能"透明"地被自动转向辅助副本，必须解决下面三个问题：
a.  客户端要标明自己发来的操作是"只读"操作。这个判定是程序开发员在编写程序的时候，通过ApplicationIntent关键字指定的。而不是SQL Server端来判定的。
Server=tcp:MyAgListener,1433;Database=Db1;IntegratedSecurity=SSPI;ApplicationIntent=ReadOnly;MultiSubnetFailover=True 
b.  辅助数据库要被配成可读模式。
c.  客户端的连接，要能够被重定向到可读辅助副本。AlwaysOn是用"只读路由"机制来实现的。
辅助数据库上可能出现的性能问题
一个可读的辅助副本可能会同时受到读操作和写操作。读操作来自于直接连接它的客户端或者通过只读路由被重定向到它的客户端。而写操作只会来自于主数据库和辅助数据库之间的数据库同步。辅助数据库只有在重做日志的时候才会发生数据更改。客户端无法直接在辅助数据库上执行数据修改操作。
像其他所有数据库一样，只读辅助数据库也有可能遇到性能问题。由于其工作方式的特殊性，其性能问题也有所不同。
（1）使用行版本控制来消除阻塞问题
由于存在读写同时发生的可能性，在辅助数据库上可能会发生阻塞问题。为了保障读操作的稳定运行和性能，AlwaysOn使用行版本控制来消除辅助数据库上的阻塞问题。对辅助数据库运行的所有查询都会被自动运行在快照隔离级别之下。即使你显式的为查询设置了其他事务隔离级别，情况也是如此。此外，所有锁定提示（Lock Hint）都将被忽略。这些都有助于消除了读写操作互相争抢锁定数据所造成的阻塞问题。
虽然由于快照隔离级别的原因，读操作不会在数据上占用共享锁，但是快照隔离级别会导致读操作占用Sch-S锁。Sch-S锁还是会阻塞那些在辅助数据库上重做的DDL语句。因为那些DDL语句需要占用Sch-M锁，而Sch-M锁和Sch-S锁是互斥的。
除了阻塞，读操作的Sch-S锁还可能造成和写操作之间的死锁问题。为了保证数据同步的完整性，AlwaysOn规定来自于数据同步（重做日志）所做的写操作永远不会被选为死锁的牺牲者，无论该写操作的代价是多小。
（2）系统资源的争抢
如果读操作比较复杂，其所带来的CPU和IO的负载也可能会影响辅助数据库上重做操作的性能。因此，如果有一个需要长时间运行的只读操作，最好还是安排在非业务高峰时间来运行会比较好。
（3）索引
为了优化在可读辅助数据库上所执行的查询语句的性能，需要在数据库上创建合适的索引，由于无法在辅助数据库运行创建索引的命令，因此需要在主数据上创建所需要的索引，然后让同步操作把索引给同步到辅助数据库上。
统计信息
统计信息对于查询操作的性能也有非常大的影响。正确的统计信息才能产生优化的执行计划。和索引一样，你只能在主数据上创建和维护统计信息，然后将统计信息的变更同步到辅助数据库上。当主数据上没有统计信息，或者统计信息已经很过时不再用适用于生成优化的只读操作执行计划的时候，你无法在辅助数据库上创建或更新统计信息。但是，辅助副本会在tempdb 中创建和维护辅助数据库的"临时统计信息"，用它们来替代过时的永久统计信息。一旦主数据库上的永久统计信息被更新了，辅助数据库上的永久统计信息也会被更新。这时，辅助数据库就会开始使用更新的永久统计信息，因为该信息比临时统计信息要新。
临时统计信息的名称会带有后缀"_readonly_database_statistic"，用于将其和主数据库上保存的永久统计信息区分开来。后缀_readonly_database_statistic是保留关键字，在主数据库上手动创建统计信息时不能使用此后缀。只有SQL Server本身才能够创建和更新辅助数据库上的临时统计信息。但是，你可以在辅助副本的tempdb中使用DROP STATISTICS Transact-SQL 语句删除临时统计信息。你也可以在辅助副本上查询sys.stats 和 sys.stats_columns 视图，来监视统计信息的状况。 sys_stats 包含一个 is_temporary 列，用于指示哪些统计信息是永久的，哪些统计信息是临时的。
因为临时统计信息保存在 tempdb 中，所以重启 SQL Server 服务会导致所有临时统计信息丢失。如果可用性组发生故障转移，所有辅助副本上临时统计信息都会被删除。
可读辅助副本会占用一部分tempdb的空间。临时统计信息，以及快照隔离级别的行版本信息都保存在辅助副本的tempdb中。因此对于辅助副本的tempdb需要进行合理的配置和优化，用以优化辅助副本的性能表现。
8.    监视AlwaysOn可用性组的运行状态
a.     系统视图和动态管理视图
                                         i.     可用性组所在的Windows故障转移群集
sys.dm_hadr_cluster
sys.dm_hadr_cluster_members
sys.dm_hadr_cluster_networks
sys.dm_hadr_instance_node_map
sys.dm_hadr_name_id_map
                                       ii.     可用性组
sys.availability_groups
sys.availability_groups_cluster
sys.dm_hadr_availability_group_states
                                     iii.     可用性副本
sys.availability_replicas
sys.availability_read_only_routing_lists
sys.dm_hadr_availability_replica_cluster_nodes
sys.dm_hadr_availability_replica_cluster_states
sys.dm_hadr_availability_replica_states
sys.fn_hadr_backup_is_preferred_replica
                                     iv.     可用性数据库
sys.availability_databases_cluster
sys.databases（添加了replica_id，group_database_id列来兼容AlwaysOn）
sys.dm_hadr_auto_page_repair
sys.dm_hadr_database_replica_states
sys.dm_hadr_database_replica_cluster_states
                                       v.     可用性组的Listener
sys.availability_group_listener_ip_addresses
sys.availability_group_listeners
sys.dm_tcp_listener_states
b.    性能计数器
AlwaysOn引入了两个性能监视器的对象：SQLServer:Availability Replica和 SQLServer:Database Replica。每个对象下面都有一些性能计数器用来让你了解当前可用性组运行的健康状况和性能表现。
Counter
Primary
Secondary
Availability Replica: Sends to Replica / Sec
X
X
Availability Replica: Receives from Replica / Sec
X
X
Availability Replica: Bytes Sent to Replica / Sec
X
X
Availability Replica: Bytes Received from Replica / sec
X
X
Availability Replica: Sends to Transport / sec
X
X
Availability Replica: Bytes Sent to Transport / sec
X
X
Availability Replica: Resent Messages / sec
X
X
Availability Replica: Flow Control Time
X

Availability Replica: Flow Control / sec
X

Database Replica: Redo Bytes Remaining

X
Database Replica: Log Bytes Received / sec

X
Database Replica: File Bytes Received / sec

X
Database Replica: Log Remaining to Undo

X
Database Replica: Total Log Requiring Undo

X
Database Replica: Redone Bytes / sec

X
Database Replica: Recovery Queue

X
Database Replica: Log Send Queue

X
Database Replica: Transaction Delay
X

Database Replica: Mirrored Write Transactions / sec
X


c.     Dashboard
一旦你创建了一个可用性组，就可以使用AlwaysOn的Dashboard。Dashboard用来监视可用性组、副本和数据库的健康状况。Dashboard是一个将各种信息集中在一体的报表，它不但本身包含丰富的信息，而且通过它你还能转向到其他的日志（AlwaysOn_health事件、SQL错误日志、Windows群集日志以及Windows事件日志等），以获得更进一步的分析信息。
要打开Dashboard，你只需要在SQL Server Management Studio中选中所想要监视的可用性组，然后右击选择"Show Dashboard"命令。
d.    AlwaysOn_health会话
AlwaysOn_health会话是SQL Server 2012自带的扩展事件对话，如图3-31所示。当你通过SQL Server Management Studio中的向导创建可用性组之后，这个会话会被启动，如果你使用的是T-SQL或者Powershell脚本创建可用行组，那么该会话不会启动。


e.  SQLDIAG扩展事件日志
前面我们已经讲过SQL Server 2012故障转移群集使用sp_server_diagnostics来获取诊断信息，并且会把sp_server_ diagnostics返回的信息也会被记录到SQLDIAG扩展事件日志文件中。详细信息参见2.1.6节。
sp_server_diagnostics也负责AlwaysOn可用性组的健康状况检查。同样的，sp_server_diagnostics返回的信息依旧会被记录到SQLDIAG日志中。我们也可以通过检查SQLDIAG文件中记录的信息来对可用性发生的异常状况进行排查。例如，我们可以通过SQLDIAG中记录的SQL Server实例的资源使用情况来判断是否是由于资源瓶颈导致了可用性发生了故障切换。
SQL Server 2012 Management Studio能够直接打开后缀为.xel的扩展事件日志文件，如图3-32所示。打开日志之后，你不但能够浏览事件信息，而能对它们进行聚合、分组、过滤等操作。
9.  Summary
功    能
故障转移群集
日志传送
数据库镜像
事务复制
AlwaysOn
保护级别
实例级
数据库级
数据库级
数据库对象级
数据库级
是否有
数据损失
/
可能有少量
数据损失
无数据损失
（同步模式）
可能有少量
数据损失
无数据损失
（同步提
交模式）
自动故障转移
是
否
是（高可用
操作模式）
否
是（自动故障
转移模式）
故障转移后
是否可逆
是
否
是
否
是
对客户端
是否透明
是，自动重连接
到相同IP的
另一个结点
否
是，自动
重定向
（需要驱
动程序支持）
否
是
停机时间
约等于SQL Server
服务重启的
时间+数据库
恢复时间
较长
约等于数据库
恢复时间
较长
约等于数据库
恢复时间
多个备用
数据副本
否
是
否
是
是（最大4个）
备用数据
副本可读
/
是
否
是
是
能抵御
用户误操作
否
是
否
否
否
能抵御磁
盘故障
否
是
是
是
是
是否有特定
硬件要求
Windows群集
无
要求有较好的
磁盘和网络
无
Windows群集
对性能
的影响
低
中
中
高
中
其他功能
/
自动页面修复
/
冲突解决，
双向数
据同步等
自动页面修复，
只读路由，辅助
数据库备份，
辅助数据
库执行DBCC命令
版本支持
SQL Server 2000
及以后
SQL Server 2000
及以后
SQL Server
2005
及以后
SQL Server
2000
及以后
SQL Server 2012