Data Domain: Uitleg replicatie hersynchronisatie
Summary: In dit artikel wordt uitgelegd hoe de "replication resync" bepaalt welke data via het netwerk moeten worden verzonden.
Instructions
DOEL
- In dit artikel wordt uitgelegd hoe "replication resync" bepaalt welke data via het netwerk moeten worden verzonden. Voor de procedure voor het uitvoeren van een hersynchronisatie, zie het artikel: Data Domain: Directoryreplicatie verbreken en opnieuw synchroniseren.
VAN TOEPASSING OP
- Alle Data Domain (DD)-modellen
- Directoryreplicatie
- Alle softwarereleases 4.3 en hoger
OPLOSSING
Resync is bijna identiek aan initialiseren en kan zelfs worden opgegeven in plaats van initialiseren voor directoryreplicatiecontexten, met de volgende verschillen:
De replicamap hoeft *niet* leeg te zijn. Intern verplaatst de bestemming de bestaande bestanden uit de weg.
(In 4.3 tot en met 4.5 is dit door deze bestanden te hernoemen naar een $destdir/.ddrsaved/ directory. In 4.6+ is dit door een snapshot te maken en vervolgens de bestanden uit de replicatiecontext te verwijderen $destdir.)
Voor elk bestand in de brondirectory wordt gecontroleerd of hetzelfde relatieve pad bestaat op het doel (het controleren van de $destdir/.ddrsaved, of de snapshot).
Als het bestand bestaat, wordt gecontroleerd of het doelbestand identiek is aan het bronbestand.
Als het identiek is, wordt het bestaande replicabestand hard op zijn plaats gekoppeld zonder dat de inhoud ervan verder hoeft te worden gefilterd of verzonden.
De controle van de bestandsidentiteit gebeurt in constante tijd.
De controle is geslaagd als het replicabestand is gemaakt door directoryreplicatie >= 4.3.
Dit houdt in dat seeding kan worden bereikt door verzamelingsreplicatie uit te voeren (handig als de datadomeinen zich in een LAN bevinden), vervolgens de verzamelingsreplicatie te verbreken en vervolgens de mapreplicatie opnieuw te synchroniseren.
Als een replicabestand niet wordt gevonden of de inhoud niet overeenkomt, wordt het bestand normaal gerepliceerd, dat wil zeggen gefilterd op segmentbasis.
Het hele punt van opnieuw synchroniseren is om deze filtering waar mogelijk te vermijden.
Een mogelijke valkuil is dat menselijke activiteit of applicatielogica die bestanden hernoemt, ertoe kan leiden dat de oorspronkelijke of replicabestanden worden verplaatst of hernoemd nadat de replicatie is verbroken, voorafgaand aan opnieuw synchroniseren.
Hierdoor vindt het opzoeken van padnaam in hersynchronisatie geen overeenkomst en moet elk bestand volledig worden gefilterd.
Aangezien de segmenten op de bestemming aanwezig zijn, wordt een hoge replicatiecompressie bereikt, maar wordt een kans gemist om te voorkomen dat de segmentverwijzingen worden verzonden en gefilterd.
-
In 4.5 mislukt hersynchronisatie als de replica retentievergrendeling heeft ingeschakeld of ooit heeft gehad.
-
In 4.6 en hoger zijn er enkele aanvullende vereisten met betrekking tot retentievergrendelde bestanden op de replica. In wezen moet elk retentievergrendeld bestand op het doel ook bestaan en moet het overeenkomende inhoud en attributen hebben op de afzender. Dit is om te voorkomen dat replicatie probeert om vergrendelde bestanden op de replica te verwijderen.