• Denne artikkelen forklarer hvordan "replication resync" bestemmer hvilke data som skal sendes over nettverket. Hvis du vil se fremgangsmåten for hvordan du utfører en ny synkronisering, kan du se artikkelen: Data Domain: Slik bryter og synkroniserer du katalogreplikering på nytt.

GJELDER FOR

• Alle Data Domain-modeller (DD)
• Katalogreplikering
• Alle programvareversjoner 4.3 og nyere

LØSNING

Resync er nesten identisk med initialisering, og kan til og med angis i stedet for initialisering for katalogreplikeringskontekster, med følgende forskjeller:

Replikakatalogen er *ikke* påkrevd å være tom. Internt flytter destinasjonen de eksisterende filene ut av veien.

(I 4.3 til og med 4.5 er dette ved å gi disse filene nytt navn til en $destdir/.ddrsaved/ directory. I 4.6+ er det ved å lage et øyeblikksbilde og deretter slette filene fra replikeringskonteksten $destdir.)

For hver fil i kildekatalogen kontrollerer den om den samme relative banen finnes på destinasjonen (kontroller $destdir/.ddrsaved, eller øyeblikksbildet). 

Hvis filen finnes, kontrollerer den om målfilen er identisk med kildefilen. 

Hvis den er identisk, er den eksisterende replikafilen hardt koblet på plass uten ytterligere krav om å filtrere eller sende noe av innholdet.

Filidentitetskontrollen skjer i konstant tid.

Kontrollen lykkes hvis replikafilen ble opprettet av katalogreplikering >= 4.3.

Dette innebærer at seeding kan oppnås ved å kjøre samlingsreplikering (praktisk hvis datadomenene er i et LAN), og deretter bryte samlingsreplikering, og deretter gjøre katalogreplikering resync.

Hvis det ikke blir funnet en replikafil eller innholdet ikke samsvarer, replikeres filen på vanlig måte, det vil si filtreres på segment-for-segment-basis.

Hele poenget med resynkronisering er å unngå denne filtreringen der det er mulig.

En potensiell fallgruve er at menneskelig aktivitet eller programlogikk som gir nytt navn til filer, kan føre til at avsender- eller replikafilene flyttes eller gis nytt navn etter at replikasjonen ble brutt, før resynkronisering.

Dette fører til at banenavnoppslaget i resync ikke finner samsvar, og krever full filtrering av hver fil.

Siden segmentene finnes på målet, oppnås høy replikeringskomprimering, men en mulighet går glipp av for å unngå å sende segmentreferansene og filtrere dem i utgangspunktet.

• I 4.5 mislykkes resynkronisering hvis replikaen har, eller noensinne har hatt, oppbevaringslås aktivert.
• I 4.6 og nyere er det noen tilleggskrav knyttet til låste oppbevaringsfiler i replikaen. I hovedsak må enhver oppbevaringslåst fil på destinasjonen også eksistere og må ha samsvarende innhold og attributter på opphavsmannen. Dette er for å hindre at replikering prøver å fjerne oppbevaringslåste filer i replikaen.

• Data Domain: Replikeringskontekst er deaktivert på grunn av potensielt NVRAM-tap
• Data Domain: Hvordan bryte og synkronisere katalogreplikering på nytt