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.

This article applies to This article does not apply to This article is not tied to any specific product. Not all product versions are identified in this article.
Check out other resources

Instructions

Zweck

 

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.

 

 

Informationen zur erneuten Synchronisierung mit der Funktion "Retention Lock":
  • 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.

 

Referenz

 

 

Additional Information

 

Affected Products

Data Domain

Products

Data Domain
Article Properties
Article Number: 000014971
Article Type: How To
Last Modified: 29 May 2025
Version:  7
Find answers to your questions from other Dell users
Support Services
Check if your device is covered by Support Services.