分布式可用性组拒绝使用 SUSPEND_FROM_CAPTURE 重新同步我的 FILESTREAM 数据库

我的家庭实验室设置包括四台服务器，这些服务器在两台物理主机上运行在 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 之间的手动故障转移都正常工作，并且没有数据丢失。

在我的测试服务器上，我在我的 Distributed AG Forwarder 上看到以下错误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 联机丛书。

^{（喜欢 Books Online 参考，顺便说一句）}

为了排除故障，我已经完全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: 驱动器上运行不会报告任何错误。

dbcc checkdb (dag_test_db)从主要返回没有错误。

我写了一个查询来从文件流中读取所有数据；也许这会显示一些有趣的东西。获得该测试的结果后，我将更新问题。查询使用ApplicationIntent=ReadOnly通过 sqlcmd.exe 连接到转发器实例。这是查询，对于那些感兴趣的人：

USE [dag_test_db];
GO
DECLARE @d varbinary(max);
DECLARE @f nvarchar(260);
DECLARE cur CURSOR LOCAL FORWARD_ONLY READ_ONLY
FOR
SELECT
      [f].[file_data]
    , [f].[original_file_name]
FROM [dbo].[files] [f];

OPEN cur;
FETCH NEXT FROM cur INTO @d, @f;
WHILE @@FETCH_STATUS = 0
BEGIN
    PRINT @f + N': ' + CONVERT(nvarchar(11), LEN(@d), 0);
    FETCH NEXT FROM cur INTO @d, @f;
END
CLOSE cur;
DEALLOCATE cur;

也许一些勇敢的年轻 Microsoft 工程师可以帮助我理解是什么导致了错误fsdohdlr.cpp at 2474？

DBCC CHECKDB ([dag_test_db]) WITH NO_INFOMSGS;在全球主要显示没有腐败。

将报错信息中的文件名转换为十进制的LSN，fn_dblog在global primary上使用显示日志内容显示：

错误消息中引用的文件确实存在于转发器的文件系统中：

C:\Users\Hannah>目录 F:\SQLServer\HV2019\FILESTREAM\dag_test_db\dag_test_db_fg_fs_f01\3e6a0757-7405-4ee2-b8a8-df878b8cd7ce\a10e3ae8-922c-4821-904e-7555c0316 30d\0000008f-000292b0-0006
 驱动器 F 中的卷没有标签。
 卷序列号是 90BA-CEC3

 F:\SQLServer\HV2019\FILESTREAM\dag_test_db\dag_test_db_fg_fs_f01\3e6a0757-7405-4ee2-b8a8-df878b8cd7ce\a10e3ae8-922c-4821-904e-7555c031630d目录

2023 年 4 月 28 日晚上 10:27 797,346 0000008f-000292b0-0006
               1 文件 797,346 字节
               0 目录 123,663,937,536 字节空闲

icacls对于转发器上的相关路径显示：

icacls F:\SQLServer\HV2019\FILESTREAM\dag_test_db\dag_test_db_fg_fs_f01\3e6a0757-7405-4ee2-b8a8-df878b8cd7ce\a10e3ae8-922c-4821-904e-7555c031630d
F:\SQLServer\HV2019\FILESTREAM\dag_test_db\dag_test_db_fg_fs_f01\3e6a0757-7405-4ee2-b8a8-df878b8cd7ce\a10e3ae8-922c-4821-904e-7555c031630d NT SERVICE\MSSQL$ HV2019:(I)(OI)(CI)(F )
                                                                                                                                           所有者权利：(I)(OI)(CI)(F)
                                                                                                                                           内置\管理员：(I)(OI)(CI)(F)

成功处理1个文件；处理 0 个文件失败

从我所看到的来看，权限看起来不错——SQL Server 服务作为对文件的完全控制，实际上整个文件夹结构来自F:\SQLServer\HV2019.