管理SQL Server AlwaysOn（1）——基础维护

本文属于管理SQL Server AlwaysOn 系列文章

前言：

前面系列已经介绍了SQL Server AlwaysOn的知识点、安装演示及注意事项等。但是这并不是终点，更多的反而是起点。就像不能生了孩子就不管，你还得养（管理）。作为DBA，更多的工作内容恰恰就是管理AlwaysOn。所以这里单独列出一个系列介绍SQL Server AlwaysOn的管理。本系列沿用 从0开始部署基础的AlwaysOn 的环境。

在这个系列中，准备讲述以下内容：

1. 管理SQL Server AlwaysOn（1）——基础维护
2. 管理SQL Server AlwaysOn（2）——添加、移除次要副本
3. 管理SQL Server AlwaysOn（3）——可用性组备份
4. 管理SQL Server AlwaysOn（4）——常见异常
5. 管理SQL Server AlwaysOn（5）——常规监控（1）——常规监控
   
6. 管理SQL Server AlwaysOn（5）——常规监控（2）——扩展事件监控
   
7. 管理SQL Server AlwaysOn（5）——常规监控（3）——性能监控
   
8. 管理SQL Server AlwaysOn（6）——警告
   
9. 管理SQL Server AlwaysOn（7）——待补充
   

注：由于工作所需，可能不会按顺序更新。

基础维护：

针对基础维护，本文大概介绍以下内容：

• 群集维护，包括补丁升级。
• 管理可用性组，包括如何进行同步/异步节点的故障转移。
• 添加多个侦听器
• 其他管理内容

下面我门开始进行介绍和演示，如果读者未有实操环境，可以参考开篇中提到的文章，先自行搭建，如果已有环境，建议先进行虚拟机的备份，因为有些操作具有大杀伤性。

群集管理：

本系列的主题是SQL Server AlwaysOn，而仅仅因为AlwaysOn需要建立在Windows Server Failover Cluster（WSFC，简称Windows群集）上，所以我们有必要把底层环境稍微介绍一下，但是不会做深入介绍，毕竟每个知识点学深了，都不是小事。

首先我们必须清楚，群集安装完毕并不等于工作结束，从安装完毕开始，我们的管理和维护工作才真正开始。这一部分会介绍：

• 节点之间移动实例
• 滚动补丁升级

节点间移动实例：

在日常运维当中，除了防止意外断电之外，其中一个部署高可用技术的好处就是可以明显降低维护过程中导致的停机时间。特别是对操作系统或者SQL Server进行打补丁操作。如果你的环境是双节点群集（假设为A，B，A为主节点/活动节点。B为被动节点）， 那么在打补丁等可能引发重启等操作时，就要进行节点移动。步骤如下：

1. 对被动节点B进行补丁升级。（A主B被）
2. 第一步成功后，把主节点A的实例故障转移（Failover）到被动节点B。此时原主动节点A和原被动节点B的角色就对调了。（A被B主）
3. 对原主动节点A，现被动节点进行补丁升级。成功之后，操作已经算完成了。（A被B主）

然后根据具体需要再决定是否要把活动实例（现在的B）切换回去A节点。这个没有强制要求，但是需要考虑实际情况。比如实例的可用性是第一优先级并远大于其他一切要求，那么可能不适合再Failover回去，因为这个操作会引发短暂的服务不可用。又或者因为B节点是为了提供性能而配置的高水平服务器，那么通过这种打补丁或者Failover操作把服务移到更新，更强的节点之后，就没必要Failover回去原有节点，当然，WSFC建议使用等配的软硬件配置，所以在此之后，最后把A也提升到同等配置。

为了完成上面的步骤，可以用两种方法，一种是图形操作，另外一种是PowerShell命令。