Data Domain: Objaśnienie ponownej synchronizacji replikacji
Summary: W tym artykule wyjaśniono, w jaki sposób "ponowna synchronizacja replikacji" określa, jakie dane mają być wysyłane w sieci.
Instructions
ZASTOSOWANIE
- W tym artykule wyjaśniono, w jaki sposób "ponowna synchronizacja replikacji" określa, jakie dane mają być wysyłane w sieci. Aby uzyskać procedurę przeprowadzania ponownej synchronizacji, zapoznaj się z artykułem: Data Domain: Jak przerwać i ponownie zsynchronizować replikację katalogu.
DOTYCZY
- Wszystkie modele Data Domain (DD)
- Replikacja katalogów
- Wszystkie wersje oprogramowania 4.3 i nowsze
ROZWIĄZANIE
Ponowna synchronizacja jest niemal identyczna z inicjalizacją i może być nawet określona zamiast inicjowania dla kontekstów replikacji katalogu , z następującymi różnicami:
Katalog repliki *nie* musi być pusty. Wewnętrznie miejsce docelowe usuwa istniejące pliki z drogi.
(W wersjach od 4.3 do 4.5 włącznie polega to na zmianie nazw tych plików na $destdir/.ddrsaved/ directory. W wersji 4.6+ jest to wykonanie migawki, a następnie usunięcie plików z kontekstu replikacji $destdir).
Dla każdego pliku w katalogu źródłowym sprawdza, czy ta sama ścieżka względna istnieje w katalogu docelowym (sprawdzając $destdir/.ddrsavedlub migawki).
Jeśli plik istnieje, sprawdza, czy plik docelowy jest identyczny z plikiem źródłowym.
Jeśli jest identyczny, istniejący plik repliki jest trwale połączony z miejscem bez konieczności filtrowania lub wysyłania jego zawartości.
Sprawdzanie tożsamości pliku odbywa się w stałym czasie.
Sprawdzanie zakończy się pomyślnie, jeśli plik repliki został utworzony przez polecenie katalogu "replication >" = 4.3.
Oznacza to, że rozmieszczanie można zrealizować, uruchamiając replikację kolekcji (wygodne, jeśli domeny danych znajdują się w sieci LAN), a następnie przerywając replikację kolekcji, a następnie ponownie synchronizując replikację katalogów.
Jeśli plik repliki nie zostanie znaleziony lub zawartość nie jest zgodna, plik jest replikowany normalnie, to znaczy filtrowany według segmentów.
Celem ponownej synchronizacji jest unikanie tego filtrowania, jeśli jest to możliwe.
Potencjalną pułapką jest to, że aktywność człowieka lub logika aplikacji, która zmienia nazwy plików, może spowodować przeniesienie lub zmianę nazwy pliku źródłowego lub repliki po przerwaniu replikacji przed ponowną synchronizacją.
Powoduje to, że funkcja wyszukiwania ścieżki w ponownej synchronizacji nie znajduje dopasowania i wymaga pełnego filtrowania każdego pliku.
Ponieważ segmenty istnieją w miejscu docelowym, osiągana jest wysoka kompresja replikacji, ale traci się możliwość uniknięcia wysyłania odwołań do segmentów i filtrowania ich w pierwszej kolejności.
-
W wersji 4.5 ponowna synchronizacja kończy się niepowodzeniem, jeśli replika ma lub kiedykolwiek miała włączoną blokadę retencji.
-
W wersji 4.6 i nowszych istnieją pewne dodatkowe wymagania związane z plikami zablokowanymi przechowywaniem w replice. Zasadniczo każdy plik z blokadą przechowywania w miejscu docelowym musi również istnieć i musi mieć pasującą zawartość i atrybuty w źródle źródła. Ma to na celu uniemożliwienie replikacji próby usunięcia plików objętych przechowywaniem z repliki.