一、AlwaysOn简介
AlwaysOn可用性组是SQL Server 2012中提供的全新功能，确保了应用程序数据的可用性，实现零数据丢失。AlwaysOn可用性组技术融合了数据库群集和数据库镜像的优点，此技术的一大好处是提供非共享存储，可以避免因为存储的单点故障而造成的整个可用性方案失效。
AlwaysOn可用性组基于数据库(组)级别，是将一组用户数据库(可以是一个或多个)划到一个组中。每组可用性数据库都由一个可用性副本承载。可用性副本包括一个主副本和一到四个辅助副本。 主副本用于承载主数据库，辅助副本则承载一组辅助数据库并作为可用性组的潜在故障转移目标。主副本使主数据库可用于客户端的读写连接，实现对数据库的更改操作。 同时在数据库级别进行同步。 主副本将每个主数据库的事务日志记录发送到每个辅助数据库。 每个辅助副本缓存事务日志记录，然后将它们还原到相应的辅助数据库。 主数据库与每个连接的辅助数据库独立进行数据同步。 因此，一个辅助数据库可以挂起或失败而不会影响其他辅助数据库，一个主数据库可以挂起或失败而不会影响其他主数据库。
部署 AlwaysOn 可用性组需要一个 Windows Server 故障转移群集 (WSFC) 群集。 给定可用性组的每个可用性副本必须位于相同 WSFC 群集的不同节点上。 部署AlwaysOn可用性组时，系统会为每个可用性组创建一个 WSFC 资源组。WSFC 群集将监视此资源组，判断节点间的状态，以便评估主副本的运行状况。 当发生失败时实现故障的转移，针对 AlwaysOn 可用性组的仲裁基于 WSFC 群集中的所有节点，而与某一给定群集节点是否承载任何可用性副本无关。
用户可以通过创建一个可用性组侦听器来提供到给定可用性组的主副本的客户端连接。 “可用性组侦听器”采用DNS名称的方式连接给定可用性组的资源，以便将客户端连接定向到相应的可用性副本。
对于每个可用性副本，AlwaysOn所支持的事务提交模式分为同步提交模式或异步提交模式。在异步提交模式下，主副本无需等待确认异步提交辅助副本已强制写入日志，便可提交事务。 异步提交模式可最大限度地减少辅助数据库上的事务滞后时间，但允许它们滞后于主数据库，因此可能会导致某些数据丢失。此可用性模式是一种灾难恢复解决方案，适合于可用性副本的分布距离较远的情况;所谓同步提交模式是指在提交事务之前，同步提交主副本要等待同步提交辅助副本确认它已完成强制写入日志。 同步提交模式可确保在给定的辅助数据库与主数据库同步时，充分保护已提交的事务。 这种保护的代价是延长事务滞后时间。此可用性模式相对于性能而言更强调高可用性和数据保护，当主副本和辅助副本距离较近时可以使用此方法，解决时时同步的问题。
当Windows群集触发故障转移后，故障转移目标（原先的辅助副本）能够接管主副本角色，对自己管理的数据库进行恢复操作，使它们作为新的主数据库。原先的主副本如果在故障转移后还可用，就会成为辅助副本，它上面的数据库就成为了辅助数据库。
故障转移形式是由主副本和故障转移目标两者的模式所共同决定的。两个副本间要发生自动故障转移，需要两者都配置为同步提交模式+自动故障转移模式。两者中有一个配置了手动故障转移，则自动故障转移就不能发生。两者间有一个配置了异步提交模式，则它们之间就只能发生强制故障转移。
强制故障转移可能会丢失数据。自动故障转移和手动故障转移会保证数据的安全。为了防止丢失数据，自动故障转移和手动故障转移都要求故障转移目标是使用同步提交模式的辅助副本且当时处于SYNCHRONIZED状态。如果已处于SYNCHRONIZED状态的辅助副本发出强制故障转移命令，其行为与手动故障转移时的行为相同。对于异步提交模式的辅助副本，无论数据是否已经达到同步，它永远只会处于SYNCHRONIZING状态，于是它只能支持强制故障转移这一种形式。
相对于数据库镜像，AlwaysOn的一个重要优势就是可以将辅助数据库配置成可读模式，这极大地增强了数据库整体的伸缩性。通过将只读请求分流到辅助数据库，主副本的工作负载得到了减轻，读和写之间的冲突可以得到缓解，辅助副本的硬件资源也能得到利用。同时，通过AlwaysOn的“只读路由”功能，只读操作可以动态地被转向辅助副本。在一定程度上，可以实现对终端用户透明。利用这个功能，SQL Server可以实现工作负荷的Scale-out（由多台SQL Server同时响应客户端发来的工作负载）。当客户端连接使用Listener的名字来访问SQL Server实例时，只读路由功能可以将来自客户端的只读请求从主副本上自动重定向到可读的辅助副本上去执行。客户端应用程序只需要确保连接的服务器名是Listener的名字，而无须去关心背后到底是哪个副本响应这个请求。这个功能可以自动分流一部分主副本的工作负载，使得主副本有更多的资源处理其他读写请求。
要让只读操作能“透明”地被自动转向辅助副本，必须解决下面三个问题：
-
客户端要标明自己发来的操作是“只读”操作。这个判定是程序开发员在编写程序的时候，通过ApplicationIntent关键字指定的，ApplicationIntent=ReadOnly，ApplicationIntent=ReadWrite
-
辅助数据库要被配成可读模式。
-
客户端的连接，要能够被重定向到可读辅助副本。AlwaysOn是用“只读路由”机制来实现的。
本文原始出处：江健龙的技术博客 http://jiangjianlong.blog.51cto.com/3735273/1791763
二、部署环境准备
1、部署环境
2、创建故障转移群集，使用共享磁盘作为仲裁盘。如果有3个以上节点，可以不必使用仲裁盘，但是使用仲裁盘仍是保障群集良好运行的推荐方式
3、在两个节点都独立安装SQL2012SP1，注意是独立安装，而非群集节点安装
4、在两个节点都启用SQL Server Always On可用性组
5、在SQL2012-01上创建TestDB，并设置恢复模式为完整
6、为TestDB做一次完整备份
7、将存储备份包的目录共享出来并设置相应的权限
三、配置Always On可用性组
1、使用向导创建可用性组
2、指定可用性组名称
3、选择要添加到可用性组中的数据库
选要添加到可用组中的数据库。这些数据库将会成为一个整体一同发生故障转移。在一个可用性组里最多可以添加100个数据库。在数据库名的右侧，会显示数据库的状态。如果该数据库的状态不满足可用组的要求，那么就无法勾选这个数据库。数据库要满足的要求包括：
需要是用户数据库，系统数据库不能加入可用性组。
数据库可以读写。只读的数据库不允许加入可用性组。
数据库要处于多用户模式。
数据库没有使用AUTO_CLOSE。
数据库的恢复模式是完全恢复。
数据库已经做过完整备份。
不属于任何其他的可用性组。
数据库上没有配置数据库镜像。
4、指定副本
点击添加副本，把第二个节点SQL2012-02添加进来（最多可以有5个可用性副本），并指定每个可用性副本的模式：
同步提交模式：该模式决定了主副本和辅助副本之间是否要保持完全同步。最多可以有3个同步提交副本。
自动故障转移模式：该模式决定了当主副本失败时是否将可用性组转移到指定的辅助副本上。最多可以将两个可用性副本配置为自动故障转移。
可读辅助副本：该模式决定了该副本作为辅助副本时是否可读。
5、配置端点
端点是AlwaysOn可用性组的重要组成部分，它的主要作用有两个：
（1）主副本和辅助副本之间通过端点传送日志块和消息，同步数据。
（2）主副本和每个辅助副本通过端点互相发送ping来确定彼此是否互相连通
端点的配置按默认即可。
6、指定备份首选项和优先级
首选辅助副本：如果有任何辅助副本可用，备份都应该在辅助副本上执行。如果主副本是唯一还处于在线状态的副本，那么备份才会在主副本上执行。
副本备份优先级：1表示最低优先级，100表示最高优先级。默认情况下，所有辅助副本都具有相同的备份优先级，如果保持这个设置，Always On就必须使用其他因素来决定执行备份的副本。
7、创建侦听器
只能通过 SQL Server 为每个可用性组创建一个侦听器。 通常情况下，每个可用性组只需要一个侦听器。侦听器就是一个虚拟的网络名称，可以通过这个虚拟网络名称访问可用性组，而不用关心连接的是哪一个节点，它会自动将请求转发到主节点，当主节点发生故障后，辅助节点会变为主节点，侦听器也会自动去侦听主节点。
创建侦听器需要提供：
（1）IP地址。建议使用静态IP地址
（2）网络名（DNS名）。确保该名字在网络上是唯一的。这个名字就是应用程序用来连接主副本的接口，它和任意一个副本的服务器名都不相同。
（3）端口号。需要指派一个服务器上未被使用的端口。这样副本实例才能成功绑定和监听这个端口。
8、选择初始数据同步
其他的副本通过这个共享目录获得数据库的备份并在各自的实例上进行还原。这个和日志传送进行初始化的步骤很像。这里要确保每个副本实例的服务账户对共享目录和本地目录有合适的读写权限。另外要注意，通过这种方式初始化，要确保主副本上存放主数据库文件的路径在辅助副本上也存在。
9、验证可用性组
10、可用性组摘要
11、完成可用性组的创建
四、可用性组创建完成后检查
1、在故障转移群集中确认可用性组
已创建群集资源组AlwaysOnGrp01,并承载在SQL2012-01节点上。
2、登录SQL2012-01确认是主副本
3、登录SQL2012-02确认是辅助副本
4、使用侦听器名称登录确认是登录到主副本
五、读写分流配置与测试
通过将只读请求分流到辅助数据库，主副本的工作负载得到了减轻，读和写之间的冲突可以得到缓解，辅助副本的硬件资源也能得到利用。同时，通过Always On的“只读路由”功能，只读操作可以动态地被转向辅助副本。在一定程度上，可以实现对终端用户透明。利用这个功能，SQL Server可以实现工作负荷的Scale-out（由多台SQL Server同时响应客户端发来的工作负载）。当客户端连接使用侦听器的名字来访问SQL Server实例时，只读路由功能可以将来自客户端的只读请求从主副本上自动重定向到可读的辅助副本上去执行。客户端应用程序只需要确保连接的服务器名是侦听器的名字，而无须去关心背后到底是哪个副本响应这个请求。这个功能可以自动分流一部分主副本的工作负载，使得主副本有更多的资源处理其他读写请求。
1、建立read指针
SQL 语句如下：
ALTER AVAILABILITY GROUP [AlwaysOnGrp01]
MODIFY REPLICA ON
N'SQL2012-01' WITH
(SECONDARY_ROLE (READ_ONLY_ROUTING_URL = N'tcp://SQL2012-01.lab-sql.com:1433'))
ALTER AVAILABILITY GROUP [AlwaysOnGrp01]
MODIFY REPLICA ON
N'SQL2012-02' WITH
(SECONDARY_ROLE (READ_ONLY_ROUTING_URL = N'tcp://SQL2012-02.lab-sql.com:1433'))
2、建立primary、 read db ur list关系
在当前的primary上为各个primary建立对应的read only url 列表（有优先级概念），为每个可能成为primary角色的server，建立相应的只读列表，下面的代码由于互为readonly server，因此优先级都是1，SQL 语句如下：
ALTER AVAILABILITY GROUP [AlwaysOnGrp01]
MODIFY REPLICA ON
N'SQL2012-02' WITH
(PRIMARY_ROLE (READ_ONLY_ROUTING_LIST=('SQL2012-01')));
ALTER AVAILABILITY GROUP [AlwaysOnGrp01]
MODIFY REPLICA ON
N'SQL2012-01' WITH
(PRIMARY_ROLE (READ_ONLY_ROUTING_LIST=('SQL2012-02')));
3、查看关系与优先级
SQL 语句如下：
select ar.replica_server_name, rl.routing_priority,
(select ar2.replica_server_name
from sys.availability_read_only_routing_lists rl2
join sys.availability_replicas AS ar2 ON rl2.read_only_replica_id = ar2.replica_id
where rl.replica_id=rl2.replica_id and rl.routing_priority =rl2.routing_priority
and rl.read_only_replica_id=rl2.read_only_replica_id) as 'read_only_replica_server_name'
from sys.availability_read_only_routing_lists rl join sys.availability_replicas AS ar ON rl.replica_id = ar.replica_id
4、 测试连接到辅助副本
（1）使用侦听器名称连接数据库
（2）指定要连接的数据库是TestDB
（3）通过ApplicationIntent关键字ApplicationIntent=ReadOnly标明客户端发来的操作是“只读”操作
（4）成功连接到辅助副本
六、可用性组的故障转移测试
1、断开SQL2012-01的网卡，模拟主副本故障
2、群集资源组已自动转移到SQL2012-02上
3、SQL2012-02已由辅助副本变为主副本
4、将SQL2012-01的网卡恢复连接
5、确认SQL2012-01警告消除（仍然为辅助副本）
本文转自 jianlong1990 博客，原文链接： http://blog.51cto.com/jiangjianlong/1791763 如需转载请自行联系原作者
