标签: availability-groups

假设您需要确保依赖 SQL Server 2012 作为其数据库后端的应用程序全天候可用，即使一台服务器出现故障。

作为开发人员而不是 DBA，我很难理解何时使用哪种场景来实现故障转移/高可用性：

• Windows 故障转移群集中的两台（或更多）服务器，SQL Server 作为群集实例
• 通过事务复制保持最新的两个（或更多）SQL Server 实例
• SQL Server 可用性组中的两个（或更多）SQL Server，以同步提交模式配置

这些场景中的哪一个适用于什么样的工作负载，以及这些场景可以处理什么样的故障/中断？它们甚至具有可比性/可交换性吗？

我正在寻找处理 SQL Server 2012 可用性组中计划的 SQL Server 代理作业的最佳实践。也许我错过了一些东西，但是在目前的状态下，我觉得 SQL Server 代理并没有真正与 SQL2012 的这个强大功能集成在一起。

如何让计划的 SQL 代理作业知道节点切换？例如，我有一个在主节点上运行的作业，它每小时加载数据。现在，如果主要服务器出现故障，我如何激活现在成为主要服务器的辅助服务器上的作业？

如果我总是在辅助上安排作业，它会失败，因为辅助是只读的。

我设置了一个 Always On Availability Group，我想确保我的用户在他们的连接字符串中使用 ApplicationIntent=ReadOnly。

从 SQL Server 通过 DMV（或扩展事件或其他），我能否判断用户是否在其连接字符串中使用 ApplicationIntent=ReadOnly 进行连接？

请不要回答如何防止连接 - 这不是这个问题的内容。我不能简单地停止连接，因为我们现有的应用程序在没有正确字符串的情况下进行连接，我需要知道它们是哪些，以便我可以与开发人员和用户合作，随着时间的推移逐渐修复它。

假设用户有多个应用程序。例如，Bob 与 SQL Server Management Studio 和 Excel 连接。他需要更新时使用 SSMS，需要读取时使用 Excel。我需要确保他在与 Excel 连接时使用 ApplicationIntent=ReadOnly。（这不是确切的场景，但足以说明。）

我们正准备对我们的 SQL Server执行大规模升级，并注意到分布式可用性组的一些异常行为，我正试图在继续之前解决这些问题。

上个月，我将远程辅助服务器从 SQL Server 2016 升级到 SQL Server 2017。该服务器是多个分布式可用性组 (DAG)和一个单独的可用性组 (AG) 的一部分。当我们升级这台服务器时，我们没有意识到它会进入一个不可读的状态，所以在过去的一个月里，我们一直完全依赖于主服务器。

作为即将进行的升级的一部分，我将CU 4补丁应用到服务器并重新启动它。当服务器重新上线时，刚刚打补丁的辅助服务器显示所有 DAG/AG 都在同步，没有任何问题。

然而，初选展示了一个非常不同的故事。报道称

• 单独的 AG 同步没有任何问题
• 但 DAG 处于不同步/不健康状态

在最初感到恐慌之后，我尝试了以下方法来使 DAG 中的事物再次同步：

• 从主数据库中，我停止并恢复了数据移动。这并没有开始同步数据。
• 在二级（我刚刚修补的那个）上我跑了ALTER DATABASE [<database] SET HADR RESUME;- 执行没有错误，但没有恢复任何同步

我最后一次再次同步数据的尝试是登录到辅助服务器，然后手动重新启动 SQL Server 服务。手动重新启动服务似乎有点极端，因为我希望重新启动服务器就足够了。

有没有人遇到过重启后 DAG 没有开始同步到辅助节点的问题？如果有，是如何解决的？

我检查了 SQL Server 错误日志和辅助服务器上的事件查看器，没有发现任何异常。

我需要截断一个包含 170 亿行的表，该表位于作为 AG 一部分的数据库中。

此操作对 AG 延迟和日志备份大小有什么影响？

有推荐的方法吗？

我需要为 SSRS 和 Tableau 报告提供实时或几乎实时的数据。我不希望生产 OLTP 系统受到长时间运行的查询的负面影响。在可用性组中的辅助数据库上运行大型查询会影响主数据库中的事务性能吗？

在升级 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 中时，有什么方法可以在辅助节点上恢复数据复制？

如果在可用性组中的主节点上强制执行计划，它是否应用于在辅助节点上运行的查询？

我正在寻找涵盖计划强制两种可能性的答案：

• 计划指南
• 查询存储强制计划

我已阅读以下内容，这些内容表明 QS 强制计划不会结转，但在文档中找不到任何权威信息，或任何有关计划指南的信息。

• Erin Stellato 的查询存储和可用性组
• Vikas Rana在 AlwaysOn Readable Secondary 上查询数据存储强制计划行为

强制的决定性证据是辅助节点的执行计划中存在Use Plan或PlanGuideName和PlanGuideDB属性。

大家好，提前感谢您的帮助。我们在 SQL Server 2017 可用性组方面遇到了挑战。

背景

公司是一家零售B2B后端软件。约500个单租户数据库，5个共享数据库供所有租户使用。工作负载特征主要是读取，并且大多数数据库的活动非常低。

托管在同一地点的物理生产服务器最近从共享 SAN/FCI 配置的 Windows Server 2012 上的 SQL Server 2014 Enterprise 升级到 Windows Server 2016 上的 SQL Server 2017 Enterprise，在 2 插槽/32 核/768 GB RAM 和本地使用 AlwaysOn AG 的 SSD 驱动器。AG 流量使用具有交叉电缆连接的专用 10G NIC 端口。

他们的要求是所有数据库一起进行故障转移，因此他们必须将它们全部放在一个 AG 中。它是同一服务器上的单个不可读取的同步副本。

新服务器已于2018年6月投入生产，安装了最新的CU（当时的CU7）和windows更新，系统运行良好。大约一个月后，在将服务器从 CU7 更新到 CU9 后，他们开始注意到以下挑战，按优先级顺序列出。

我们一直在使用 SQL Sentry 监控服务器，并没有观察到物理瓶颈。所有关键指标似乎都不错。CPU 平均为 20%，IO 时间通常小于 1ms，RAM 未充分利用，网络 <1%。

挑战

故障转移后症状似乎好转，但几天后又会出现，无论哪个服务器是主要服务器 - 两台服务器上的症状都相同。

1. 偶发的客户端超时和连接故障，例如

   ...建立连接时发生错误...

   或者

   执行超时过期

   有时这些会持续长达 40 秒，然后消退。

2. 事务日志备份作业的完成时间是以前的 10 倍。以前备份所有500个数据库的日志需要2-3分钟，现在需要15-25分钟。我们已经验证备份本身运行良好，吞吐量良好。但是，在完成一个日志的备份之后和开始下一个之前，会有一个小的延迟。它开始时非常低，但在一两天内达到 2-3 秒。乘以500个数据库，还是有区别的。

3. 有时，一些看似随机的数据库会在手动故障转移后陷入“未同步”状态。解决此问题的唯一方法是重新启动辅助副本上的 SQL Server 服务，或者删除这些数据库并将其重新加入 …

我正在考虑为我们的 SQL Server 集群之一使用 RAID0 设置。我将概述情况并寻找为什么这可能是一个坏主意。此外，如果您有用例、白皮书或其他文档，您可以就这个主题向我指出，那就太好了。

我们在 2 个数据中心有 3 台服务器，它们是 SQL 集群的一部分。它们都在一个可用性组中运行 SQL Server。主节点旁边有一个副本，另一个位于另一个数据中心。他们正在运行具有自动故障转移功能的同步复制。所有驱动器都是企业级 SSD。他们将运行 SQL Server 2017 或 2019。

我认为与其他方法相比，在 RAID0 阵列上运行它们会有很多好处，而且几乎没有真正的缺点。我目前看到的唯一负面影响是主服务器上缺乏冗余，因此失败率增加。作为优点：

1. 如果驱动器发生故障，而不是在有人收到通知并对其进行手动操作之前以缓慢、降级的状态运行，则服务器将立即无法保持完整的操作能力。这将有一个额外的好处，即通知我们故障转移，因此我们可以更快地调查原因。

2. 它降低了每 TB 容量的整体故障几率。由于我们不需要奇偶校验或镜像驱动器，因此我们减少了每个阵列的驱动器数量。驱动器越少，驱动器故障的总机会就越小。

3. 这更便宜。为我们所需的容量需要更少的驱动器显然成本更低。

我知道这不是传统的商业思维，但有什么我没有考虑的吗？我喜欢任何赞成或反对的意见。

我不是为了提高查询性能而尝试这样做，但如果有有意义的，请随时指出它们。我主要担心的是没有考虑或解决我没有想到的可靠性或冗余问题。

操作系统位于单独的镜像驱动器上，因此服务器本身应该保持正常运行。这些驱动器之一可以更换并再次镜像。它很小，除了系统数据库之外没有任何数据库文件。我无法想象这需要超过几分钟。如果其中一个数据阵列出现故障，我们会更换驱动器、重建阵列、恢复并与 AG 重新同步。根据我的个人经验，恢复比 RAID5 驱动器重建快得多。我从来没有遇到过 RAID1 故障，所以我不知道重建是否会更快。恢复将来自备份并前滚以匹配主服务器，因此主服务器上的负载增加应该非常小，仅将日志的最后几分钟与恢复的副本同步。