标签: availability-groups

我们有两个数据中心，它们之间的 ping 时间为 2 ms，通过站点到站点 VPN 连接。在主数据中心，我们有 2 台服务器，在辅助数据中心，我们有一个数据库服务器。所有服务器的规格和配置都相同，运行 Windows 2012 R2，我们有两个 SQL Server 2016 Enterprise 许可证。一种用于主站点 + 故障转移，一种用于辅助站点。

问题是我们应该使用什么技术？始终在可用性组上，在主数据中心的两个节点之间进行同步复制并异步复制到辅助数据中心。另一种选择是在主数据中心使用镜像，然后将日志传送到辅助数据中心。唯一需要注意的是，我们需要使用透明数据加密 (TDE)，因此需要使用企业许可证。

我们的运维团队目前有 2 人并且在不断增长，但还没有完全分配 DBA，我知道如何设置这两种技术，但只在生产中使用过镜像和日志传送。

人们会推荐什么，always on 看起来很棒，但我读过一些文章说你需要大量的 DBA 资源来照顾它，而镜像和日志传送要容易得多。

我们设置了 SQL Server 2014 Always ON，其中包含一个主要副本和一个辅助副本。我一直在使用 Dell LiteSpeed 在辅助副本上进行数据库备份（完整和 tlog），以便从主副本卸载该流量。我们让一位开发人员截断了一个重要的表，因此我们不得不从完整备份和 tlog 备份中恢复主数据库。在恢复之前，我首先在主数据库上进行了完整的数据库备份，并注意到它只有 34 GB，而辅助数据库的备份几乎是 70 GB。恢复后，人们抱怨性能很慢。我的问题是为什么辅助副本上的数据库备份是主副本的两倍。TIA。

我刚刚获得了一个 Sql Server 2016 可用性组设置（一个主节点、一个同步辅助节点和一个异步辅助节点）。我在服务器上有五个数据库。

我设置了一个应用程序来对服务器运行查询（使用带有“故障转移伙伴”连接字符串的实体框架。）

当我尝试通过重新启动主服务器来测试故障转移时，出现以下错误：

服务器 MySecondaryServer，数据库主服务器没有配置数据库镜像。

像这样镜像系统数据库似乎很奇怪，所以我们没有将它设置为“可用性数据库”之一。

所以，这是我的问题：我是否应该将主数据库添加到“可用性数据库”列表中，如果我这样做会导致问题吗？

背景：

我的部门正在从带有镜像的 SQL Server 2008R2 升级到带有无集群可用性组的 SQL Server 2017。直到最近，测试才发现没有问题或危险信号。然后我们安装了 CU1，遇到了问题，卸载了 CU1，问题就消失了。操作系统是带有最新补丁的 server 2016。

CU1 后观察到的行为：

使用 SSMS 或 tsql，我们可以创建一个 2 副本无集群同步可用性组，并向其中添加一个数据库。该组可以多次故障转移而不会出现问题。啊，但是添加第二个数据库，故障转移会出现问题。其中一个数据库总是会处于不同步状态。再多的摆弄也无法让它复活。如果我删除并重新创建整个内容，则可能是其他数据库未同步。记录器中的相关错误消息是“由于异常 35222，无法更新副本状态”。这似乎是一条与集群相关的消息，但由于我们是无集群的，我感到很困惑。在我们卸载两个副本上的 CU1 后，我能够创建 AG 并添加 22 个数据库（包括两个原始数据库）。故障转移没有问题。附带说明一下，自动播种并不总是适用于多个数据库。该操作将失败并显示“种子检查消息超时”。从 AG 中删除这些数据库并一次添加一个是成功的。

我的问题是：

在 CU1 之后，是否还有其他人遇到过无集群 AG 的问题？如果是这样，你在我没有成功的地方成功了吗？

评论/意见：

我认为 CU 将在与 SP 相同的级别进行测试。虽然我知道无论测试多么彻底，错误都会出现，但在第一个测试中发生这种情况令人不安。这将导致我们在部署之前对每个 CU 进行真正的压力测试，这意味着我们不会在它们出现时部署它们。我们只会在我们认为有必要时部署它们。我们是一个没有专门的 dba 的小型组织，需要对所采取的行动有所选择。

我在 SQL Server 2016 SP1 Standard 上设置了 AlwaysOn AG。然后我创建了一个 AG 并添加了一个带有自动种子（同步模式）的数据库。我使用 SSMS 2017 来创建我的 AG 并添加数据库。一切正常。

但是，当我检查等待统计信息时，我在主服务器上获得了 VDI_CLIENT_OTHER (80%) 类型的等待，平均资源时间为 42 秒。经过一番研究，我发现等待是由执行命令 VDI_CLIENT_WORKER 的 4 个会话生成的。据我了解，等待意味着在播种新 AG 时线程正在等待工作。但我不明白的是为什么我有那些等待，因为我的 AG 准备好了，为什么我有 4 个执行 VDI_CLIENT_WORKER 命令的会话？我发现每个调度程序都有一个 VDI_CLIENT_WORKER

有人可以尝试解释 VDI_CLIENT_WORKER-command 的作用以及如何解决许多 VDI_CLIENT_OTHER 等待的问题吗？

今年秋天，我们将关闭整个数据中心的电源以更换有缺陷的电源模块。没有 DR 站点可以移动任何东西，公司的最后一点都驻留在一个 DC 中的一个位置。关闭 2 节点可用性组的最佳方法是什么？我是否应该从 AG 中删除数据库然后关闭服务器电源？在电源工作完成后使服务器联机时。我应该先启动共享见证服务器，然后再启动主服务器和第二个服务器吗？然后将数据库重新添加到AG？我们在 VMware 环境中运行 Windows 2008 R2 和 SQL Server Enterprise 2012 核心版。

我有一个由 2 个 SQLServer 2016 实例（WSFC 中的 2 个 Windows 2016 服务器）组成的旧可用性组 我还有 2 个新的 SQLServer 2017 实例（2 个 Windows Server 2016），我最初想加入 2016 AG。

这是一个 0 停机迁移场景，一旦数据库与 2017 年的数据库对齐，2016 年的服务器应该被解雇。

令我非常失望的是，我发现无法将 2017 实例加入现有的 2016 AG，但我无法承担停止生产、获取和恢复备份、等待数据库同步、更改名称（以及可能的新 AG 的 ip) 与原始 AG 匹配，除非作为最后一个资源......

然后我遇到了名为“Distributed AG Group”的 2016 年新服务，我开始考虑将它用于我的迁移场景......基本上是这样的：

1. 使用 SQL 2017 实例创建一个新的 AG
2. 在原来的2016 AG和新的2017 AG之间创建一个分布式AG（应用继续连接2016的监听器）
3. 等待 DB 同步在 2017 AG 中发生
4. 以 2017 AG 为主
5. 从分布式 AG 中删除 2016 AG（应用程序停机时间短）
6. 更改 2017 监听器的名称和 ip（应用程序再次启动）
7. 移除分布式AG

是否可行？我可以在分布式 AG 中混合 2016 和 2017 …

我已经成为 DBA 大约 2 年了，我仍然不了解 AlwaysOn 可用性组的一些微妙之处。首先，据我所知，它们只是麻烦，主要是因为我们环境中经常发生的情况。

我们每月打一次 Windows 补丁，预计服务器会重新启动。大约每月一次，我们会遇到这样一种情况，即具有多个可用性组的集群在集群的节点之间进行自我划分。

如果我正在安排备份作业，我通常会通过主服务器的多服务器管理来管理这些作业。我按照侦听器的分辨率执行此操作，因为它连接到可用性组的主节点。问题是，如果我指定“所有数据库”，则无论给定可用性组的主要/次要状态如何，整个节点都会尝试备份。

因此，在我们的监控解决方案中会产生很多干扰，因为任何具有分散可用性组的集群都会返回备份失败状态，因为失败发生在尝试在二级AG。

在这些情况下，我是否必须编写由可用性组运行的作业脚本？

是否存在仅备份该节点主要的可用性组的设置组合？

我已经提出了合并组的论点，以便我们可以通过 SERVER 而不是 AG 进行管理。我的老板认为我们应该使用 AG 来跨集群进行负载平衡，这样我们就不必为仅用于 HADR 的节点支付 SQL 许可证。我已经提出了这些漫反射 AG 可能出错的所有内容，但也许有一些我不知道的东西。

为清楚起见，我知道我们可以将侦听器指向不同的 AG，并且它们将连接到其各自节点的主节点。我似乎无法管理任何类型的通用备份计划，这些计划不会针对这些拆分 AG 情况产生监控和写入功能冲突。任何人都可以提供的任何清晰度将不胜感激。

我有一个 SQL 2016 Ent。具有 3 个节点的 AG 版。我们在 AG 中有一个包含 5 个文件流表的数据库。每个表都在它自己的文件流数据文件中。今天我修复了一个错误，即通过重建索引将所有文件保存到一个文件流数据文件中。

在 dev 中，我们没有 AG，数据库处于简单恢复中。空间被收回了。之前和之后看起来像这样：

当我在 AG 中运行相同的代码时，所有节点都如下所示：

文件已移至正确的文件流数据文件，但未从原始数据文件中恢复空间。

一开始我还以为是车库收藏，看了Paul Randal的博文。我缩小了日志文件，然后创建了一个垃圾表，通过显式转换添加了大量行，运行了日志备份和检查点，所有这些都在主节点上。日志文件确实增长了，之前活动的 VLF 被标记为不活动。

更复杂的是，备份是辅助节点上的完全复制\日志备份。

在这种情况下回收空间的正确方法是什么？

编辑：按照安迪在他博客中的步骤后，空间被收回。每个 AG 节点看起来像：

最近，在我们进行统计更新时，我们的阻止进程仪表板一直在报告被阻止的进程。

很快就找到了原因：更新统计作业步骤 (T-SQL) 在辅助 SQL Server 实例和主 SQL Server 实例上都启动。该作业更新同一数据库的多个统计信息，该数据库是 AlwaysOn 可用性组的一部分。我希望这会在辅助实例上失败。

故障转移历史的简要概述：

由于许可而应保持活动状态的服务器 A（将被命名为活动服务器），在 20/02 晚上 9 点意外故障转移到服务器 B（被动服务器）。

在计划外故障转移之后，我们在 2002 年 2 月 21 日中午 12 点进行了另一次（但这次是计划内的）手动故障转移回 Active Server。

工作经历

在第一次故障转移之前一切都很好，活动服务器是唯一运行该作业的服务器。

一项工作正在运行。 我们看到在活动端运行的统计更新。（这是当时的主要副本）

在无源服务器作为主要副本的短时间内，我们没有任何监控并且作业历史记录被清除。

故障转移后，回到“正常”状态，在被动节点上处于主节点不到 24 小时后，被动实例上的作业步骤也已在主动实例上启动并运行。

（我杀死了会话）。

现在对我来说有趣的部分是，这两个作业都在活动服务器上运行，似乎该作业正在使用侦听器访问数据库。但这可能是一个完全不同的原因。

有一个复制作业 PowerShell 任务在每晚凌晨 01 点运行 (dbatools)：

powershell.exe Copy-DbaAgentJob -ExcludeJob "CopyJobs,CopyLogins" -Source INDCSPSQLA01  -Destination  INDCSPSQLP01     -Force

我的猜测现在是针对一次，作业复制发生在主动、次要节点 --> 带有 -Force 的主要被动节点。这发生在 21/02 01 AM。

问题

为什么被动实例上的作业步骤在主动实例的数据库上执行？

清单

在这两种情况下，作业目标都是本地的：

EXEC @ReturnCode = msdb.dbo.sp_add_jobserver @job_id = @jobId, @server_name = N'(local)'

服务器名称正确

select …