小编Gre*_*ray的帖子

在升级 SQL Server 2014 SP1 (12.0.4422.0) 实例中的存储时，我们遇到了一个问题，即在重新启动 SQL Server 后，两个数据库无法在辅助数据库上启动。当我们安装新的（更大的）SSD 并将数据文件复制到新卷时，服务器已离线几个小时。当我们重新启动 SQL Server 时，除了两个数据库之外的所有数据库再次开始同步。另外两个在 SSMS 中显示为Not Synchronizing / Recovery Pending。

之前遇到过类似的Not Synchronizing / In Recovery问题，我检查了 Availability Groups -> Availability Databases 部分下的状态，但它们显示了一个红色的 X：

甚至尝试暂停数据移动生成了一条错误消息：

无法暂停数据库“StackExchange.Bycycles.Meta”中的数据移动，该数据库驻留在可用性组“SENetwork_AG”中的可用性副本“ny-sql03”上。(Microsoft.SqlServer.Smo)

附加信息：执行 transact-SQL 语句或批处理时发生异常。(Microsoft.SqlServer.ConnectionInfo)

由于无法访问文件或内存或磁盘空间不足，无法打开数据库“StackExchange.Bycycles.Meta”。有关详细信息，请参阅 SQL Server 错误日志。（Microsoft Sql Server，错误：945）

我检查过文件存在并且没有任何权限问题。我还检查了管理下 SSMS 中的 SQL Server 日志，但没有看到任何有关挂起恢复或两个数据库的任何问题的信息。

在寻求帮助时，我发现两篇不同的文章都说需要恢复数据库。

当数据库卡在 Recovery Pending 中时，有什么方法可以在辅助节点上恢复数据复制？

在测试从 SQL Server 2014 SP1 (12.0.4422.0) 到 SQL Server 2016 CTP 3.2 (13.0.900.73) 的升级时，我遵循推荐的更新过程并遇到了一个问题，即故障转移后数据库无法在旧的主数据库上启动到更新的辅助。我们的设置是一个主副本和一个辅助副本，我完成的步骤是：

1. 删除同步提交辅助副本上的自动故障转移
2. 将辅助服务器实例升级到新版本
3. 手动故障转移到辅助副本
4. 验证数据库在新的主副本上是否在线
5. 将以前的主副本升级到新版本

升级辅助节点和故障转移使其成为主节点完全按预期工作。但是在升级以前的主副本后，我注意到其上的数据库在 SSMS 中列为Not Synchronizing / In Recovery。尝试访问它们也会生成错误消息：

数据库...无法访问。（对象浏览器）

通过我看到的 SQL Server 日志检查

无法打开数据库 '...' 版本 782。将数据库升级到最新版本。

查询master..sysdatabases表，确实是旧版本，升级过程中没有更新：

不幸的是，日志没有指出它为什么没有更新，并且可用性组仪表板只给出了一个通用警告，表明某些可用性数据库的数据同步状态不健康，没有任何原因。

我尝试使用 TSQL 分离数据库或将它们设置为离线以“踢”它进行更新，但由于它们是 SQL AG 的一部分，因此这些命令不起作用。

当数据库是 SQL AG 的一部分时，如何将数据库升级到最新版本？

我们在 Windows Server 2012 多子网故障转移群集上使用 SQL Server 2016 可用性组 (AG) 来实现 HA/DR。我们的纽约数据中心（10.7.xx 子网）中有两个节点，我们的科罗拉多数据中心（10.8.xx 子网）中有一个节点。科罗拉多服务器主要用于灾难恢复或纽约离线的扩展维护，因此我们目前将 CO-SQL01 节点的 Quorum NodeWeight/Votes 设置为零，以防止它在出现任何问题时自动获得集群或 AG 的所有权.

我的问题是：我们是否应该更改故障转移群集管理器中的默认设置，特别是 AG 角色的首选所有者和 AG 侦听器 IP 资源的可能所有者？使用的默认值似乎与我们在纽约使用两个节点并仅使用 CO 节点进行灾难恢复的高可用性目标相冲突。

以下是我们多子网 AG 的首选所有者的默认设置：

我们是否应该在 NY-SQL02 旁边添加一个检查并将其移动到 CO-SQL01 之上，以便它成为首选？其他角色呢，我们可以设置核心集群资源的首选所有者吗（比如集群名称）？

以下是 SQL-StackOverflow_AG IP 资源的默认设置：

我们是否应该删除与该 IP 地址位于不同子网中的服务器旁边的复选标记？

这个问题是在最近的办公时间提出的，但是当我们的集群出现问题时，我们可能会帮助防止停机。我们最近在更换 CO-SQL01 服务器硬件时发生了 5 分钟的中断，它被添加回故障转移集群（但不是 AG）而没有删除它的投票。CO-SQL01 服务器随后发生了严重崩溃（我们认为这是重负载下的 NVMe/PCIe 驱动程序错误）并设法将 AG 与它一起删除（我们认为 CO-SQL01 在它出现时获得了核心集群资源的所有权重新上线）。

老实说，我们在使用多子网故障转移群集可用性组时遇到了许多意外问题，似乎默认首选角色所有者和可能的资源所有者可能不正确，或者至少不是我们方案的最佳选择。我们目前正在考虑使用SQL Server 2016 中新的分布式可用性组功能将我们的多子网 AG 拆分为两个单个子网 AG（每个数据中心一个），以防止将来出现这些问题。我们还认为这将使我们能够以最少的停机时间升级集群操作系统。

我们刚刚开始设置分布式可用性组，以将我们的生产数据库复制到新的报告集群中。我们为复制设置的第一个可用性组运行良好，没有任何问题，但是当我们转移到具有更大数据库（总共超过 3TB）的第二个可用性组时，它花费的时间更长，并且 5 个数据库中有两个失败了。我们将分布式可用性组设置为使用直接播种，并在查询 sys.dm_hadr_automatic_seding 表时将 current_state 指示为 FAILED，故障状态为 2（SQL 错误）或 21（播种检查消息超时）：

我们可以做些什么来解决这个问题？