SQL Server 补丁概述

定期对 SQL Server 进行更新（使用服务包（SP）或累积更新包（CU））是一种推荐的做法。以下是对 SQL Server 更新的简要概述。

服务包：服务包包含已发布的热修复程序和更新的单一打包文件。
累积包（CU）：累积包（CU）是热修复程序和较小的功能增强内容。
一般分发版本（GDR）：微软发布 GDR 版本，它特别与 SQL Server 安全性相关。

在 SQL Server 2016 之前，微软会定期发布服务包和累积更新。例如，在 SQL Server 2016 版本中，您会看到以下这样的序列。

RTM release
Cumulative Updates ( CU1 to CU9)
Service Pack 1
Cumulative Packs (CU1 to CU15)
Service Pack 2

从 SQL Server 2017 版本开始，微软改变了其服务模式。它不再提供服务包，而是每隔两个月发布累积包。每个累积包都包含之前的累积包内容。例如，在 SQL Server 2019 中，微软于 2020 年 9 月 2 日发布了最新的 CU7。因此，如果您使用的是 RTM 版本，可以直接应用 CU7 以获得最新的构建版本 [15.0.4063.15]。

为 SQL Server Always On的副本应用 SQL Server 补丁

在 SQL Server Always On Availability Group中，我们使用多个 SQL 实例，并将它们称为主副本（primary）和辅助副本（secondary）。根据您的 SQL Server 版本，您可以有一个主副本和多个辅助副本。

在故障转移集群（failover cluster）环境中运行的 SQL Server 与使用Availability Group的 SQL Server 在补丁安装流程上存在差异。

在故障转移集群中，SQL 服务会继续在一台节点上保持运行状态，而另一台节点的服务则处于停止状态。
活动节点拥有共享磁盘，并且在故障转移过程中会转移到另一台节点上。

在可用性组配置中，SQL 服务在所有副本上运行，并充当主副本或从副本的角色。在本文中，我们将介绍如何在 HADR 环境中的三节点可用性组中应用补丁。

我们可以将整个 SQL 扩补工作分为三个阶段。

准备工作
应用补丁
收尾工作

让我们依次探讨每个阶段的任务，并对其进行详细阐述。

准备阶段

在准备阶段，我们需要完成以下任务：

确定当前补丁级别和目标补丁级别。对于目标补丁级别，可以选择 N-1（N=最新补丁） 的补丁级别。如果你想直接使用最新补丁，务必查看 SQL Server 官方博客，了解应用该补丁后是否存在已知问题。
切勿直接在生产环境中应用补丁。应先在低环境中测试目标补丁，等待至少一周的应用验证后，再迁移至生产环境打补丁。
仔细阅读目标补丁的发布说明，它会提供有关错误修复和功能增强的信息。
在对生产副本应用补丁之前，需要验证以下内容：
1，确认在主副本上已经拥有系统数据库和用户数据库的最新备份。最好进行完整备份；但如果数据库体量过大，可以在应用补丁前，选择进行 差异备份或事务日志备份。
2，在辅助副本上，进行系统数据库的备份。
使用 可用性组（AG）仪表板验证可用性组的健康状况。在同步提交模式下，AG 数据库应处于 Synchronized（已同步）状态；在异步提交模式下，应处于 Synchronizing（正在同步）状态。

在SQL Server Always On Availability Group可用性组副本中应用 SQL Server 补丁

如上图所示，我们有三个需要打补丁的 SQL 实例：

在主数据中心有两个节点，主数据中心的可用性组处于同步模式。
在辅助数据中心有一个节点，辅助数据中心的可用性组处于异步模式。

首先，我们在主数据中心的辅助副本上应用补丁。

在 SSMS 中打开可用性组属性，将 故障转移模式 从自动（Automatic） 修改为手动（Manual）（如下图所示）。这样可以确保在给主副本打补丁时，如果出现问题，不会自动故障转移到辅助副本。

在 SSMS 中连接到 辅助副本，展开 Always On High Availability -> Availability Databases。对辅助副本的数据库执行Suspend Data Movement（暂停数据传输），这样主副本就不会再向该特定的辅助副本发送事务块。如果你从主副本暂停数据传输，那么会导致所有辅助副本的数据传输都被暂停。因此，在应用 SQL Server 补丁时，应当从需要打补丁的辅助副本上执行暂停操作。

远程连接至辅助副本，按需安装 Service Pack / Cumulative Update（累计更新包）。安装过程比较直接，可以按照安装向导完成最新补丁的应用。
重启辅助副本：安装补丁后必须重启服务器。
当辅助副本上线后，使用 SSMS 连接并执行验证：
- 验证 SQL 服务是否正常运行
- 验证 SQL Server 版本是否更新成功
- 检查 SQL Server 错误日志中是否存在错误或警告
- 验证数据库状态
- 建议在打补丁后运行一次 DBCC CHECKDB 来验证数据库一致性
然后，从 辅助副本数据库 恢复数据传输（Resume Data Movement）。辅助副本可能需要一段时间才能恢复到 Synchronized（同步状态），因为它需要先应用所有待处理的事务日志块。
等待 AG 仪表板 显示为健康状态（绿色）。一旦健康状态确认无误，执行一次 手动故障转移（Manual Failover），将当前的主副本切换到主站点中的辅助副本。
故障转移后，当前的主副本会变为辅助副本。
此时可以按照相同步骤为新的辅助副本应用 SQL Server 补丁。
当新的辅助副本打完补丁并完成验证后，再执行 AG回切（Failback）。这样，主副本将恢复到打补丁前的状态。
最后，将同步提交模式下的 主副本和辅助副本 的 故障转移模式（Failover Mode） 改回自动（Automatic）。
至此，我们已经完成了 主站点 中 SQL Server Always On 可用性组的补丁操作。此时可以通知应用团队进行验证，并反馈是否存在问题。
对于 灾备站点（DR）副本节点：它在 SQL Server Always On 可用性组中处于 异步模式，因此故障转移模式本来就是 手动（Manual）。需要执行以下步骤：
1. 暂停 DR 副本的数据传输
2. 在 DR 副本上应用补丁
3. 执行数据库与 SQL 服务验证
4. 恢复数据传输

收尾工作

在对可用性组中的 SQL 实例应用完补丁之后，需要进行以下验证：

确认版本：验证所有参与 SQL Server Always On 可用性组的副本，SQL 实例版本是否都已更新
故障转移测试：执行可用性组的故障转移（Failover），并在故障转移和回切（Failback）后确认仪表板（Dashboard）状态是否健康
日志检查：查看所有副本上的错误日志
应用验证：让应用团队验证业务功能是否正常

总结

SQL Server 打补丁是数据库管理员的一项重要任务。本文我们探讨了在高可用与灾难恢复（HADR）配置下，为 SQL Server Always On 可用性组应用补丁的流程。
需要牢记的是：每个环境可能会因为配置和 SQL Server 功能的不同而有所差异。因此，在打补丁之前必须做好规划，以避免最后时刻的仓促操作。始终应当先在开发和测试环境中应用补丁，再推广到生产环境。