• I den här artikeln beskrivs hur "replikeringssynkronisering" avgör vilka data som ska skickas över nätverket. Anvisningar om hur du utför en omsynkronisering finns i artikeln: Data Domain: Så här bryter och synkroniserar du om katalogreplikering.

GÄLLER

• Alla Data Domain-modeller (DD)
• Katalogreplikering
• Alla mjukvaruversioner 4.3 och senare

LÖSNING

Omsynkronisering är nästan identiskt med initiering och kan till och med anges i stället för initiera för katalogreplikeringskontexter, med följande skillnader:

Replikkatalogen behöver *inte* vara tom. Internt flyttar målet de befintliga filerna ur vägen.

(I 4.3 till och med 4.5 är detta genom att byta namn på dessa filer till en $destdir/.ddrsaved/ directory. I 4.6+ är det genom att göra en ögonblicksbild och sedan ta bort filerna från replikeringskontexten $destdir.)

För varje fil i källkatalogen kontrollerar den om samma relativa sökväg finns på målet (markerar $destdir/.ddrsavedeller ögonblicksbilden). 

Om filen finns kontrollerar den om målfilen är identisk med källfilen. 

Om den är identisk länkas den befintliga replikfilen på plats utan att du behöver filtrera eller skicka något av innehållet.

Filidentitetskontrollen sker i konstant tid.

Kontrollen lyckas om replikfilen har skapats av katalogreplikeringen >= 4.3.

Detta innebär att seeding kan åstadkommas genom att köra samlingsreplikering (praktiskt om Data Domains finns i ett LAN), sedan bryta samlingsreplikeringen och sedan synkronisera om katalogreplikeringen.

Om det inte går att hitta någon replikfil eller om innehållet inte matchar, replikeras filen normalt, d.v.s. filtreras segment för segment.

Hela poängen med omsynkronisering är att undvika den här filtreringen där det är möjligt.

En potentiell fallgrop är att mänsklig aktivitet eller programlogik som byter namn på filer kan leda till att upphovs- eller replikfilerna flyttas eller byter namn efter att replikeringen har brutits innan de synkroniseras om.

Detta gör att pathname-sökningen i resync inte hittar någon matchning och kräver fullständig filtrering av varje fil.

Eftersom segmenten finns på målet uppnås hög replikeringskomprimering, men en möjlighet missas att undvika att skicka segmentreferenserna och filtrera dem i första hand.

• I 4.5 misslyckas omsynkroniseringen om repliken har, eller någonsin har haft, kvarhållningslås aktiverat.
• I 4.6 och senare finns det några ytterligare krav som rör kvarhållningslåsta filer på repliken. I grund och botten måste alla kvarhållningslåsta filer på målet också finnas och måste ha matchande innehåll och attribut på upphovsmannen. Detta för att förhindra replikering från att försöka ta bort kvarhållningslåsta filer på repliken.

• Data Domain: Replikeringskontexten är inaktiverad på grund av potentiell NVRAM-förlust
• Data Domain: Så här bryter och synkroniserar du om katalogreplikering