Grupos de Disponibilidade Distribuída recusando-se a ressincronizar meu banco de dados FILESTREAM com SUSPEND_FROM_CAPTURE

A configuração do meu laboratório doméstico consiste em quatro servidores executados no HyperV em dois hosts físicos. As instâncias do SQL Server são SQLAG101, SQLAG102, SQLAG201 e SQLAG202.

SQLAG101 e SQLAG102 são membros do SQLAG100 Availability Group e estão na rede 192.168.0.0/24.

SQLAG201 e SQLAG202 são membros do SQLAG200 Availability Group e estão na rede 192.168.2.0/24.

O tráfego é roteado entre as duas sub-redes, que são locais para meu laboratório (ou seja, há muito pouca latência envolvida).

SQLDAG é um Grupo de Disponibilidade Distribuído que abrange SQLAG100 e SQLAG200. Isso está funcionando bem há cerca de 6 meses, com failover automático entre os servidores membros do AG e failovers manuais entre os dois AGs funcionando corretamente e sem perda de dados.

No meu servidor de teste, estou vendo os seguintes erros no meu Distributed AG Forwarder para um banco de dados usando FILESTREAM:

O sistema operacional retornou o erro '2(O sistema não pode encontrar o arquivo especificado.)' ao tentar 'CreateFileW' em 'F:\SQLServer\HV2019\FILESTREAM\dag_test_db\dag_test_db_fg_fs_f01\3e6a0757-7405-4ee2-b8a8-df878b8cd7ce\a10e3ae8 -922c-4821-904e-7555c031630d\0000008f-000292b0-0006' em 'fsdohdlr.cpp'(2474).

A movimentação de dados dos Grupos de Disponibilidade Always On para o banco de dados 'dag_test_db' foi suspensa pelo seguinte motivo: "system" (Source ID 3; Source string: 'SUSPEND_FROM_CAPTURE'). Para retomar a movimentação de dados no banco de dados, você precisará retomar o banco de dados manualmente. Para obter informações sobre como retomar um banco de dados de disponibilidade, consulte os Manuais Online do SQL Server.

^{(adoro essa referência do Books Online, btw)}

Para solucionar problemas, abandonei completamente o dag_test_dbencaminhador e os encaminhadores secundários. Em seguida, fiz um backup completo do primário, restaurei-o no encaminhador e continuei restaurando os backups de log conforme necessário antes de adicionar o dag_test_dbretorno ao Grupo de Disponibilidade dos encaminhadores por meio deALTER DATABASE [dag_test_db] SET HADR AVAILABILITY GROUP = SQLAG200;

Inicialmente, o painel do grupo de disponibilidade para os encaminhadores AG (SQLAG200) mostrou o banco de dados como sendo sincronizado, mas após cerca de uma hora o estado de sincronização é exibido NOT SYNCHRONIZINGe a descrição do motivo da integridade da sincronização é exibida SUSPEND_FROM_CAPTURE.

A execução chkdsk /fna unidade F: não relata erros.

dbcc checkdb (dag_test_db)do primário não retorna nenhum erro.

Escrevi uma consulta para ler todos os dados do filestream; talvez isso mostre algo interessante. Assim que tiver os resultados desse teste, atualizarei a pergunta. A consulta está usando ApplicationIntent=ReadOnlyvia sqlcmd.exe para se conectar à instância do encaminhador. Esta é a consulta, para os interessados:

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;

Talvez algum jovem e arrojado engenheiro da Microsoft possa me ajudar a entender o que está causando um erro em fsdohdlr.cpp at 2474?

DBCC CHECKDB ([dag_test_db]) WITH NO_INFOMSGS;no primário global não mostra nenhuma corrupção.

Converter o nome do arquivo na mensagem de erro para um LSN decimal e usar fn_dblogno primário global para exibir o conteúdo do log mostra:

O arquivo referenciado na mensagem de erro existe no sistema de arquivos do encaminhador:

C:\Users\Hannah>dir F:\SQLServer\HV2019\FILESTREAM\dag_test_db\dag_test_db_fg_fs_f01\3e6a0757-7405-4ee2-b8a8-df878b8cd7ce\a10e3ae8-922c-4821-904e-7555c031 630d\0000008f-000292b0-0006
 O volume na unidade F não tem rótulo.
 O número de série do volume é 90BA-CEC3

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

28/04/2023 22:27 797.346 0000008f-000292b0-0006
               1 Arquivo(s) 797.346 bytes
               0 Dir(s) 123.663.937.536 bytes livres

icaclspara o caminho em questão no encaminhador mostra:

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\MS$H V2019:(I)(OI)(CI)(F )
                                                                                                                                           DIREITOS DO PROPRIETÁRIO:(I)(OI)(CI)(F)
                                                                                                                                           BUILTIN\Administradores:(I)(OI)(CI)(F)

1 arquivo processado com sucesso; Falha ao processar 0 arquivos

As permissões parecem boas pelo que posso ver - o serviço SQL Server como controle total sobre o arquivo e, de fato, toda a estrutura de pastas de F:\SQLServer\HV2019.