Data Domain: Spiegazione della risincronizzazione della replica
Summary: Questo articolo spiega in che modo la "risincronizzazione della replica" determina quali dati inviare in rete.
Instructions
SCOPO
- Questo articolo spiega in che modo la "replication resync" determina quali dati inviare in rete. Per la procedura su come eseguire una risincronizzazione, consultare l'articolo: Data Domain: Come interrompere e risincronizzare la replica di directory.
SI APPLICA A
- Tutti i modelli Data Domain (DD)
- Replica di directory
- Tutte le versioni software 4.3 e successive
SOLUZIONE
Resync è quasi identico a initialize e può anche essere specificato al posto di initialize per i contesti di replica di directory, con le seguenti differenze:
La directory di replica *non* deve essere vuota. Internamente, la destinazione sposta i file esistenti.
(Nella versione da 4.3 a 4.5 inclusa, questo avviene rinominando questi file in un $destdir/.ddrsaved/ directory. Nella versione 4.6+, è creando un'istantanea e quindi eliminando i file dal contesto di replica $destdir).
Per ogni file nella directory di origine, verifica se esiste lo stesso percorso relativo sulla destinazione (controllando il $destdir/.ddrsavedo l'istantanea).
Se il file esiste, verifica se il file di destinazione è identico al file di origine.
Se è identico, il file di replica esistente viene collegato direttamente senza ulteriori requisiti per filtrare o inviare il suo contenuto.
Il controllo dell'identità dei file avviene in tempo costante.
Il controllo ha esito positivo se il file di replica è stato creato dalla replica della >directory = 4.3.
Ciò implica che il seeding può essere eseguito eseguendo la replica della raccolta (utile se i Data Domain si trovano in una LAN), quindi interrompendo la replica della raccolta e quindi eseguendo la risincronizzazione della replica della directory.
Se non viene trovato un file di replica o il contenuto non corrisponde, il file viene replicato normalmente, ovvero filtrato segmento per segmento.
Lo scopo della risincronizzazione è quello di evitare questo filtraggio, ove possibile.
Una potenziale insidia è rappresentata dal fatto che l'attività umana o la logica dell'applicazione che rinomina i file potrebbe causare lo spostamento o la ridenominazione dei file di origine o di replica dopo l'interruzione della replica, prima della risincronizzazione.
In questo modo la ricerca del nome del percorso nella risincronizzazione non trova alcuna corrispondenza e richiede il filtraggio completo di ogni file.
Poiché i segmenti esistono sulla destinazione, si ottiene un'elevata compressione della replica, ma si perde l'opportunità di evitare innanzitutto l'invio dei riferimenti al segmento e il relativo filtraggio.
-
Nella versione 4.5 la risincronizzazione ha esito negativo se la replica ha, o ha mai avuto, il blocco di retention abilitato.
-
Nella versione 4.6 e successive, esistono alcuni requisiti aggiuntivi relativi ai file con Retention Lock nella replica. In sostanza, anche qualsiasi file con Retention Lock sulla destinazione deve esistere e deve avere contenuto e attributi corrispondenti nel file di origine. Ciò impedisce alla replica di tentare di rimuovere i file bloccati dalla replica.