Niezbędne kontrolki zdrowia bazy danych MongoDB

Utrzymanie zdrowej bazy danych MongoDB jest kluczowe dla stabilności aplikacji, optymalnej wydajności i integralności danych. „Zdrowy” klaster to taki, który niezawodnie obsługuje odczyty i zapisy, chroni dane przed utratą i działa w oczekiwanych granicach operacyjnych. Regularne kontrole i proaktywne monitorowanie są niezbędne, aby wykrywać i rozwiązywać potencjalne problemy, zanim wpłyną one na działanie usługi.

Zdrowie klastra MongoDB można podzielić na trzy podstawowe obszary:

• Replikacja
• Wydajność
• Kopia zapasowa 

Regularnie oceniając te obszary, zapewniają Państwo, że platforma danych jest solidna i niezawodna. Co więcej, nowoczesne narzędzia zarządzania, takie jak MongoDB Atlas i MongoDB Ops Manager, oferują zintegrowane monitorowanie z alertami i rekomendacjami, które pomagają wyprzedzać potencjalne problemy. Skonfigurowanie alertów ułatwi trzymanie ręki na pulsie. Instrukcje i przykłady można znaleźć w oficjalnej dokumentacji MongoDB na temat konfigurowania alertów.

Przyjrzyjmy się tym obszarom.

Status replikacji

Replikacja jest kręgosłupem wysokiej dostępności w MongoDB. Zdrowy zestaw replik zapewnia redundancję danych i możliwość przełączenia awaryjnego. Przyjrzyjmy się trzem kluczowym wskaźnikom, które pozwalają zapewnić skuteczną replikację między serwerami będącymi członkami zestawu replik.

Ogólny stan i szczegóły statusu replikacji 

Pełny status zestawu replik można uzyskać, uruchamiając polecenie rs.status() w powłoce MongoDB. To polecenie zapewnia kompleksowy widok bieżącego stanu zestawu replik. Należy sprawdzić wynik, aby potwierdzić, że wszyscy członkowie są zdrowi (tj. w stanie PRIMARY lub SECONDARY) i działają zgodnie z oczekiwaniami.

W interfejsie Atlas można również uzyskać podobne informacje jak te z powyższego polecenia. Na stronie „Clusters” proszę kliknąć nazwę konkretnego klastra. Ta akcja przekieruje do karty „Overview”, gdzie można zobaczyć przegląd węzłów. Jeśli coś jest poważnie nie tak, powinno to być tam widoczne. 

Czas replikacji

Trwałość danych w klastrze replikowanym zależy od replikacji danych na większości węzłów. Z tego powodu zdrowy klaster musi replikować szybko. Jeśli tak nie jest, operacje z poziomem zapisu majority będą miały wyższe opóźnienia.

Głównym wskaźnikiem tej cechy jest opóźnienie replikacji. Opóźnienie replikacji to zwłoka między operacją na węźle primary a jej późniejszym zastosowaniem na węźle secondary. Niskie, stabilne opóźnienie replikacji jest silnym wskaźnikiem zdrowia. Z kolei wolna replikacja może być oznaką źle skonfigurowanych połączeń między węzłami.

Najłatwiejszym sposobem obserwacji opóźnienia replikacji jest wykres „Replication Lag” na karcie „Cluster Metrics”. Oto przykład takiego wykresu dla zdrowego klastra. Proszę zauważyć, że ta metryka nie dotyczy węzła PRIMARY klastra — tego pośrodku, oznaczonego literą „P”.

Okno Oplog replikacji 

Replikacja jest realizowana za pomocą specjalnej kolekcji zwanej „oplog”. Oplog (dziennik operacji) to kolekcja o stałym rozmiarze (capped), która zapisuje wszystkie operacje modyfikujące dane. „Replication Oplog Window” oznacza przybliżony czas dostępny w oplogu replikacji dla źródła synchronizacji, zanim bieżące operacje zaczną być nadpisywane. Innymi słowy, okno Oplog replikacji to różnica czasu między najnowszym a najstarszym znacznikiem czasu w oplogu. Odpowiednio duża wartość okna jest krytyczna, aby węzły secondary mogły nadrobić zaległości po przestoju i uniknąć konieczności pełnej ponownej synchronizacji danych.

Jeśli węzeł secondary jest offline dłużej niż dostępne okno Oplog replikacji, konieczna będzie pełna ponowna synchronizacja od zera. Innymi słowy, wartość okna Oplog replikacji powinna być dłuższa niż maksymalny czas możliwej niedostępności repliki. Proszę pamiętać, że wartość okna jest wrażliwa na nagłe skoki operacji zapisu.

Aby uzyskać większe okno Oplog replikacji, należy zwiększyć rozmiar kolekcji oplog.

Status wydajności

Wydajność bezpośrednio wpływa na doświadczenie użytkownika aplikacji oraz koszty utrzymania klastra. Zdrowy klaster działa efektywnie względem swojego obciążenia.

Również tutaj proszę przyjrzeć się kluczowym aspektom wydajności, które warto monitorować.

Bieżące liczby operacji są zgodne z oczekiwaniami 

Najpierw warto sprawdzić, czy klaster otrzymuje oczekiwaną liczbę operacji. „Oczekiwaną”, zakładając, że znają Państwo tę wartość. Jeśli nie, analiza trendu zapytań z ostatniej godziny, dnia, tygodnia itp. może dać dobre rozeznanie, czego się spodziewać i czy występują jakieś piki lub anomalie. Regularny tygodniowy pik o określonej porze może wymagać wcześniejszego skalowania klastra w górę.

Proszę obserwować tempo operacji (odczyty, zapisy, polecenia). Nagłe, nieoczekiwane skoki lub spadki mogą wskazywać na problem, taki jak błąd aplikacji, wąskie gardło zasobów lub nieefektywny wzorzec zapytań. Aby w tym pomóc, warto ustawić alerty dotyczące liczby operacji, widocznej w sekcji „Opcounters” metryk klastra.

Dodatkowo informacje w czasie rzeczywistym o bieżącym tempie operacji można znaleźć na karcie „Real Time”.

Lepsze zrozumienie wolnych zapytań 

Zapytania, których wykonanie trwa wyjątkowo długo, nazywa się wolnymi zapytaniami. Często wskazują one na potrzebę indeksowania lub optymalizacji zapytań. Ponadto warto monitorować operacje wymagające sortowania w pamięci, ponieważ mogą one zużywać znaczące zasoby serwera i pogarszać wydajność.

Karta „Query Insights” pozwala przeglądać zapytania, filtrować je według kryteriów i wykonywać dodatkowe działania. Warto korzystać z tej strony, aby zidentyfikować, które zapytania należy zoptymalizować i które być może powinny działać na innym węźle lub w innym czasie.

Brakujące indeksy

Najczęstszą przyczyną wolnych zapytań w MongoDB jest brak odpowiednich indeksów. Gdy indeksu brakuje, MongoDB może wykonywać skan kolekcji (sprawdzać każdy dokument w kolekcji), ale jest to bardzo nieefektywna operacja, zwłaszcza w przypadku dużych kolekcji. Identyfikacja i tworzenie brakujących indeksów jest niezbędne dla utrzymania wydajności zapytań.

Karta „Performance Advisor” zawiera kilka cennych narzędzi pomagających w optymalizacji wydajności. Poniżej widać stronę „Create Indexes”.

Status kopii zapasowych

Replikacja jest cennym zabezpieczeniem przed utratą danych w przypadku utraty lub uszkodzenia zasobów, takich jak dysk serwera. Natomiast wbudowana wysoka dostępność klastra pokryje większość awarii sprzętowych. Jednak niezawodna strategia tworzenia kopii zapasowych pozostaje ostatecznym zabezpieczeniem przed utratą danych. Zdrowy klaster ma przetestowany, działający system tworzenia kopii zapasowych i odtwarzania.

Podobnie jak w innych sekcjach, przyjrzyjmy się kluczowym kwestiom dotyczącym strategii kopii zapasowych.

Zdefiniowanie celów odtworzeniowych 

Proszę zdefiniować Recovery Point Objective (RPO), czyli maksymalnie akceptowalną utratę danych, oraz Recovery Time Objective (RTO), czyli maksymalny dopuszczalny czas przywrócenia usługi. Te cele determinują wymaganą częstotliwość i metody wykonywania kopii zapasowych.

Podstawy kopii zapasowych

Istnieją różne narzędzia do tworzenia kopii zapasowych danych w MongoDB. Zaczyna się od prostego zrzutu danych przy użyciu mongodump. Następnie przechodzi się do korzystania z narzędzi zarządzających MongoDB w celu wykonywania migawkowych kopii (snapshots) i zachowywania pojedynczych operacji (oplog), aby odtworzyć obraz dowolnego punktu w czasie. MongoDB Atlas zawiera te narzędzia dla klastrów hostowanych, a MongoDB OpsManager pełni podobną funkcję dla klastrów lokalnych (on‑premises).

Przechowywanie wielu wersji danych jako kopii zapasowych zwykle zajmuje więcej miejsca niż sama oryginalna baza danych. Warto zrozumieć koszty, aby lepiej dopasować się do potrzeb. To ćwiczenie pozwoli przygotować harmonogram określający liczbę tworzonych migawek oraz ich częstotliwość.

Śledzenie, dostęp i odtwarzanie kopii zapasowych

Jeśli korzystają Państwo z MongoDB Atlas, proszę zweryfikować, czy zarządzany proces tworzenia kopii zapasowych działa pomyślnie, regularnie wykonuje migawki, a polityki retencji są zgodne z wymaganiami RPO.

Proszę wykonać odtworzenie: jedynym sposobem, aby rzeczywiście potwierdzić ważność kopii zapasowych, jest regularny test odtwarzania. Taka próba weryfikuje cały łańcuch tworzenia i odtwarzania kopii, zapewniając możliwość odzyskania danych w sytuacji awaryjnej.

Podsumowanie

Zdrowy klaster MongoDB charakteryzuje się:

• Optymalnym stanem replikacji
• Efektywną wydajnością
• Niezawodnymi kopiami zapasowymi

Proaktywne monitorowanie tych trzech obszarów, analiza wydajności zapytań oraz testy odtwarzania zapewnią stabilność i długowieczność wdrożenia MongoDB.