因为篇幅原因，AlwaysOn可用性组被拆成了两部分：理论部分和实战部分。而实战部分又被拆成了准备工作和AlwaysOn可用性组搭建。
三篇文章各自的链接：
SQL Server ->> 高可用与灾难恢复（HADR）技术 -- AlwaysOn（理论篇）
SQL Server ->> 高可用与灾难恢复（HADR）技术 -- AlwaysOn（实战篇）之建立活动目录域、DNS服务器和Windows故障转移群集（准备工作）
SQL Server ->> 高可用与灾难恢复（HADR）技术 -- AlwaysOn（实战篇）之AlwaysOn可用性组搭建
前言
SQL Server 2012引入了全新的HADR技术 -- AlwaysOn。AlwaysOn可谓是集SQL Server 2012之前各种HADR的优点于一身，比如故障转移群集的高可用行，日志传送的数据副本可访问，镜像技术的高同步和自动页面修复。同时它的可用性组概念又规避了故障转移群集必须是整个实例完全转移的“缺点”。在架构上的可拓展性也是其一大优势。多只读辅助副本来帮助减轻主副本的数据读取负载对于某些大型应用是一大利器。以及可以再与故障转移群集相结合来实现更高层次的高可用也体现了其对于大型应用的支持。
AlwaysOn可用性组的前提条件
1）服务器不能是域控制器
2）服务器OS需要是Windows Server 2008或以后的版本
3）服务器需要是Windows故障转移群集的节点
AlwaysOn可用行组数据库的要求
1）只能是用户数据库，这点和镜像技术是一样的；
2）可读写；
3）多用户模式；
4）完全恢复模式；
5）做过完整备份；
6）不属于其他的可用性组；
重要特性
1）多用户数据库为可用性单位
2）虚拟网络服务器名
3）三种故障转移模式
4）最多可以有8个辅助服务器（SQL SERVER 2012最多4个，SQL SERVER 2014最多8个）
5）主服务器和辅助服务器数据加密和压缩
6）自动修复某些类型的数据页面损坏
7）辅助服务器数据只读，分担一部分主服务器负载
8）辅助服务器可以执行备份和DBCC命令
9）AlwaysOn专属Dashboard、DMV、Performance Counter和Extended Events支持
与其他高可用与灾难恢复（HADR）技术对比
SQL Server 2012之前的版本提供的高可用与灾难恢复（HADR）技术众多，但是难有一种是“完美”或者说可以被看成是一种解决方案的。各自都存在一些优缺点。
集群：优点是可以故障转移；缺点是共享了同一份数据，无副本，一旦数据出问题就完全不可访问；自动故障转移是整个实例级别；
日志传送：最老的HADR技术，依赖于事务日志。优点是一个数据库可以同时有一个或多个数据库副本，而且还是可以访问的，可以实现读写分离分担主服务器压力，缺点是一旦灾难发生，会出现短暂的数据丢失。不支持自动故障转移。恢复时间相当长。相当于把副本备份然后还原到当前的生产数据库，在承当数据丢失的情况下，前提是故障是数据库级别，不能是硬件或者实例（Windows服务）级别。
事务复制：这个不是灾难恢复技术，只是作为高可用技术的一种。依赖于事务日志。优点是高可用的对象可以细化到表级别，也可以把它看成是ETL技术的一种选择，用于分发数据到其他的订阅节点是非常好的技术，对于实现读写分离也是一个选择。缺点是一旦灾难发生，会出现数据丢失，而且会给服务器增加负担。和日志传送一样依赖于事务日志，注定很多缺点两者都相似。
数据库镜像：SQL Server 2005后的HADR技术。优点是可以保证不会出现任何数据丢失，也支持故障转移；缺点是副本不可访问，仅在故障转移时才可访问，无法读写分离减轻服务器压力。
AlwaysOn：可以说它就是对其他高可用与灾难恢复（HADR）技术的集大成者，吸取了数据库镜像的数据库级别的故障转移，日志传送的副本可访问（只读）特点，故障转移集群的多节点和自动故障转移和检测的能力。它不像故障转移集群必须是对整个实例级，也不像数据库镜像和日志传送只能对单个数据库，AlwaysOn的核心思想是“可用性组”，每个可用性组包含的是一个或若干个数据库，然后把整个可用性组一起进行故障转移。
《SQL Server 2012实施与管理实战指南》一书中总结了这5种技术的一些特点。
AlwaysOn和Windows群集的关系
AlwaysOn的故障转移特性是基于Windows群集实现的。因为故障侦测和转移也具备了一些Windows群集的特性：
1）同一可用性组的可用性副本必须处在同一Windows群集内
2）同一可用性组的可用性副本必须运行在不同的Windows节点上
3）如果某个可用性副本是一个SQL群集实例，同一SQL群集的其他非活跃节点上安装的任何其他SQL实例不能作为它的辅助副本
4）一个数据库只能属于一个可用性组
使用虚拟网络服务器名和Listener，由Listener来决定是否Failover
Listener决定把客户端请求是否重定向到其他的辅助副本上。它本身是不支持SQL Browser的，因为使用虚拟网络服务器名本身就是使用默认实例的一种用法。既然是使用默认实例，那也就不存在命令实例和其端口号一说了。那SQL Browser也就没用了。如果本身使用虚拟网络服务器名，每个副本都使用默认实例。
架构流程图
可用性模式
异步提交模式：事务被提交前无需先等待某个辅助副本将事务日志固化。这种模式下一般辅助数据库都是出于SYNCHRONIZING状态。这种模式一般适用于那些主副本和辅助副本物理距离远的情况。
同步提交模式：事务被提交前需要先等待某个辅助副本将事务日志固化。这种模式下辅助数据库会出于SYNCHRONIZED状态。
AlwaysOn事务提交流程
可用性副本连接状态
DISCONNECTED: 主副本和辅助副本间互相发送ping。默认超时时间为10秒。最低为5秒。建议10秒甚至更长，避免SQL Server过于繁忙。
可用性模式对事务复制的影响
事务复制的Log Reader不会去处理那些尚未复制到辅助副本的日志记录。因为如果事务复制处理了这些日志，就会造成订阅服务器的记录比辅助服务器的数据新鲜度要新。这时一旦发生Failover，辅助副本就会被自动切换成主副本，这样就会出现辅助副本的数据比订阅服务器的记录旧。这种情况是不允许。
故障转移形式
AlwaysOn通过加载了一个名为hadrres的DLL。因为AlwaysOn其实也是依托Windows群集服务，所以其实也是由RHS.exe进程来加载这个DLL。从名字可以看出是High Availibility Disaster Recovery Resource的简称。也就是其实这条进程是用于控制可用性组资源的上下线的。
AlwaysOn和SQL Server的群集其实是一样通过调用存储过程sp_server_dianostics来检查群集的状态。调用方法存在hadrres.dll中。hadrres.dll开启一条线程连接到SQL Server并且一直保持，不断调用这个存储过程来获取SQL Server的状态信息。返回结果和AlwaysOn可用性组的FailureConditionLevel配置进行对比，以决定是否切换到辅助副本上。
HealthCheckTimeout间隔为30000毫秒。一个实例只会运行一次sp_server_dianostics，不管有多少个可用性组。多个可用性组将选择最小的间隔设置值值除以3作为生效的间隔。sp_server_dianostics只是检查实例的状态，而不是检查数据库的状态。
故障恢复模式：自动，手动和强制
AlwaysOn是否触发故障转移是由故障恢复模式和可用性模式决定的
自动故障转移：
1）主副本和辅助副本连接状态置为DISCONNECTED并且断开所有客户端连接；
2）等待辅助副本把日志操作前滚（redo）完毕
3）辅助副本切换为主副本，此时如果没有任何可用辅助副本，主副本的可用性组状态就是NOTSYNCHRONIZED
4）原来的主副本变成可用后变成辅助副本，同步现有主副本后面生成的日志记录
手动故障转移：
当主副本和辅助副本处于SYNCHRONIZED状态时，可以执行手动故障转移。此时不会出现数据丢失。
强制故障转移
当主副本停止，辅助副本进入“RESOLVING”角色。此时RESOLVING角色既不是主副本也不是辅助副本。如果执行强制故障转移把辅助副本转成主副本，可能出现数据丢失。而且，其他副本在执行完强制故障转移之后可能需要重新配置可用性组，因为强制故障转移形式导致新的主副本不能确定与其他副本间的数据一致性。
手动故障转移的途径：
1）T-SQL语句
2）SSMS UI界面
3) PowerShell
多子网可用性组的故障转移
客户端应用程序使用MultiSubsetFailover来支持多子网可用性组的故障转移，配置Listener
Split Brain（大脑分裂）
大脑分裂是指发生故障转移时存在新的主副本上线和旧的主副本仍然在线存在的这种同时出现两个主副本的情况。为了避免这种情况，AlwaysOn可用性组有一个叫LeaseTimeout，意思是如果主副本在LeaseTimeout之前没有收到Windows群集服务的消息，就会自动终止SQL Server的运行。因为其实主动权在Windows群及服务手中。它认定故障转移发生并转向另外的新的主副本，从而不发生通信消息给旧的主副本。LeaseTimeout很快就到，这样旧的主副本就会终止自己的服务。从而避免大脑分裂。
只读辅助数据库
辅助副本上的数据库是可以被配置成只读，然后通过AlwaysOn的只读路由功能将只读请求重定向到只读辅助副本上，从而已经分担主副本的工作负载。鉴于SQL Server允许最多可以有6个辅助副本，也就是意味着我们最多可以有6个只读辅助数据库来分担读的压力。当然越多的辅助副本，数据滞后的可能性就越大，因为每个辅助副本的负载都不尽相同，与其增加多副本，倒不如把资源集中在两个或者三个副本上。建议不要超过4个副本。把主副本和辅助副本都放置在同一局域网（同一台交换机相连），配置主副本和辅助副本的可用性模式为异步提交模式。虽然这样数据滞后的发生可能性会增大，也就是数据出现延迟。这里其实是有两种方案。一种是多个辅助副本，每个副本（包括主副本和辅助副本）的硬件配置相同（参考了携程的架构设计），而且把辅助副本的数量保持在2个内。另外一种是主副本和辅助副本的硬件配置不相同，根据其角色的特征选定硬件，这种可以参考携程的数据库架构。前者的好处是可以把可用性模式设置为同步提交模式，让可用性数据库的数据延迟降至最低。这是基于相同的硬件和处在局域网高速网络的条件考虑下做出的判断。加上限定了尽可能少的辅助副本来避免过多副本造成的数据滞后影响。理论上是可以。不过即便如此，数据的延迟也肯定还是会出现。最重要的一点，也是缺点，就是硬件代码太高了。容易造成硬件浪费。如果不是大型应用，而且对数据实时性的要求又很高，可以考虑这套做法，也就是把资源都尽量集中在两个或者三个机器或者群集上。第二种做法是主副本使用SAN存储结构，加上SQL Failover群集，多个辅助副本使用SSD存储结构保证数据读取和写入的速度，可用性模式配置成异步，最后加上负载均衡硬件机器来分散数据读取请求。可以参考《数据库技术与应用专场-03AlwaysOn技术在携程核心数据库的应用》。对于整个架构我唯一处在的疑问在于，配置成异步提交模式以为着会出现数据延迟。而携程的做法是通过一张代表可用性资源组时间戳的表来代表数据的新鲜度，然后应用程序在读取辅助副本数据的时候检查这张表以判断是否超过数据延迟的容许程度，以决定是否把数据读取访问返回给主副本。如果可以有效地控制好数据延迟的上限，那也可以接受。因为这样假设一旦出现N个线程排队等待修改同一行数据的情况，这个时候交易事务提交后到了主副本中检查数据行的数据版本（提交表单中带有的，来自于辅助副本上）和数据库中的当前行是否一致，不一致则说明数据过期，这个时候事务失败。其实也就是要结合应用程序和数据库技术，最后需要承当起一定的代价。我是这么看的。
SQL SERVER实现只读辅助数据库的重导向依靠的是：
1）它的“只读路由”功能；
2）辅助数据库配置为只读模式；
3）应用程序发起连接时指定了ApplicationIntent为READONLY。
ApplicationIntent
目前支持ApplicationIntent的数据库驱动有：SQLNCLI11 ODBC和OLEDB、.NET FRAMEWORK的SQLClient和JDBC for SQL Server 4.0
只读路由
SQL Server的只读路由功能会帮助你分流一部分的读取请求去到辅助数据库上。但是需要说明，在多个辅助数据库的情况下，到底最后面会去到哪个辅助数据库上是会收到路由配置和副本的状态影响的。所以说本身SQL Server自己是没有办法实现负载均衡。要实现比较真实的负载均衡，你需要依靠专业的负载均衡机器来帮助实现（通过直接访问实例名），或者通过应用程序层面编写一套自己的算法来分摊负载。
主副本的连接访问类型：ALL -- 默认，允许读写；READ_WRITE -- 不允许连接字符串带有Application_Intent = Readonly
辅助副本的连接访问类型：ALL -- 只是为了满足那些无法使用Application_Intent的客户端，其实无论如何只要尝试修改数据都会报错；READ_ONLY -- 为了支持只读路由自动分流数据读取；NONE -- 不接受任何访问请求；
只读路由的工作前提是Application_Intent = READONLY和使用Listener来连接可用性组。
辅助数据库上的潜在性能问题
阻塞和死锁
由于辅助数据库需要和主数据库进行数据同步，写入操作是几乎可能不间断的发生，而又因为可能同时也是一个只读的数据库，所以锁的冲突、阻塞和死锁是潜在的问题。阻塞问题在AlwaysOn是有行版本控制来解决的。所有对辅助数据库的数据查询都运行在快照隔离级别下。即便如此，查询还是会申请架构共享锁（Sch-S），所以还是存在和DDL语句相冲突。死锁也是可能发生的，不过AlwaysOn的事务日志重写是优先级别高而不可能被选为牺牲者。
行版本控制和临时统计信息带来的Tempdb的空间增长
行版本控制和临时统计信息可能带来的Tempdb的空间增长。需要对Tempdb的合理配置，比如Growth和Maximum Size的配置，数据文件数量的配置，文件location的选择。
监控AlwaysOn可用性组的运行状态
1）系统视图和动态管理视图（DMV）
实例级别的：
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
可用性组级别：
sys.availability_groups
sys.availability_groups_cluster
sys.dm_hadr_availability_groups_states
可用性副本级别：
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
可用性数据库级别：
sys.availability_databases_cluster
sys.databases
sys.dm_hadr_auto_page_repair
sys.dm_hadr_database_replica_states
sys.dm_hadr_database_replica_cluster_states
与可用性组的Listener相关
sys.availability_group_listener_ip_addresses
sys.availability_group_listeners
sys.dm_tcp_listener_states
2）性能计数器
SQL Server:Availability Replica
SQL Server:Database Replica
3）Dashboard
4) AlwaysOn_health会话（Extended Events）
5）SQLDIAG拓展事件日志
理论篇到此就结束了。接下来的实战篇因为篇幅原因被拆成了两部分：1）活动目录域、DNS服务器和Windows故障转移群集；2）AlwaysOn可用性组搭建；
参考：
《SQL Server 2012实施与管理实战指南》
SQL Server 2012 - High Availability - AlwaysOn in Real-life
Prerequisites, Restrictions, and Recommendations for AlwaysOn Availability Groups (SQL Server)
Windows Server Failover Clustering (WSFC) with SQL Server
SQL Server 2012 AlwaysOn High Availability and Disaster Recovery Design Patterns