Always On 可用性组功能是一个提供替代数据库镜像的企业级方案的高可用性和灾难恢复解决方案。 SQL Server 2012 中引入了 Always On 可用性组功能，此功能可最大程度地提高一组用户数据库对企业的可用性。 “可用性组” 针对一组离散的用户数据库（称为“可用性数据库” ，它们共同实现故障转移）支持故障转移环境。 一个可用性组支持一组读写主数据库以及一至八组对应的辅助数据库。 （可选）可使辅助数据库能进行只读访问和/或某些备份操作。
可用性组在可用性副本级别进行故障转移。 可用性组 (availability group)一个容器，用于一组共同实现故障转移的数据库（“可用性数据库”）。可用性数据库 (availability database)属于可用性组的数据库。 对于每个可用性数据库，可用性组将保留一个读写副本（“主数据库”）和一个到八个只读副本（“辅助数据库”）。主数据库 (primary database)可用性数据库的读写副本。辅助数据库 (secondary database)可用性数据库的只读副本。可用性副本，可用性组的实例化，该可用性组由特定的 SQL Server 实例承载，并维护属于该可用性组的每个可用性数据库的本地副本。 存在两种类型的可用性副本：一个 主副本 和一至八个 辅助副本。主副本 (primary replica)使主数据库可用于来自客户端的读写连接并用于将每个主数据库的事务日志记录发送到每个辅助副本的可用性副本。辅助副本 (secondary replica)维护各可用性数据库的辅助副本的可用性副本，充当可用性组的潜在故障转移目标。 或者，辅助副本可以支持对辅助数据库进行只读访问，并支持对辅助数据库创建备份。可用性组侦听器 (availability group listener)一个服务器名称，客户端可连接到此服务器以访问 AlwaysOn 可用性组的主要副本或次要副本中的数据库。 可用性组侦听器将传入连接定向到主副本或只读辅助副本。
需要注意的是：每个可用性副本都必须驻留在单个 Windows Server 故障转移群集 (WSFC) 群集的不同节点中。
支持替代可用性模式，如下所示：
异步提交模式。 此可用性模式是一种灾难恢复解决方案，适合于可用性副本的分布距离较远的情况。
同步提交模式。 此可用性模式相对于性能而言更强调高可用性和数据保护，为此付出的代价是事务延迟时间增加。 一个给定的可用性组可支持最多三个同步提交可用性副本（包括当前主副本）。
支持几种形式的可用性组故障转移：自动故障转移、计划的手动故障转移（通常简称为“手动故障转移”）和强制的手动故障转移（通常简称为“强制故障转移”）
使您能够将给定的可用性副本配置为支持以下一种或两种活动辅助功能：
-
利用只读连接访问，与副本的只读连接可以在此副本作为辅助副本运行时访问和读取其数据库。 有关详细信息，请参阅活动辅助副本：可读辅助副本（AlwaysOn 可用性组）。
当副本作为辅助副本运行时，对副本的数据库执行备份操作。 有关详细信息，请参阅活动辅助副本：辅助副本备份（AlwaysOn 可用性组）。
通过使用活动辅助功能，可更好地利用辅助硬件资源，从而提高 IT 效率并降低成本。 此外，通过将读意向应用程序和备份作业转移到辅助副本，有助于提高针对主副本的性能。
支持每个可用性组的可用性组侦听器。 “可用性组侦听程序”是一个服务器名称，客户端可连接到此服务器以访问 AlwaysOn 可用性组的主要副本或次要副本中的数据库。 可用性组侦听器将传入连接定向到主副本或只读辅助副本。 侦听器在可用性组故障转移后提供快速应用程序故障转移。 有关详细信息，请参阅可用性组侦听程序、客户端连接和应用程序故障转移 (SQL Server)。
支持灵活的故障转移策略以便更好地控制可用性组故障转移。
支持用于避免页损坏的自动页修复。
支持加密和压缩，这提供了安全且高性能的传输方式。
大概介绍完后，我们开始今天的安装及配置介绍，
环境介绍：
我们再次跳过DC的环境部署，如果需要参考，请查看本地博客中关于DC的相关文章。
我们首先准备第一台SQLServer服务器，
然后开始安装SQLServer2016
选择需要安装的SQL Server功能角色，其实我们一般只安装数据库引擎即可。再次我们基本都安装了。
创建默认实例
服务器配置，我们选择混合模式
安装完成
我们安装完之后，通过SSMS连接，需要注意的是SQL Server 2016开始需要单独安装SSMS工具，我们可以通过以下链接进行下载安装。
https://docs.microsoft.com/en-us/sql/ssms/sql-server-management-studio-ssms
https://docs.microsoft.com/en-us/sql/ssms/download-sql-server-management-studio-ssms 英文版本
接下来我们准备第二台SQL Server
确认信息后，开始安装
安装完成
因为我们需要创建AlwayOn高可用，所以需要将两台节点增加到故障转移群集中，所以我们需要安装故障转移群集角色，我们开始安装故障转移群集中，我们该服务和SQLServer安装在一台。
首先是第一台-SQL2016-01
安装完成
然后第二台也安装完成--SQL2016-02
打开群集管理器后，接下来我们就是配置集群了，在配置群集之前建议先验证集群，将两个SQL Server服务器增加到节点中
因为我们是测试环境，没有配置心跳线，所以网络会有警告
验证没有问题后，我们开始创建集群，定义集群名称及网络地址
SQLCLU 192.168.5.17
确认信息，开始创建
因为我们没有添加仲裁，所以会提示一下信息，当然，我们也可以在后面单独配置仲裁
群集创建完成。
我们查看节点信息
接下来我们需要配置仲裁---群集名称--右击---更多操作--配置仲裁设置
在此我们选择高级仲裁配置
选择所有节点
我们再次配置文件共享见证，可以根据自己的环境进行选择配置
我们使用文件仲裁见证，服务器放在了DC上，所以提前需要在DC上创建一个共享文件夹
指定文件共享路劲到DC服务器上的共享文件夹
确认信息
创建完成
接下来就是我们创建一个数据库及表信息DB1
插入一些数据
都安装后，我们开始创建高可用组
我们通过SSMS右击--AlwayOn High Avaliablity 会有一个提示，
意思是必须为服务器实例启用AlwaysOn功能，之后才能在此实例上创建可用性组，若要启用AlowaysOn，请打开SQL Server配置管理器，右键单击SQL Server实例名称，选择属性，然后使用SQL Server属性对话框的AlwaysOn高可用性选项卡，
https://msdn.microsoft.com/en-us/library/ff878259.aspx
我们使用SSMS连接到SQL Server后，在服务器属性对话框中,单击一般页面。 的HADR启用属性显示下列值之一:
真正的如果启用了总是在可用性组织
假,如果总是在可用性组是禁用的。
使用SQL Server Configuration Manager进行配置，我们打开SQL Server 配置管理器
打开SQL SERVER配置管理器后，我们打开SQL Server服务
我们将SQL Server服务的登录账户换成域账户
然后我们勾选启用AlwayOn可用性组---
保存后，我们需要重启数据库服务
我们同样把第二台服务器的AlwaysOn打开
我们在创建高可用组之前，先创建一个共享文件夹，然后赋予权限
我们文件夹是在DC上创建的，需要注意的是，该共享文件夹只是临时的，创建完高可用组后就不会用到的。所以共享路劲创建在哪都无所谓
接下来我们就可以配置可用性组了
定义高可用组名称—DB-Always
创建高可用组前，我们需要对数据库进行完整备份。
备份完成
接下来回到创建高可用性组的想到就可以满足条件了
默认只有一个副本，因为我们有两台服务器，所以我们就可以添加副本
连接第二个节点
我们按照自己的生产环境进行配置，即可。
我们提前在DC上创建了一个共享目录
我们先不创建侦听器
选择同步目录，需要注意的是，该同步目录只是在一开始创建高可用性组的时候才可以用到，所以路劲无所谓
确认信息
创建完成
创建完成后，我们可以看见相关的配置信息
接下来就是创建侦听器侦听器
AlwaysOn创建后，客户端就需要进行连接，为了让应用程序能够透明地连接到主副本而不受故障故障转移的影响，我们需要创建一个侦听器，侦听器就是一个虚拟的网络名称，可以通过这个虚拟网络名称访问可用性组，而不用关心连接的是哪一个节点，它会自动将请求转发到主节点，当主节点发生故障后，辅助节点会变为主节点，侦听器也会自动去侦听主节点。
一个侦听器包括虚拟IP地址、虚拟网络名称、端口号三个元素，一旦创建成功，虚拟网络名称会注册到DNS中，同时为可用性组资源添加IP地址资源和网络名称资源。用户就可以使用此名称来连接到可用性组中。与故障转移群集不同，除了使用虚拟网络名称之外，主副本的真实实例名还可以被用来连接。
SQL Server2012早期版本的SQL Server只有在实例启动的时候地会尝试绑定IP和端口，但是SQL Server2012却允许在副本实例处于运行状况的时候随时绑定新的IP地址、网络名称和端口号。因此可以为随时为为可用性组添加侦听器，而且这个操作会立即生效。当添加了侦听器之后，在SQL Server的错误日志中可以看到类似：在虚拟网络名称上停止和启动侦听器的消息。
要注意的是，SQLBrowser服务是不支持Listener的。这是因为应用程序在使用Listener的虚拟网络名连接SQLServer时，是以一个默认实例的形式进行访问的（只有主机名，没有实例名），因此客户端根本就不会去尝试使用SQLBrowser服务。
我们创建一个侦听器
为侦听器定义一个名称和IP地址
创建完成
我们可以看见集群角色会自动配置好角色----是监听器的地址
最近后我们通过集群地址
192.168.5.17
alwayon地址也可以登录
192.168.5.16
接下来我们切换一下
切换前我们需要注意一个问题
切换的时候不能在集群管理器里面切换，需要在高可用性组下切换，不然会有问题，就算切换成功了，有些数据也会出现问题
我们首先在集群管理器里面查看节点所有者
接下来我们切换--右击高可用性组----故障转移
通过想到切换
因为我们只有两个节点，所以会显示节点2
我们需要手动连接节点2
开始连接
连接完成
确认信息
切换完成
我们就可以看见SQL2016-02就是主节点了
各副本间的数据同步
AlwaysOn必须要维护各副本间的数据一致性，当主副本上的数据发生变化，会同步到辅助副本上。这里AlwaysOn通过三个步骤来完成：
步骤1：主副本记录发生变化的数据；
步骤2：将记录传输到各个辅助副本；
步骤3:把数据变化操作在辅助副本上执行一遍。
具体实现如下：
在主副本和辅助副本上，SQL Server都会启动相应的线程来完成相应的任务。对于一般的SQL Server服务器，即没有配置高可用性，会运行Log Writer的线程，当发生数据修改事务时，此线程负责将本次操对应的日志信息记录到日志缓冲区中，然后再写入到物理日志文件。但如果配置了AlwaysOny主副本的数据库，SQL Server会为它建立一个叫Log Scanner的线程，不间断的工作，负责将日志从日志缓冲区或日志文件里读出，打包成日志块，发送到辅助副本。因此可以保证发生的数据变化，不断送给各辅助副本。
辅助副本上存在固化和重做两个线程完成数据更新操作，固化线程会将主副本Log Scanner所发过来的日志块写入辅助副本磁盘上的日志文件里，因此称为固化，然后重做线程负责从磁盘上读取日志块，将日志记录对应的操作重演一遍，此时主副本和辅助副本上的数据就一致了。重做线程每隔固定的时间点，会跟主副本通信，告知自己的工作进度。主副本由此知道两边数据的差距。Log Scanner负责传送日志块，不需要等待Log Writer完成日志固化；辅助副本完成日志固化以后就会发送消息到主副本，告知数据传输完成，而不需要等待重做完成，这样各自独立的设计，是尽可能减少 AlwaysOn所带来的操作对数据库性能的影响。
本文转自 高文龙 51CTO博客，原文链接：http://blog.51cto.com/gaowenlong/1905360，如需转载请自行联系原作者
