Um backlog é relatado para um membro do Read-Only DFSR depois de remover um filtro de arquivo de replicação

Este artigo fornece uma solução para um problema em que um backlog é relatado para um membro Read-Only depois que você remove um filtro de arquivo de replicação.

Aplica-se a: Windows Server 2019, Windows Server 2016, Windows Server 2012 R2
Número de KB original: 4021676

Sintomas

Considere o seguinte cenário:

• Você está executando o Windows Server 2019, Windows Server 2016 ou Windows Server 2012 R2.
• O sistema usa o DFSR (Distributed File System Replication) e inclui Read-Only pastas replicadas.
• Você está prestando dados independentemente do filtro de replicação de DFSR Leitura/Gravação para Read-Only candidatos membros. Portanto, os arquivos que estão no conjunto de filtros agora existem em todos os membros.
• Após a replicação inicial, você remove um filtro de arquivo de replicação.
• Quando os membros do DFSR detectam a alteração do filtro, todos eles executam uma pesquisa dirWalkerTask para obter conteúdo.
• Em um membro do Read-Only, esse processo cria uma UID para o objeto de arquivo e incrementa o GVSN (número de sequência de versão global) do vetor de versão. No entanto, a alteração local não é propagada.
• O parceiro de leitura/gravação cria sua própria UID para o mesmo arquivo e o membro Read-Only detecta um conflito de nomes.
• Por resolução de conflito padrão, a versão local mais recente do arquivo é selecionada. O membro Read-Only relata que a versão local domina e subsume a atualização do parceiro de leitura/gravação.
• O membro Read-Only incrementa seu GVSN e gera uma lápide para a UID do parceiro de leitura/gravação. No entanto, nenhuma alteração é propagada.

Nesse cenário, um backlog é relatado do membro Read-Only para o parceiro de leitura/gravação porque o serviço DFSR tem duas alterações locais que não são replicadas para seu parceiro. A primeira entrada de relatório é para a alteração local quando o DFSR apresenta o arquivo como um novo objeto. A segunda entrada é criada quando o DFSR gera uma lápide para a versão do arquivo do parceiro De leitura/gravação que perdeu a resolução de conflitos. Ele faz isso excluindo essa versão do arquivo.

Motivo

Este é o comportamento padrão. O membro Read-Only aplica o mecanismo padrão de resolução de conflitos ao novo conteúdo de replicação se um filtro for removido e o conteúdo existente precisar ser integrado ao DFSR.

Resolução

Na maioria das circunstâncias, você pode ignorar com segurança os backlogs relatados no membro do Read-Only do DFSR para a direção do parceiro de leitura/gravação. Isso ocorre porque um membro Read-Only não se destina a ter alterações reais.

Se apenas alguns arquivos forem afetados, considere fazer alterações genéricas nos arquivos no membro leitura/gravação.

Geralmente, uma sincronização inicial é necessária para que o membro Read-Only remova esse backlog.

Mais informações

Quando você usa scripts Windows PowerShell e o Get-DfsrBacklog cmdlet para criar uma visão geral para várias configurações do DFSR, talvez você queira considerar a seguinte lógica para excluir saídas de backlog de membros Read-Only para seus parceiros:

#variables for checking multiple DFSR setups, may be different in your existing script
$RGName="ReplicationGroupName"
$RFName="ReplicatedFolderName"
$SMem="SendingMember"
$RMem="ReceivingMember"

#new variable for the DFSR subcription for the RF, containing the value/attribute "ReadOnly"; obtained by Get-DfsrMembership

$DfsrSubscription=Get-DfsrMembership -Groupname $RGName -Computername $SMem | Where-object {$_.foldername -eq $RFName}

#now gather only the Backlog output, when the senders configuration for this RF is not Read-only

if ($DfsrSubscription.ReadOnly -eq 0)
{
    Get-DfsrBacklog -Groupname $RGName -Foldername $RFName -SourceComputerName $SMem -DestinationComputerName $RMem -verbose
}
else
{
    Write-Host "Backlog detection skipped because Sending Member ($SMem) is Read-only for this RF ($RFName)"
}

Resultado: Em vez da saída de backlog do membro Read-Only, agora você verá a seguinte entrada de relatório:

Detecção de backlog ignorada porque o Membro de Envio (SendingMember) é Read-Only para este RF (ReplicadFolderName)

• Quando ele detecta e marca GUIDs de banco de dados obsoletos (GcTask::GcStaleDbGuids)
• Quando ele sinaliza aos parceiros de replicação que ele está vivo e aguardando atualizações (GcTask::GcSendDbKeepAlive)

Para obter mais informações sobre essas funções, consulte A UID das lápides de vetor de versão no Processamento Atualizações.

Essas atualizações genéricas aumentam os números de sequência de versão (e, portanto, alteram o vetor da cadeia de versões do GVSN) no membro Read-Only. No entanto, o membro Read-Only nunca compartilha essas atualizações com seus parceiros de replicação, portanto, as atualizações nunca são rastreadas usando o vetor de versão global nos outros membros. Portanto, uma contagem de backlogs mostra um delta visível entre o membro Read-Only e seus parceiros de replicação.

Para impedir que essas atualizações gerem dados confusos, os scripts que coletam dados de backlog devem excluir Read-Only membros.