Zrozumienie zaległości replikacji w Redis: PSYNC, rozmiar i ograniczenia dotyczące wysokiej dostępności

Der Zaległości replikacji Redis ma wpływ na to, czy po zerwaniu połączenia replika pobierze jedynie brakujące zmiany, czy też otrzyma do ponownego przesłania cały zbiór danych. Dostosowując rozmiar bufora do rzeczywistej objętości replikacji, można uniknąć niepotrzebnych pełnych synchronizacji. Wymaga to jednak odpowiedniego dopasowania historii replikacji, budżetu pamięci i procesów operacyjnych: duży zaległy zestaw danych nie zastąpi ani trwałości danych, ani solidnej koncepcji przełączania awaryjnego.

Co faktycznie przechowuje lista zadań do wykonania

Na stronie Replikacja Redis Serwer główny przetwarza zmiany w zbiorze danych i przesyła ciągły strumień poleceń do swoich replik. Obejmuje to nie tylko wartości zapisywane bezpośrednio przez klientów. Również wygasłe lub zastąpione klucze mogą wywoływać zmiany, które muszą zostać przekazane dalej. Backlog przechowuje w pamięci roboczej ograniczony, najnowszy fragment tego strumienia replikacji. Nie zawiera zatem dodatkowej pełnej kopii bazy danych i nie jest też archiwum operacji zapisu o dowolnym wieku.

W przypadku bezproblemowej pracy repliki śledzą bieżący strumień danych. Jeśli połączenie zostanie przerwane, historia na serwerze głównym nadal się wydłuża. Po ponownym nawiązaniu połączenia replika próbuje kontynuować od miejsca, w którym została przerwana. Decydujące znaczenie ma wówczas to, czy wymagane bajty są nadal przechowywane. Jeśli tak jest i historia replikacji jest zgodna, Redis może uzupełnić brakujące dane. Nie ma przy tym konieczności całkowitego zastępowania danych już istniejących na replice.

Korzyści są szczególnie widoczne w przypadku krótkich zakłóceń sieciowych, zmian połączeń oraz planowanych prac konserwacyjnych. Pełna synchronizacja dużego zbioru danych wymaga przepustowości i mocy obliczeniowej; w zależności od konfiguracji dochodzi do tego dodatkowe obciążenie pamięci i nośników danych. Backlog może zmniejszyć ten nakład, ale nie jest w stanie zrekompensować każdego rodzaju przerwy. Ponowne uruchomienie procesu lub zmiana historii wymaga innego podejścia niż krótkotrwała przerwa w połączeniu TCP.

Kiedy wystarczy PSYNC, a kiedy konieczna jest pełna resynchronizacja

A częściowa resynchronizacja za pomocą PSYNC wymaga podania dwóch powiązanych ze sobą danych: identyfikatora replikacji oraz przesunięcia. Identyfikator określa konkretną historię danych. Przesunięcie opisuje pozycję bajtu w strumieniu replikacji. Dwa przesunięcia o tej samej wielkości, pochodzące z różnych historii, nie są zatem automatycznie porównywalne. Z drugiej strony niewielkie opóźnienie w tej samej historii może już znajdować się poza dostępnym zaległością, jeśli jej pojemność jest ograniczona.

W uproszczeniu: po ponownym połączeniu serwer Replica zgłasza, do jakiego etapu dotarł. Serwer Primary sprawdza, czy jest w stanie dostarczyć dane potrzebne w dalszej części procesu. Jeśli historia jest nieznana lub brakuje niezbędnego fragmentu, następuje Pełna resynchronizacja konieczne. W tym procesie replika otrzymuje pełny zbiór danych, a następnie zmiany, które powstały podczas synchronizacji. W zależności od konfiguracji transfer może odbywać się z pośrednim etapem RDB na nośniku danych lub bez tego etapu.

Po przełączeniu awaryjnym pełna resynchronizacja nie zawsze jest nieunikniona. Przeniesiona replika może dodatkowo zapamiętać poprzedni identyfikator replikacji oraz jego ważny zakres przesunięcia. Dzięki temu kolejne repliki mogą, pod odpowiednimi warunkami, podłączyć się do znanej historii. Nie daje to jednak żadnej gwarancji przy planowaniu: odpowiedni zakres musi nadal być dostępny, a konkretne ponowne podłączenie musi odpowiadać zapisanym identyfikatorom.

Pomiar wskaźnika replikacji zamiast szacowania rozmiaru bazy danych

Już sama wielkość zbioru danych wystarcza do Wymiarowanie zaległości nie wystarczy. Duża baza danych, z której głównie się korzysta, może generować niewielki ruch replikacyjny. Natomiast mała pamięć podręczna z często zmieniającymi się wartościami i dużą liczbą zdarzeń wygaśnięcia może na bieżąco przesyłać znaczne ilości danych. Nawet stała liczba operacji na sekundę nie opisuje w wystarczającym stopniu wymaganej pamięci: niewielkie zmiany kluczy i duże nadpisywanie wartości nie powodują takiego samego zużycia bajtów.

Praktyczne przybliżenie wynika ze wzrostu w czasie wartości master_repl_offset. Zarejestruj wartość dwukrotnie na tym samym serwerze głównym i podziel różnicę przez liczbę upływających sekund. Sprawdź przy tym również identyfikator replikacji. Po zmianie roli lub ponownym uruchomieniu nie wolno po prostu odejmować od siebie dwóch niepowiązanych punktów pomiarowych. Pojedynczy przedział pomiarowy dostarcza ponadto jedynie średnią częstotliwość w ramach tego przedziału, a nie trwale gwarantowaną górną granicę.

Poniższe zapytanie odczytuje informacje diagnostyczne. Nie zmienia ono konfiguracji Redis. Należy je wykonać z opcjami połączenia i uwierzytelniania wymaganymi w danym środowisku. Poniższe wywołanie wykorzystuje domyślne połączenie z redis-cli; należy wyraźnie ustawić inny serwer, port lub dostęp TLS.

redis-cli INFO replication

Zmierz obciążenie w różnych fazach, np. podczas normalnej codziennej działalności, przy importach oraz w trakcie większych odświeżeń pamięci podręcznej. Udokumentuj zarówno typowe wartości, jak i krótkotrwałe szczyty. Jeśli występuje wiele zmian spowodowanych wygasającymi kluczami, pomocne w pogłębieniu tematu będzie wewnętrzny artykuł Analiza wygasania kluczy w Redis. Związek ten ma znaczenie dla planowania, ponieważ nie każda istotna potrzeba zapisania danych wynika bezpośrednio z nowego zapytania użytkownika.

Jak w sposób przejrzysty obliczyć wielkość zaległości

Jak Przybliżone założenia projektowe możesz pomnożyć odpowiednią częstotliwość replikacji przez czas trwania przerwy, którą należy zrekompensować, a następnie dodać uzasadniony zapas. Czas ten powinien uwzględniać nie tylko samą przerwę w działaniu sieci. Również wykrycie awarii, próby ponownego nawiązania połączenia oraz przywrócenie ścieżki połączenia mogą wymagać czasu. To, jaka rezerwa jest odpowiednia, zależy od zaobserwowanych wahań oraz pożądanego celu operacyjnego, a nie od uniwersalnej wartości procentowej.

Celowo uproszczony przykład obliczeniowy: dla rozpatrywanej fazy obciążenia przyjmujesz 12 MiB na sekundę. Połączenie może być niedostępne przez 90 sekund; dodatkowo przewiduje się 30 sekund rezerwy czasowej. Wynika z tego, że 12 MiB/s × 120 s = 1.440 MiB, czyli około 1,41 GiB. Liczby te są jedynie przybliżeniami służącymi wyjaśnieniu i nie stanowią testu wydajnościowego Redis. Przed wdrożeniem do środowiska produkcyjnego należy je zastąpić wartościami pomiarowymi z Twojej aplikacji.

Obliczenia odwrotne pomagają w ocenie dostępnego bufora. Całkowicie zapełniony backlog o wielkości 256 MiB odpowiada teoretycznie około 21 sekundom historii przy stałej wartości 12 MiB na sekundę. Przy 2 MiB na sekundę byłoby to około 128 sekund. W rzeczywistym zastosowaniu szybkości te ulegają jednak zmianom. Taki zasięg stanowi zatem jedynie migawkę sytuacji i nie jest gwarancją, że każda awaria trwająca tyle czasu może zostać częściowo zsynchronizowana.

Sprawdź również, czy po ponownym połączeniu replika nadąża szybciej niż pojawiają się nowe zmiany. Zwiększenie historii nie eliminuje ani trwale zbyt wolnej sieci, ani trwale przeciążonego odbiorcy. Jeśli opóźnienie utrzymuje się lub nadal rośnie, należy zbadać jego przyczynę. W przeciwnym razie planowanie coraz większej ilości pamięci jedynie odkłada problem na później i może obciążyć cały system pod względem pamięci.

Jak w zrozumiały i kontrolowany sposób zmieniać konfigurację Redis

Parametry repl-backlog-size oraz repl-backlog-ttl kontrolują różne rzeczy. Pierwszy określa przewidywaną wielkość zaległości. Drugi określa na serwerze głównym, po upływie jakiego czasu bez połączonych replik zaległości mogą zostać zwolnione. Jest to brak maksymalnego czasu przerwy dla PSYNC. Dopóki bufor jest nadpisywany lub nie jest spełniony inny warunek, sam długi czas TTL nie wystarczy.

Poniższe wiersze pochodzą z szablonu konfiguracyjnego Redis 7.2.0 jako skomentowane ustawienia domyślne. Znaki komentarza zostały celowo zachowane. Samo skopiowanie tych wierszy nie powoduje aktywacji żadnych ustawień; ponadto podane wartości nie stanowią ogólnych zaleceń dotyczących wydajności dla systemów produkcyjnych.

# Redis 7.2.0: auskommentierte Vorgaben aus redis.conf
# repl-backlog-size 1mb
# repl-backlog-ttl 3600

Z repl-backlog-ttl 0 Po odłączeniu wszystkich replik funkcja zwolnienia pamięci sterowana czasowo zostanie wyłączona. Nie zapewnia to przechowywania historii przez nieograniczony czas: istniejący bufor może nadal zostać nadpisany nowymi danymi replikacji. Nie zapewnia to również trwałości danych po dowolnych ponownych uruchomieniach procesu. Należy zatem rozważyć, czy dodatkowe zużycie pamięci jest adekwatne do oczekiwanego zachowania podczas ponownego łączenia.

Przed wprowadzeniem zmiany należy sprawdzić faktycznie obowiązujące wartości i wyjaśnić procedurę wdrażania. Zmienna środowiskowa kontenera, zarządzany plik konfiguracyjny oraz ustawienie zmienione w czasie wykonywania to nie to samo. Jeśli instancja zostanie później utworzona od nowa, utracone mogą zostać wyłącznie dostosowania dokonane w czasie wykonywania. Poniższe zapytania mają charakter odczytu; mimo to wymagają odpowiednich uprawnień dostępu.

redis-cli CONFIG GET repl-backlog-size
redis-cli CONFIG GET repl-backlog-ttl

W przypadku usługi Managed Redis dostawca może ograniczyć dostęp do CONFIG ograniczać lub zarządzać ustawieniami za pomocą własnego interfejsu. Nie jest to jednak powód do omijania mechanizmów zabezpieczających. W takim przypadku należy korzystać z zatwierdzonych kanałów administracyjnych i udokumentować wybrany rozmiar wraz z odpowiadającym mu wolumenem replikacji. W planie zmian należy ponadto uwzględnić dotychczasowe wartości oraz realistyczny plan powrotu do poprzedniego stanu.

Monitorowanie: które wartości są ze sobą powiązane

W przypadku Monitorowanie replikacji Redis Sam zielony status połączenia to za mało. Połączenie może zostać przywrócone, podczas gdy replika wciąż nadrabia zaległości lub właśnie ładuje pełny zestaw danych. Z drugiej strony krótka przerwa w połączeniu nie musi od razu stanowić poważnego problemu, jeśli historia i zdolność nadrabiania zaległości są wystarczające. Dlatego należy wspólnie oceniać połączenie, stan synchronizacji, zmiany przesunięcia oraz dostępną historię.

Pola w INFO-Odpowiedzi mogą się różnić w zależności od wersji Redis oraz od tego, czy chodzi o serwer główny, czy replikę. Dlatego też analiza danych powinna wyraźnie uwzględniać brakujące pola, zamiast domyślnie interpretować je jako wartości zerowe lub stan bezbłędny. Również nazwy master oraz slave ze względu na kompatybilność nadal występują w nazwach pól; nie wolno ich dowolnie tłumaczyć w kodzie wykonywalnym.

Do interpretacji zaległości należy odwołać się do wewnętrznych wytycznych Analiza przesunięcia replikacji w Redis odpowiednie uzupełnienie. W ramach bieżącego monitoringu należy brać pod uwagę historyczne trendy, a nie tylko dwie wartości odczytane ręcznie. Rosnąca różnica wymaga innej reakcji niż ta, która ma miejsce w przypadku stopniowo zmniejszającej się luki po krótkiej przerwie.

Sensowne alerty powinny być dostosowane do celów operacyjnych: jak długo replika może pozostawać niedostępna? Jak szybko musi nadrobić zaległości? Jaka częstotliwość pełnych synchronizacji jest nietypowa? Sztywne wartości progowe bez uwzględnienia profilu obciążenia i ilości danych często prowadzą do niepotrzebnych powiadomień lub pomijania rzeczywistych pogorszeń wydajności. Oprócz wskaźników replikacji należy również monitorować wykorzystanie pamięci RAM, obciążenie sieci oraz sygnały wskazujące na ponowne uruchomienie procesów.

Właściwa ocena budżetu pamięci i powolnych replik

Portfel zamówień to tylko część całości Wymagania dotyczące pamięci w Redis. Do tego dochodzą zasoby danych, struktury administracyjne, bufory klientów oraz – w zależności od stanu pracy – dodatkowa pamięć podczas operacji utrwalania lub synchronizacji. Dlatego nie należy planować wykorzystania całej dostępnej pamięci operacyjnej na dane użytkowe oraz dokładnie obliczone zaległości. Niezbędną rezerwę należy określić na podstawie konkretnego środowiska i występujących w nim szczytów obciążenia.

Od wersji Redis 7.0 bufor replikacji i kolejka replikacji współdzielą pamięć. W dokumentacji INFO zaznaczono zatem między innymi, że mem_clients_slaves może wynosić zero, jeśli bufory replikacji nie przekraczają zajętości backlogu. Nie oznacza to jednak, że replikacja nie zajmuje pamięci. Należy traktować wartości przeznaczone do tego celu jako mem_replication_backlog oraz mem_total_replication_buffers w kontekście i nie sumuj na ślepo nakładających się wielkości.

Częstym błędem diagnostycznym jest traktowanie każdego przerwanej synchronizacji jako wyniku znacznego zaległości. Powolne repliki, ograniczona przepustowość sieci lub przekroczenie limitów bufora wyjściowego mogą mieć inne przyczyny. Parametr client-output-buffer-limit replica dotyczy danej klasy klienta i nie może być mylona z repl-backlog-size należy traktować jako równoważne. Przed zmianą limitów sprawdź logi, dokumentację wersji oraz przewidywany wpływ na inne połączenia.

Dlaczego duża liczba zleceń w zaległościach nie gwarantuje jeszcze wysokiej dostępności

Bufor poprawia ponowne nawiązanie połączenia, ale nie sprawia, że domyślnie asynchroniczna replikacja staje się bezstratna. Serwer główny może potwierdzić operację zapisu klientowi, zanim replika ją przetworzy. Jeśli w tym czasie serwer główny ulegnie awarii, dana operacja może nie być dostępna na wybranym później systemie zastępczym. Sam rozmiar bufora nie eliminuje tego problemu Ryzyko utraty danych podczas przełączania awaryjnego nie.

Również WAIT nie przekształca topologii Redis w system o gwarantowanej silnej spójności. Polecenie to może oczekiwać potwierdzeń od replik; faktyczne bezpieczeństwo danych nadal zależy od innych czynników, w szczególności od zachowania w zakresie trwałości danych i przełączania awaryjnego. Podobnie ograniczają min-replicas-to-write oraz min-replicas-max-lag przyjmowanie nowych operacji zapisu na swoich warunkach, bez automatycznego, trwałego zapisywania każdej pojedynczej operacji na wielu instancjach.

Dla Wysoka dostępność W związku z tym potrzebna jest spójna strategia obejmująca: dopuszczalny poziom utraty danych, dopuszczalny czas przestoju, trwałość danych, wykrywanie awarii, wybór nowego serwera głównego oraz przywracanie danych. Sentinel lub Redis Cluster mogą w tym kontekście przejąć inne zadania niż backlog. Kto jedynie zwiększa rozmiar bufora, pozostawiając wszystkie pozostałe założenia bez zmian, nie ma jeszcze solidnego planu przywrócenia działania.

Testowanie zmian i zawężanie zakresu powtarzających się problemów

Rozpocznij kontrolowany test w izolowanym środowisku z podobną wersją Redis i przewidywalnym obciążeniem zapisem. Przed przerwaniem zapisz identyfikatory replikacji, przesunięcia, stan zaległości oraz zużycie pamięci. Następnie zasymuluj ograniczoną przerwę w połączeniu, nie wprowadzając żadnych niezweryfikowanych zmian w produkcyjnych zaporach sieciowych ani procesach. Po przywróceniu połączenia sprawdź, czy następuje częściowa czy całkowita synchronizacja oraz ile czasu zajmuje nadrobienie zaległości.

W każdym teście zmieniaj w miarę możliwości tylko jedną istotną zmienną. Jeśli jednocześnie zmieniają się zaległości, obciążenie zapisu i warunki sieciowe, trudno jest przypisać konkretny efekt do danej zmiany. Powtórz test z różnym czasem trwania przerwy i różnymi fazami obciążenia. W ten sposób pojedyncze udane ponowne połączenie pozwoli na uzyskanie zrozumiałej oceny zachowania systemu. Zaobserwowane ograniczenia należy udokumentować, nie wywodząc z nich jednak gwarancji na każdą przyszłą awarię.

W przypadku powtarzających się pełnych resynchronizacji należy najpierw sprawdzić, czy historia danych jest w ogóle zgodna. Następnie należy zwrócić uwagę na pozostałe bajty, czas bez repliki, informacje o ponownych uruchomieniach oraz rzeczywistą prędkość nadrabiania zaległości. Zbyt mały bufor jest jedną z możliwych przyczyn, ale nie jedyną. Szczególnie ważne jest rozróżnienie między jednorazową, zbyt długą luką a repliką, która stale pozostaje w tyle nawet przy istniejącym połączeniu.

Ostatecznie właściwe ustawienie to takie, które pokrywa zdefiniowany przez Ciebie przedział awarii przy realistycznym obciążeniu i pozostawia wystarczającą ilość pamięci na pozostałą część pracy. Należy wspólnie odnotować podstawę pomiarową, źródło konfiguracji oraz datę weryfikacji. Po wprowadzeniu większych zmian w zachowaniu zapisu, topologii lub wersji Redis należy ponownie zweryfikować wymiarowanie. Dzięki temu zaległości pozostają uzasadnioną decyzją operacyjną, a nie tylko raz przyjętą wartością.