共计 6110 个字符，预计需要花费 16 分钟才能阅读完成。
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 可用性组。
2，使用 SSMS 连接任意主副本的 SQL Server 实例，打开新建 AG 向导（New Availability Group Wizard）
连接到主副本，是因为该副本上拥有所有的可用性数据库，如果所有的可用性副本上都有相同的数据库副本，那么可以连接任意一个副本。
3，指定 AG 的名字，勾选“Database Level Health Detection”选项
4，选择可用性数据
从数据库列表中需要添加到可用性组中的数据，这些数据库将成为一个整体一起发生故障转移，本例勾选 Test_DW。
添加到可用性组中的数据库必须满足一定的要求：
- 数据库可以读写；
- 数据库的恢复模式是 FULL；
- 数据库已经做过完整备份；
5，添加可用性副本
使用“Add Replica”添加可用性副本，在 Availability Replicas 列表中，能够查看各个可用性副本的配置：
- Server Instance：副本的实例名称
- Initial Role：是副本初始角色，Primary 是主副本，Secondary 是辅助副本；
- 勾选“Automatic Failover”：副本的故障转移模式是自动故障转移；
- 勾选“Synchronous Commit”：副本的可用性模式是同步提交模式；
- “Readable Secondary”：可读的辅助副本，主数据库是可读写的，辅助数据库可以设置为可读的；
6，创建 Listener
创建一个可用性组的侦听器，实际上是虚拟的服务器，
- Listener DNS Name：网络名，命名为 TestAGListener；
- Port：推荐使用默认端口 1433；
- Network Mode：IP 地址的分配方式，建议使用 Static IP，本例使用 DHCP
- Subnet：子网，系统自动设置
7，选择如何在辅助副本上初始化 AG 中的数据
FULL：向导自动对主数据库做完整备份和日志备份，并将备份文件存放在共享目录中，其他副本通过共享目录获得数据库的备份，并在各自的 SQL Server 实例上还原数据库。通过 FULL 初始化方式，必须确保主副本上的存储主数据库文件的路径在辅助副本上也存在，即数据库文件的存储路径一致。
Join Only：如果已经手动在各个辅助副本上还原了数据库，使用该选项，将各个辅助副本直接加入到可用性组中。
Skip Initial data sync：跳过该步骤，用户需要手动在主副本上对数据库做完整备份，并还原到所有的辅助副本，然后通过 SSMS 将数据库添加到可用性组中。
推荐将主数据库和辅助数据库的文件路径保持一致。
8，成功创建可用性组
执行后续的 Validation 和 Summary 之后，向导开始创建可用性组，在创建完成之后，使用 SSMS 打开“AlwaysOn High Availability”，能够看到创建成功的可用性组：“TestAG”，括号中的 Primary 表示当前的可用性副本是主副本（Primary Replica）。
参考文档：
《SQL Server 2012 实施与管理实战指南》第三章 PDF 下载见 http://www.linuxidc.com/Linux/2016-01/127450.htm
从 0 开始搭建 SQL Server AlwaysOn 第三篇（配置 AlwaysOn）
AlwaysOn Failover Cluster Instances (SQL Server)
本文永久更新链接地址：http://www.linuxidc.com/Linux/2017-01/139776.htm
