在这个系列中，准备讲述以下内容：
管理SQL Server AlwaysOn(1)——基础维护
管理SQL Server AlwaysOn(2)——添加、移除次要副本
管理SQL Server AlwaysOn(3)——可用性组备份
管理SQL Server AlwaysOn(4)——常见异常
管理SQL Server AlwaysOn(5)——常规监控(1)——常规监控
管理SQL Server AlwaysOn(5)——常规监控(2)——扩展事件监控
管理SQL Server AlwaysOn(6)——警告
管理SQL Server AlwaysOn(7)——待补充
注：由于工作所需，可能不会按顺序更新。
基础维护：
针对基础维护，本文大概介绍以下内容：
群集维护，包括补丁升级。
管理可用性组，包括如何进行同步/异步节点的故障转移。
添加多个侦听器
其他管理内容
下面我门开始进行介绍和演示，如果读者未有实操环境，可以参考开篇中提到的文章，先自行搭建，如果已有环境，建议先进行虚拟机的备份，因为有些操作具有大杀伤性。
群集管理：
本系列的主题是SQL Server AlwaysOn，而仅仅因为AlwaysOn需要建立在Windows Server Failover Cluster(WSFC，简称Windows群集)上，所以我们有必要把底层环境稍微介绍一下，但是不会做深入介绍，毕竟每个知识点学深了，都不是小事。
首先我们必须清楚，群集安装完毕并不等于工作结束，从安装完毕开始，我们的管理和维护工作才真正开始。这一部分会介绍：
节点之间移动实例
滚动补丁升级
节点间移动实例：
在日常运维当中，除了防止意外断电之外，其中一个部署高可用技术的好处就是可以明显降低维护过程中导致的停机时间。特别是对操作系统或者SQL Server进行打补丁操作。如果你的环境是双节点群集(假设为A，B，A为主节点/活动节点。B为被动节点)， 那么在打补丁等可能引发重启等操作时，就要进行节点移动。步骤如下：
对被动节点B进行补丁升级。(A主B被)
第一步成功后，把主节点A的实例故障转移(Failover)到被动节点B。此时原主动节点A和原被动节点B的角色就对调了。(A被B主)
对原主动节点A，现被动节点进行补丁升级。成功之后，操作已经算完成了。(A被B主)
然后根据具体需要再决定是否要把活动实例(现在的B)切换回去A节点。这个没有强制要求，但是需要考虑实际情况。比如实例的可用性是第一优先级并远大于其他一切要求，那么可能不适合再Failover回去，因为这个操作会引发短暂的服务不可用。又或者因为B节点是为了提供性能而配置的高水平服务器，那么通过这种打补丁或者Failover操作把服务移到更新，更强的节点之后，就没必要Failover回去原有节点，当然，WSFC建议使用等配的软硬件配置，所以在此之后，最后把A也提升到同等配置。
为了完成上面的步骤，可以用两种方法，一种是图形操作，另外一种是PowerShell命令。
图形操作：
首先登录到节点1，打开故障转移群集管理器，对Windows的Cluster角色名进行右键→【移动】→【选择节点】：
此时会显示【移动群集角色】对话框：
：
在上图中可以选择想移动的节点，由于目前是双节点，所以实际上是没有其他选择，点击确定之后，节点开始移动，移动完毕之后会看到：
PowerShell操作：
在权限足够的前提下，使用Move-ClusterGroup cmdlet可以实现角色的故障转移。比如下面命令可以把Node1的角色Failover到Node2：
[plain] view plain copy print?
Move-ClusterGroup -Name "WSFC群集角色名" -Node 目标节点名
注意WSFC群集角色名是有双引号的。演示环境下的样子是下图所示，注意我的环境现在是Node1为所有者，我希望转到Node2，所以在PowerShell里面我需要写上“目标节点名”：
执行后，不用刷新都可以看到当前的群集所有者已经换成了Node2：
再次啰嗦一下，本文是以基础维护为目标，并关注在SQL Server AlwaysOn上，所以对WSFC的真正专业的维护不在讨论和演示范畴。
滚动补丁升级：
上面演示的是双节点群集，在大型生产环境中，超过2节点的群集很普遍，此时如果要对SQL Server进行升级，就需要考虑滚动补丁更新。我们假设现在SQL Server运行在不同的大版本或者小版本上，可能会导致数据损坏，所以需要通过打补丁进行修复。下面是操作步骤：
列出角色中的所有节点的可能拥有者。
选择其中50%个节点，然后移除掉这些可能拥有者。如图，因为这里只有两节点，所以就只能勾选掉其中一个，比如Node1(因为当前活动节点在Node2，所以不能勾选掉Node2)。同样可以用PowerShell命令实现：执行之后可以看到结果是一样的[plain] view plain copy print?
Get-ClusterResource "AlwaysOn角色名(本例中为SQLAG)" | Set-ClusterOwnerNode -Owners 保留的节点(本例中为Node2保留，即Node1去掉)
当50%的可能拥有者节点移除后，就可以对勾选掉的节点进行补丁升级。在校验这些节点已经成功之后，把他们再次加回去。
把角色的节点移到其中一个已经升级成功的节点上。重复上面的操作，从可能的拥有者中移除未升级的节点→升级这些节点→验证→加回角色的可能的拥有者列表中。
管理可用性组：
对于AlwaysOn可用性组，当完成配置之后，也要开始进行管理操作。包括可用性组的故障转移、监控和在特殊情况下添加额外的侦听器。下面将逐个讨论：
故障转移：
当次要副本被配置为同步提交模式(synchronous commit mode)并设置了自动故障转移之后，当主副本遇到满足故障转移条件时，可用性组就会自动移到冗余副本上。在某些情况下，需要手动故障转移。常见情况有：DR测试、计划性维护操作等。
同步故障转移：
如果需要故障转移一个同步提交模式下的副本，可以在SSMS中，按下图方式在主副本上执行：
注意下面这个图，如果你是在次要副本中打开的故障转移界面，是没有这一步的
然后点击下一步和完成。如无报错，则可用性组转移成功。但是这并不代表完事了，经常容易忘记的事情就是：检查新主副本上的作业、账号、程序是否正确配置并正常运行，这一点很重要，因为本人过去的环境中，未对次要副本配置日志备份，而前面章节介绍过，AlwaysOn必须使用完整恢复模式，在这种模式下，生产环境的数据库日志文件很可能会异常暴增导致磁盘空间不足从而停止服务。在以前一开始使用AlwaysOn的时候就遇到过这种情况，也有些情况是账号配置问题、配套依赖程序未同步等因素导致转移成功但系统无法正常运行。所以要有足够的检查!
同样我们可以使用T-SQL来执行，比如我们现在需要从Node2切到Node1
注意：在次要副本中执行下面命令：
[sql] view plain copy print?
ALTER AVAILABILITY GROUP 可用性组名 FAILOVER ;
GO
执行完之后刷新一下就可以看到副本从“(辅助)”变成“(主要)”
异步故障转移：
当可用性组是异步提交模式时，从技术上来说，可以像同步提交模式一样进行Failover操作，但是你需要“强制”进行Failover，同时必须接受可能的数据丢失风险。可以使用下面命令进行Failover：
注意需要在次要副本上执行：
[sql] view plain copy print?
--Run in the secondary replica
ALTER AVAILABILITY GROUP SQLAG FORCE_FAILOVER_ALLOW_DATA_LOSS ;
除了在次要副本上执行之外，为了运行成功，你的群集还必须有仲裁，否则，需要强制把群集先联机，才能强制AlwaysOn可用性组联机。为了尽可能避免数据丢失，可以 在可能的条件下进行计划性Failover，下面是具体的操作步骤：
禁用各种登录账号，但要确保进行操作的账号不被禁用。
修改副本模式为同步提交模式。
Failover
把提交模式改回异步提交模式。
启用第一步中禁用的账号。
同步非包含对象：
不管使用哪种Failover模式，在实例级别都有一些对象是不包含在可用性组中，所以需要进行同步。最直接的方式是使用SSIS包周期性同步实例间的对象。下面是一些需要同步的内容：
Logins
Credentials(证书)
SQL Server Agent Jobs
自定义错误信息
Linked Servers
服务器级别的事件警告
Master库中的存储过程
服务器级别的触发器
密钥相关内容
添加多个侦听器：
常规情况下，每个可用性组只有一个单独的可用性组侦听器(Listener)，但是在某些极端情况下可能会对相同的可用性组创建多个侦听器。比如一些历史遗留问题。此时可能需要创建一个额外的侦听器用于硬编码。
但是，通过图形化界面(SSMS)、T-SQL甚至PowerShell都不能创建第二个侦听器，必须使用Failover Cluster Manager来实现。我们在我们的“SQLAG”角色内创建一个客户端接入点(Client Access Point)资源。按下面步骤：
添加一个新的客户端访问点名，并输入新的IP地址：
可以看到加了之后SQLAG角色的状态是“部分运行中”，并且看到下面的新加客户端访问点是“脱机”状态：
此时我们右键新的客户端访问点并选择属性：
在【依赖关系】中，选择【OR】，并添加原有的侦听器名(本例是192.168.1.123)：
然后右键“AGListener2”，选择联机即可。一旦配置完成之后，客户端可以使用任意一个侦听器名进行访问：
其他管理事项：
除了前面提到的之外，还有一些其他事项会把数据库变成不可用，其中最明显的就是不能把数据库变成single-user或者read-only模式。因为这个会导致应用程序的安全状态改变。这也是为什么在Failover一节中，需要禁用登录账号的原因。而且如果你必须变更数据库的单用户模式，那么首先需要移除可用性组。
可以使用下面命令从可用性组中移除：
[sql] view plain copy print?
--次要副本上执行
ALTER DATABASE TestAG SET HADR OFF ;
执行完毕后，次要副本从“已同步”变成了“正在还原”
这个时候又有可能需要把数据库恢复回去，这时候可以执行下面语句：
[sql] view plain copy print?
--注意SET后面，HADR意味着HA和DR，从名字可以折射出AlwaysOn是包含了HA和DR
ALTER DATABASE TESTAG SET HADR RESUME;
GO
另外一个重要的注意事项是数据库及其日志文件的部署。这些文件必须存在每个副本中相同的路径下。
总结：
关于SQL Server AlwaysOn的基础基础维护就先到这里，如有后续补充会尽可能显式添加进来或者必要时候另起一文。下一节介绍：管理SQL Server AlwaysOn(2)——添加、移除次要副本
