Data Domain: Erklärung zur Neusynchronisierung der Replikation
Summary: In diesem Artikel wird erläutert, wie die "Replikationsneusynchronisierung" bestimmt, welche Daten über das Netzwerk gesendet werden sollen.
Instructions
Zweck
- In diesem Artikel wird erläutert, wie mit der Neusynchronisierung der Replikation bestimmt wird, welche Daten über das Netzwerk gesendet werden sollen. Das Verfahren zum Durchführen einer Neusynchronisierung finden Sie im Artikel: Data Domain: Anleitung zum Unterbrechen und erneuten Synchronisieren der Verzeichnisreplikation.
GILT FÜR
- Alle Data Domain-(DD-)Modelle
- Verzeichnisreplikation
- Alle Softwareversionen 4.3 und höher
LÖSUNG
Resync ist nahezu identisch mit initialize und kann sogar anstelle von initialize für Verzeichnisreplikationskontexte angegeben werden, mit den folgenden Unterschieden:
Das Replikatverzeichnis muss *nicht* leer sein. Intern verschiebt das Ziel die vorhandenen Dateien aus dem Weg.
(In Version 4.3 bis einschließlich 4.5 werden diese Dateien in ein $destdir/.ddrsaved/ directory. In 4.6+ wird ein Snapshot erstellt und dann die Dateien aus dem Replikationskontext gelöscht $destdir.)
Für jede Datei im Quellverzeichnis wird geprüft, ob derselbe relative Pfad auf dem Ziel vorhanden ist (Überprüfung der $destdir/.ddrsavedoder den Snapshot).
Wenn die Datei vorhanden ist, wird geprüft, ob die Zieldatei mit der Quelldatei identisch ist.
Wenn sie identisch ist, wird die vorhandene Replikatdatei fest verknüpft, ohne dass weitere Informationen gefiltert oder gesendet werden müssen.
Die Dateiidentitätsprüfung erfolgt in gleichbleibender Zeit.
Die Prüfung ist erfolgreich, wenn die Replikatdatei durch Verzeichnisreplikation >= 4.3 erstellt wurde.
Dies bedeutet, dass das Seeding durch Ausführen der Sammelreplikation (praktisch, wenn sich die Data Domains in einem LAN befinden), Unterbrechen der Sammelreplikation und anschließendes erneutes Synchronisieren der Verzeichnisreplikation erreicht werden kann.
Wenn eine Replikatdatei nicht gefunden wird oder der Inhalt nicht übereinstimmt, wird die Datei normal repliziert, d. h., segmentweise gefiltert.
Der Sinn der Neusynchronisierung besteht darin, diese Filterung nach Möglichkeit zu vermeiden.
Ein potenzieller Fallstrick besteht darin, dass menschliche Aktivitäten oder Anwendungslogik, die Dateien umbenennt, dazu führen könnten, dass die Ursprungs- oder Replikatdateien verschoben oder umbenannt werden, nachdem die Replikation vor der Neusynchronisierung unterbrochen wurde.
Dies führt dazu, dass bei der Pfadnamensuche bei der Neusynchronisierung keine Übereinstimmung gefunden wird und jede Datei vollständig gefiltert werden muss.
Da die Segmente auf dem Ziel vorhanden sind, wird eine hohe Replikationskomprimierung erreicht, aber es wird eine Gelegenheit verpasst, das Senden und Filtern der Segmentreferenzen von vornherein zu vermeiden.
-
In 4.5 schlägt die Neusynchronisierung fehl, wenn für das Replikat eine Aufbewahrungssperre aktiviert ist oder jemals aktiviert war.
-
In Version 4.6 und höher gibt es einige zusätzliche Anforderungen in Bezug auf Dateien mit Aufbewahrungssperre auf dem Replikat. Im Wesentlichen müssen alle Dateien mit Aufbewahrungssperre auf dem Ziel ebenfalls vorhanden sein und übereinstimmende Inhalte und Attribute auf dem Absender aufweisen. Dadurch soll verhindert werden, dass die Replikation versucht, Dateien mit Aufbewahrungssperre auf dem Replikat zu entfernen.