在 SQL Server Always On Availability Groups中应用SQL Server 补丁程序或累积更新

原文地址：https://www.sqlshack.com/apply-sql-server-patches-or-cumulative-updates-in-sql-server-always-on-availability-groups/  在本系列关于 SQL Server 始终在线可用性组的第 32 篇文章中，我们将讨论为 AG 复制实例应用服务包或累积更新包的过程。 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）。需要执行以下步骤：
  
  
  • 暂停 DR 副本的数据传输
    
  • 在 DR 副本上应用补丁
    
  • 执行数据库与 SQL 服务验证
    
  • 恢复数据传输
    
   
  

 收尾工作

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

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

 总结

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

来源：程序园用户自行投稿发布，如果侵权，请联系站长删除
免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！