• Denne artikel forklarer, hvordan "replikeringsgensynkronisering" bestemmer, hvilke data der skal sendes via netværket. For proceduren for, hvordan du udfører en gensynkronisering, se artiklen: Data Domain: Sådan bryder og synkroniserer du biblioteksreplikering igen.

GÆLDER FOR

• Alle Data Domain-modeller (DD)
• Biblioteksreplikering
• Alle softwareudgivelser 4.3 og derover

LØSNING

Gensynkronisering er næsten identisk med initialisering og kan endda angives i stedet for initialisering for mappereplikeringskontekster med følgende forskelle:

Replikabiblioteket skal *ikke* være tomt. Internt flytter destinationen de eksisterende filer af vejen.

(I 4.3 til og med 4.5 er dette ved at omdøbe disse filer til en $destdir/.ddrsaved/ directory. I 4.6+ er det ved at lave et øjebliksbillede og derefter slette filerne fra replikeringskonteksten $destdir).

For hver fil i kildemappen kontrolleres det, om den samme relative sti findes på destinationen (kontrol af $destdir/.ddrsavedeller snapshottet). 

Hvis filen findes, kontrollerer den, om destinationsfilen er identisk med kildefilen. 

Hvis den er identisk, er den eksisterende replikafil hårdt sammenkædet på plads uden yderligere krav om at filtrere eller sende noget af dens indhold.

Filidentitetskontrollen sker i konstant tid.

Kontrollen lykkes, hvis replikafilen er oprettet af directory replication >= 4.3.

Dette indebærer, at seeding kan opnås ved at køre samlingsreplikering (praktisk, hvis Data Domains er i et LAN), derefter bryde samlingsreplikering og derefter udføre gensynkronisering af mappereplikering.

Hvis der ikke findes en replikafil, eller indholdet ikke stemmer overens, replikeres filen normalt, dvs. filtreres segment efter segment.

Hele pointen med gensynkronisering er at undgå denne filtrering, hvor det er muligt.

En potentiel faldgrube er, at menneskelig aktivitet eller programlogik, der omdøber filer, kan medføre, at ophavs- eller replikafilerne flyttes eller omdøbes, efter at replikering blev brudt, før den synkroniseres igen.

Dette medfører, at stinavneopslaget i gensynkronisering ikke finder noget match, og kræver fuld filtrering af hver fil.

Da segmenterne findes på destinationen, opnås komprimering med høj replikering, men en mulighed forpasses for at undgå at sende segmentreferencerne og filtrere dem i første omgang.

• I 4.5 mislykkes gensynkroniseringen, hvis replikaen har eller nogensinde har haft fastholdelseslås aktiveret.
• I 4.6 og derover er der nogle yderligere krav relateret til fastholdelseslåste filer på replikaen. I det væsentlige skal enhver fastholdelseslåst fil på destinationen også eksistere og skal have matchende indhold og attributter på ophavsmanden. Dette er for at forhindre, at replikering forsøger at fjerne fastholdelseslåste filer på replikaen.

• Data Domain: Replikeringskontekst er deaktiveret på grund af potentielt NVRAM-tab
• Data Domain: Sådan bryder og synkroniserer du biblioteksreplikering igen