我们的数据库结构在 Window Failover Cluster Manager 中使用了两个角色。
- 一种是用于 FCI - 在主数据中心的主动/被动节点之间切换。
- 一种是 SQL 可用性组设置将数据从主数据中心复制到 DR 数据中心。这也用于发生灾难情况时的手动故障转移。
我们的 IT 团队希望在预定的停机时间定期对这些服务器执行操作系统修补，发生这种情况时应用程序将处于脱机状态。这对我们有点帮助，因为我们不必担心在修补另一个节点时故障转移到另一个节点，但是我们可以假设我们可以在修补期间使数据库完全脱机。
我的问题是最好的方法是什么，因为 IT 团队可能对 FCI 或数据库知之甚少。我不希望我们的数据库意外故障转移，因为在此过程中，活动 SQL 节点之一可能需要重新启动。我正在考虑给他们以下指示。
- RDP进入节点活动集群组，可以通过运行powershell命令找到这个：Get-ClusterGroup并找到“集群组”的OwnerNodeValue。
- 打开故障转移集群管理器扩展到角色，有两个角色，一个用于 AG，一个用于 FCI。
- 右键单击每个并选择“停止角色”
- 执行补丁，重新启动等..
- 完成后，RDP 重新进入并在“Start Role”上恢复这两个角色。
这会起作用吗？它被认为是好的做法吗？我希望强制故障转移服务停止，以便 SQL 节点在服务器重新启动期间不会故障转移到另一个节点。
通过分别考虑每个 SQL 实例来解决此问题。
修补 SQLDR\Inst_B
这是一个辅助副本，因此可以独立修补/重新启动。
注意：当 Inst_B 离线时，Inst_A 上的 T-Logs 将保留，以便在 Inst_B 返回时重播。我不建议在 Inst_A 上进行索引维护或大数据加载时修补 Inst_B。如果 Inst_B 长时间停机（想想几天），那么您可能想要破坏 AG 副本。
修补 SQLFCIPrimary\Inst_A
注意：由于您使用的是 MANUAL 故障转移，因此不会有意外故障转移到 Inst_B 的风险。
这是完成定期修补的最简单方法，只需要一到两次 FCI 故障转移。没有理由停止 WSFC 角色。
不管你先做 Inst_A 还是 Inst_B 都没有关系，但我是风险不利的，所以我会从 Inst_B 开始。