标签: distributed-availability-groups

我们正准备对我们的 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 错误日志和辅助服务器上的事件查看器，没有发现任何异常。

我正在寻找有关如何使用手动播种设置分布式可用性组的分步演练。我可以让自动播种工作，但是当我尝试手动播种时，我无法将辅助数据库放入转发器上的 AG。

如果我在尝试将数据库添加到常规 AG 之前将分布式 AG 添加到辅助服务器，则会收到以下消息：

Msg 41190, Level 16, State 7, Line 22
Availability group 'MYDB' failed to process add-database command.  The local availability replica is not in a state that could process the command.  Verify that the availability group is online and that the local availability replica is the primary replica, then retry the command. 

如果我尝试先添加数据库而不加入辅助数据库上的分布式 AG，我会收到以下消息，因为它认为它应该是主数据库：

Msg 927, Level 14, State 2, Line 22
Database 'MYDB' cannot be opened. It is in the middle of a …

我的家庭实验室设置由跨两台物理主机在 HyperV 中运行的四台服务器组成。SQL Server 实例为 SQLAG101、SQLAG102、SQLAG201 和 SQLAG202。

SQLAG101 和 SQLAG102 是 SQLAG100 可用性组的成员，并且位于 192.168.0.0/24 网络上。

SQLAG201 和 SQLAG202 是 SQLAG200 可用性组的成员，并且位于 192.168.2.0/24 网络上。

流量在两个子网之间路由，这两个子网都是我的实验室的本地子网（即涉及的延迟非常小）。

SQLDAG 是跨越 SQLAG100 和 SQLAG200 的分布式可用性组。已经运行良好约 6 个月，AG 成员服务器之间的自动故障转移以及两个 AG 之间的手动故障转移工作正常，并且没有数据丢失。

在我的测试服务器上，我在使用以下命令的数据库的分布式 AG 转发器上看到以下错误FILESTREAM：

操作系统在“F:\SQLServer\HV2019\FILESTREAM\dag_test_db\dag_test_db_fg_fs_f01\3e6a0757-7405-4ee2-b8a8-df878b8cd7ce\a10e3ae8”上尝试“CreateFileW”时返回错误“2（系统找不到指定的文件。）” -922c-4821-904e-7555c031630d\0000008f-000292b0-0006'位于'fsdohdlr.cpp'(2474)。

由于以下原因，数据库“dag_test_db”的 Always On 可用性组数据移动已暂停：“系统”（源 ID 3；源字符串：“SUSPEND_FROM_CAPTURE”）。要恢复数据库上的数据移动，您需要手动恢复数据库。有关如何恢复可用性数据库的信息，请参阅 SQL Server 联机丛书。

^{（顺便说一句，喜欢在线书籍参考）}

为了排除故障，我已经完全放弃了dag_test_db转发器和辅助转发器。然后，我从主数据库中进行了完整备份，并将其恢复到转发器，并根据需要通过恢复日志备份进行前滚，然后再dag_test_db通过以下方式将备份添加到转发器可用性组中：ALTER DATABASE [dag_test_db] SET HADR AVAILABILITY GROUP = SQLAG200;

最初，转发器 AG (SQLAG200) 的可用性组仪表板显示数据库正在同步，但大约一小时后，同步状态显示NOT SYNCHRONIZING，同步运行状况原因描述显示SUSPEND_FROM_CAPTURE。

chkdsk /f在 F: …

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

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

我们在两个 Windows 集群中部署了分布式 AG。

• Clus01 - 设置了一个 AG，里面没有 DB (AG1)
• Clus02 - 设置了一个 AG，里面没有 DB (AG2)
• Clus01 - 使用 AG1（主要）和 AG2（次要）设置了 DistAG

我们

• 将 Clus02 加入 DistAG
• 在 Clus01 上为 AG1 添加了一个数据库
• 在恢复到 AG2 时恢复了这个数据库
• 将此数据库添加到 Clus02 上的 AG2（显示为主要，但在 DistAG 中实际上是次要的）

Clus02 上的 DB 现在按预期工作……Clus01 上的 DB 上的任何更新都将使用 DistAG 来更新 Clus02 DB。

我们经常从现场刷新这个环境（这是预生产）。所以我们必须将数据库恢复到 CLus01。

对于我们普通的 AG，我们只需从 CLUS01 中删除 DB，还原到 CLUS01，备份并还原到 CLUS02，然后再次加入 AG。

对于 DistAG，我不能

1. 从 CLUS02 上的 AG2 中删除 DB。

   ALTER AVAILABILITY GROUP [AG_G2CoreReporting]
   REMOVE DATABASE [Genesis];
   GO
   

   Run Code Online (Sandbox Code Playgroud)

   我们得到错误

   消息 …

我有一个由 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 …

我可以使用 SQL Server 2017 标准版配置分布式 AG 吗？

我在分布式 AG 设置中观察到 log_send_rate 较低。我知道 AG 使用日志流，所以我认为它不应该与数据有任何关系，但我想知道这是否与它正在传输的数据有关，而不仅仅是操作系统资源（网络、I/O）？

供考虑的基本指标：

• SQL Server 2019-CU16
• 源 RAM 1.5 TB，48 个 CPU <> 目标 RAM 128 GB，48 个 CPU - 内存差异在这里起作用吗？
• 两台服务器位于同一 DC，ping 延迟<1ms。目标服务器是虚拟机。
• ROBOCOPY 测试显示文件传输速率约为 100 MB/s
• 当高事务日志生成活动（例如索引维护或创建）发送到其他副本时 - 它以最大 20 MB/s 的速率传输（这不是预期的）。这是 log_send_queue 堆积起来的时候。
• 另一端的 REDO 速率良好，没有 REDO 队列堆积在那里。

在源 AG 上，我没有看到“发送到传输的字节数/秒”计数器的任何内容，因此我无法确定这是否是瓶颈。

如果我遗漏了任何我应该包含的内容，请提出建议。

我知道SQL Server分布式可用性组可以在两个不同的主要版本之间同步数据，

比方说全球小学 - 2016

二级股份公司 - 2017

此同步将起作用，我也可以进行故障转移。但是我想恢复到 2016 年的故障转移后会发生什么？

1. 这可能吗？
2. 2017 年的所有增量数据都会与 2016 年同步吗？