Kiedy należy ponownie zainicjować przerwany łańcuch replikacji ZFS?

Eva Wong

IceWhale author

Eva Wong jest Technicznym pisarzem i stałym majsterkowiczem w ZimaSpace. Całe życie geek z pasją do homelabów i oprogramowania open-source, specjalizuje się w tłumaczeniu skomplikowanych koncepcji technicznych na przystępne, praktyczne przewodniki. Eva wierzy, że samodzielne hostowanie powinno być zabawą, a nie czymś onieśmielającym. Poprzez swoje samouczki umożliwia społeczności rozwiewanie tajemnic konfiguracji sprzętu, od budowy pierwszego NAS po opanowanie kontenerów Docker.

When Should You Reseed a Broken ZFS Replication Chain? - Zima Store Online

Wykonaj ponowne zasianie, gdy nie możesz potwierdzić prawidłowej wspólnej bazy lub naprawa łańcucha wymagałaby niezweryfikowanego wycofania miejsca docelowego. Najpierw zachowaj ostatnią czytelną replikę.

W domowym serwerze NAS kuszącym skrótem jest wymuszenie kolejnego wysyłania przyrostowego, aż zadziała. Może to ukryć brakujący migawkę nadrzędną, rozbieżne miejsce docelowe albo punkt odbioru, który nie jest już zbiorem danych, za jaki go uważasz. Zacznij od zinwentaryzowania obu stron bez wprowadzania zmian, sprawdź, czy wspólna baza nadal istnieje, a gdy dowody nie potwierdzają bezpiecznej kontynuacji przyrostowej, użyj pełnego zasiania etapowego.

Potwierdź, że obie strony nadal współdzielą tę samą bazę

Rozpocznij od inwentaryzacji tylko do odczytu zbioru danych źródłowych, zbioru danych docelowych, migawek, zakładek oraz stanu wznawiania odbioru. Dopasuj coś więcej niż wygodną nazwę migawki: potwierdź, że kandydacka baza należy do właściwych zbiorów danych i reprezentuje tę samą historię replikacji. Zapisz wykazy przed rozpoczęciem czyszczenia, aby móc wyjaśnić wybór kolejnego działania.

Replikacja przyrostowa ZFS zależy od bazy obecnej już u odbiorcy. Praktyczna sekwencja replikacji migawek celowo zachowuje wspólną historię, zamiast zakładać, że identyczne etykiety potwierdzają ciągłość.

Jeśli zweryfikowana baza istnieje po obu stronach, przejdź do niedestrukcyjnego testu przyrostowego. Jeśli nazwa istnieje, ale tożsamość lub ścieżka zbioru danych się różni, uznaj łańcuch za niepotwierdzony. Jeśli nie pozostała żadna wspólna baza, nie usuwaj kolejnych migawek ani nie wymuszaj cofnięcia miejsca docelowego; decyzja przesunęła się już w stronę etapowego ponownego zasiania.

Przetestuj plan przyrostowy bez zmieniania repliki

Przygotuj proponowane wysyłanie, używając zweryfikowanej bazy i najnowszego celu, ale nie przekazuj go jeszcze do aktywnego miejsca docelowego. Użyj testu bez wykonywania zmian, szczegółowego szacowania lub trybu podglądu narzędzia replikacji. Przed odebraniem, które może zmodyfikować dane, potwierdź ścieżkę źródłową, ścieżkę docelową, migawkę bazową, migawkę docelową, flagi rekurencji oraz oczekiwany rozmiar strumienia.

Harmonogram, który zgłasza brak wspólnej migawki bazowej, odrzuca niebezpieczne przypuszczenie, a nie tylko prosi o ponowienie próby. Wielokrotne ponawianie nie odtworzy usuniętej wspólnej historii.

Strumień o rozmiarze odpowiadającym zmianom, utworzony z dokładnej bazy i celu, potwierdza możliwość naprawy łańcucha. Strumień zbliżony rozmiarem do pełnego zbioru danych, nieoczekiwany zbiór danych lub jakakolwiek konieczność wymuszonego wycofania oznaczają, że podgląd zakończył się niepowodzeniem. Zatrzymaj się w tym miejscu i zachowaj bieżącą replikę; zmienianie flag do momentu, aż polecenie zadziała, nie jest weryfikacją.

Wybierz naprawę tylko wtedy, gdy historia i stan miejsca docelowego są zgodne

Naprawiaj ścieżkę przyrostową tylko wtedy, gdy wspólna baza została zweryfikowana, miejsce docelowe nie stało się niezależną kopią roboczą, a podgląd proponuje oczekiwany przyrost. W oknie naprawy pozostaw miejsce docelowe tylko do odczytu. Jeśli narzędzie na to pozwala, najpierw wysyłaj dane do nowego podrzędnego zbioru danych lub miejsca docelowego w obszarze pomostowym, a następnie porównaj je przed przełączeniem.

Wykonaj ponowne zasianie, gdy nie istnieje prawidłowa baza, miejsce docelowe uległo rozbieżności, wymagane wycofanie usunęłoby migawki, których nadal potrzebujesz, lub czas poświęcony na potwierdzanie łańcucha przekracza kontrolowany koszt nowego pełnego transferu. Dyskusje na temat pochodzenia migawek przyrostowych potwierdzają, że nazwy pośrednie są mniej istotne niż zachowanie użytecznego wspólnego punktu.

Nie usuwaj starego miejsca docelowego, aby zwolnić przestrzeń, chyba że istnieje inna zweryfikowana kopia. Bezpieczniejsze ponowne zasianie zapisuje dane do oddzielnego zbioru danych lub puli, weryfikuje nową kopię, a dopiero potem wycofuje uszkodzony łańcuch. Jeśli nie ma wystarczającej pojemności na obie kopie, wstrzymaj działanie i uzyskaj tymczasową przestrzeń, zamiast zmieniać ostatnią czytelną replikę w obiekt eksperymentu.

Featured

ZimaCube 2 Osobisty domowy NAS w chmurze

ZimaCube2

Zweryfikuj nowy łańcuch w dwóch cyklach replikacji

Jedno udane pełne odebranie dowodzi tylko, że strumień dotarł. Utwórz mały plik testowy lub zmień właściwość na źródle, wykonaj kolejną zaplanowaną migawkę i uruchom drugi cykl przyrostowy, używając nowej wspólnej bazy. Po obu uruchomieniach porównaj właściwości zbiorów danych, listy migawek, próbkę plików oraz dziennik replikacji.

Jeśli zachowanie wznawiania było częścią pierwotnej awarii, rozdziel wcześniejszą ścieżkę awarii tokenu wznowienia od brakującego pochodzenia, aby ten sam objaw nie skierował Cię ponownie ku niewłaściwej naprawie.

Odzyskiwanie można uznać za zakończone pomyślnie, gdy nowe zasianie jest czytelne, drugi transfer przyrostowy ma rozmiar odpowiadający zmianom i kończy się powodzeniem, a oczekiwane migawki i pliki pojawiają się po ponownym uruchomieniu lub zaplanowanym przebiegu. Zachowaj poprzednią replikę do czasu pomyślnego przejścia tych kontroli. Eskaluj problem, jeśli tożsamości ponownie się zmienią, miejsce docelowe nie może pozostać tylko do odczytu lub narzędzie wielokrotnie wybiera nieoczekiwaną bazę.