16.7 升级可用性组

16.7  升级可用性组

　　将服务器实例从 SQL Server 2012 升级到更高版本，可以依次对每个节点执行升级。这种升级方案称为“滚动升级”。如果是为了更新 Service Pack 时，它称为“滚动更新”。 

16.7.1 准备工作

　　在准备升级工作时，建议执行以下步骤：

（1）至少尝试对一个同步提交的副本执行实际手动故障转移。

（2）为防止升级过程中的意外，降低数据丢失的风险，对可用性组中的每个数据库执行完整数据库备份。

（3）在可用性组中的每个数据库上运行DBCC CHECKDB。

（4）为防止可用性组在升级过程中出现意外的故障转移，将所有的“自动”模式的故障转移改为“手动”模式。

（5）为尽量降低对客户端应用程序的影响，应在低客户端流量期间认真选择一个维护窗口。

16.7.2  滚动升级

　　为了将可用性组的停机时间降低到一个手动故障转移所需的时间，建议遵循以下最佳做法。

（1）首先升级远程辅助副本节点的实例，然后升级本地辅助副本节点的实例。

（2）确定一个故障转移目标节点，该节点的辅助副本为“同步提交”模式，并且确认其同步状态为“已同步”。

（3）执行手动故障转移至目标节点。

（4）升级最后一个节点（即原来的主副本节点）的实例。

（5）根据业务需求，重新设定“自动”故障转移。

16.7.3 特殊场景

　　通常情况下，如果辅助副本位于远程的实例上，那么“异步提交”是最合适的提交模式。但是，如果该可用性组只有一个主副本和一个远程辅助副本，“异步提交”会导致在滚动升级时丢失数据。针对这种特殊场景，滚动升级时建议遵循以下做法，防止数据丢失。

（1）升级远程辅助副本的实例。

（2）将提交模式改为“同步提交”。

（3）等待直到同步状态为“已同步”。

（4）手动故障转移到远程服务器的实例。

（5）升级本地服务器的实例。

（6）手动故障转移到本地服务器的实例。

（7）将提交模式改回“异步提交”。

　　当故障转移到远程服务器后，客户端应用程序会感觉到数据库延迟时间大幅度增加。

本文出自 “SQL Server 管理员指南” 博客，谢绝转载！