Data Domain: Explicação da ressincronização da replicação
Summary: Este artigo explica como a "ressincronização de replicação" determina quais dados enviar pela rede.
Instructions
OBJETIVO
- Este artigo explica como a "ressincronização de replicação" determina quais dados enviar pela rede. Para obter o procedimento sobre como executar uma ressincronização, consulte o artigo: Data Domain: Como interromper e ressincronizar a replicação de diretório.
APLICA-SE A
- Todos os modelos de Data Domain (DD)
- Replicação de diretório
- Todas as versões de software 4.3 e posteriores
SOLUÇÃO
A ressincronização é quase idêntica à inicialização e pode até ser especificada em vez de inicializar para contextos de replicação de diretório , com as seguintes diferenças:
*não* é necessário que o diretório de réplica esteja vazio. Internamente, o destino move os arquivos existentes para fora do caminho.
(Nas versões 4.3 a 4.5, inclusive, isso é renomeando esses arquivos para um $destdir/.ddrsaved/ directory. No 4.6+, é feito um snapshot e, em seguida, excluindo os arquivos do contexto de replicação $destdir.)
Para cada arquivo no diretório de origem, ele verifica se existe o mesmo caminho relativo no destino (verificando o $destdir/.ddrsavedou o snapshot).
Se o arquivo existir, ele verificará se o arquivo de destino é idêntico ao arquivo de origem.
Se for idêntico, o arquivo de réplica existente será vinculado no local sem nenhum requisito adicional para filtrar ou enviar qualquer um de seus conteúdos.
A verificação de identidade do arquivo acontece em tempo constante.
A verificação será bem-sucedida se o arquivo de réplica tiver sido criado pela replicação >de diretório = 4.3.
Isso implica que a propagação pode ser realizada executando a replicação de conjunto (conveniente se os Data Domains estiverem em uma LAN), interrompendo a replicação de conjunto e, em seguida, fazendo a ressincronização da replicação de diretório.
Se um arquivo de réplica não for encontrado ou o conteúdo não corresponder, o arquivo será replicado normalmente, ou seja, filtrado segmento a segmento.
O objetivo da ressincronização é evitar essa filtragem sempre que possível.
Uma possível armadilha é que a atividade humana ou a lógica do aplicativo que renomeia arquivos pode fazer com que os arquivos de origem ou réplica sejam movidos ou renomeados após a interrupção da replicação, antes da ressincronização.
Isso faz com que a pesquisa de nome de caminho na ressincronização não encontre correspondência e precisa de filtragem completa de cada arquivo.
Como os segmentos existem no destino, uma alta compactação de replicação é alcançada, mas uma oportunidade é perdida para evitar o envio das referências de segmento e a filtragem inicial delas.
-
No 4.5, a ressincronização falha se a réplica tiver ou já tiver o bloqueio de retenção ativado.
-
No 4.6 e posterior, há alguns requisitos adicionais relacionados a arquivos bloqueados para retenção na réplica. Em essência, qualquer arquivo bloqueado para retenção no destino também deve existir e deve ter conteúdo e atributos correspondentes no originador. Isso é para impedir que a replicação tente remover arquivos bloqueados para retenção na réplica.