Systemy baz danych mają obowiązek przechowywać i zapewniać stałą dostępność odpowiednich danych zawsze, gdy są potrzebne w dowolnym momencie działania. Większość firm nie kontynuuje działalności po przypadkach utraty danych w wyniku awarii bazy danych, mostka bezpieczeństwa, błędu ludzkiego lub katastrofalnej awarii, która może całkowicie zniszczyć działające węzły produkcyjne. Przechowywanie baz danych w tym samym centrum danych wiąże się z wysokim ryzykiem utraty wszystkich danych w przypadku tych ataków.
Replikacja i tworzenie kopii zapasowych to powszechnie stosowane sposoby zapewnienia wysokiej dostępności danych. Wybór między nimi zależy od częstotliwości zmian danych. Kopia zapasowa jest najlepiej preferowana, gdy dane nie zmieniają się częściej i nie oczekuje się posiadania tak wielu plików kopii zapasowych. Z drugiej strony replikacja jest preferowana w przypadku często zmieniających się danych, poza pewnymi innymi zaletami związanymi z obsługą danych w określonej lokalizacji poprzez zmniejszenie opóźnień żądań. Jednak zarówno replikacja, jak i kopia zapasowa mogą być używane w celu uzyskania maksymalnej integralności i spójności danych podczas przywracania w przypadku awarii.
Kopie zapasowe baz danych zapewniają więcej korzyści, poza zapewnieniem punktu przywracania podstaw do tworzenia nowych środowisk na potrzeby programowania, otwartego dostępu i przemieszczania bez ograniczania produkcji. Zespół programistów może szybko i łatwo testować nowo zintegrowane funkcje i przyspieszyć ich rozwój. Kopie zapasowe mogą być również używane w punkcie kontrolnym błędów kodu, gdy dane wynikowe nie są spójne.
Rozważania dotyczące tworzenia kopii zapasowej MongoDB
Kopie zapasowe są tworzone w określonych punktach, aby odzwierciedlić (działając jako migawka bazy danych), jakie dane baza danych przechowuje w danym momencie. Jeśli baza danych ulegnie awarii w danym punkcie, możemy użyć ostatniego pliku kopii zapasowej, aby przywrócić bazę danych do punktu, w którym nastąpiła awaria. Jednak przed wyzdrowieniem należy wziąć pod uwagę kilka czynników, które obejmują:
- Cel punktu odzyskiwania
- Cel czasu odzyskiwania
- Izolacja bazy danych i migawek
- Komplikacje przy shardingu
- Proces przywracania
- Czynniki wydajności i dostępna pamięć
- Elastyczność
- Złożoność wdrożenia
Cel punktu odzyskiwania
Jest to wykonywane w celu określenia, ile danych jesteś gotowy do utraty podczas procesu tworzenia kopii zapasowej i przywracania. Na przykład, jeśli mamy dane użytkownika i dane dotyczące strumienia kliknięć, dane użytkownika będą miały pierwszeństwo przed analizą strumienia kliknięć, ponieważ te ostatnie można odtworzyć, monitorując operacje w aplikacji po przywróceniu. Ciągła kopia zapasowa powinna być preferowana w przypadku krytycznych danych, takich jak informacje bankowe, dane z branży produkcyjnej i informacje o systemach komunikacyjnych, i powinna być wykonywana w krótkich odstępach czasu. Jeśli dane nie zmieniają się często, ich utrata może być mniej kosztowna, jeśli wykonasz przywróconą migawkę, na przykład 6 miesięcy lub 1 rok wcześniej.
Cel czasu odzyskiwania
Ma to na celu analizę i określenie, jak szybko można wykonać operację przywracania. Podczas odzyskiwania aplikacje będą miały pewien czas przestoju, który jest również wprost proporcjonalny do ilości danych, które muszą zostać odzyskane. Jeśli przywracasz duży zestaw danych, zajmie to więcej czasu.
Izolacja bazy danych i migawek
Izolacja jest miarą odległości migawek kopii zapasowych od głównych serwerów baz danych pod względem konfiguracji logicznej i fizycznej. Jeśli zdarzy się, że są one wystarczająco blisko, czas odtwarzania skraca się kosztem zwiększonego prawdopodobieństwa zniszczenia w tym samym czasie, gdy niszczona jest baza danych. Nie zaleca się hostowania kopii zapasowych i środowiska produkcyjnego w tym samym systemie, aby uniknąć zakłóceń na serwerach również w przypadku tworzenia kopii zapasowych.
Komplikacje przy shardingu
W przypadku rozproszonego systemu baz danych poprzez sharding występuje pewna złożoność tworzenia kopii zapasowych i może być konieczne wstrzymanie czynności zapisu w całym systemie. Różne fragmenty kończą różne typy kopii zapasowych w różnym czasie. Biorąc pod uwagę kopie logiczne i kopie migawkowe,
Logiczne kopie zapasowe
- Odłamki mają różne rozmiary, dlatego kończą się w różnym czasie
- Zrzuty bazowe MongoDB zignorują --oplog, dlatego nie będą spójne dla każdego fragmentu.
- Balans może być wyłączony, gdy powinien być włączony tylko dlatego, że niektóre fragmenty mogą nie zakończyły procesu przywracania
Kopie zapasowe migawek
- Działa dobrze dla pojedynczej repliki z wersji 3.2 i nowszych. Dlatego powinieneś rozważyć aktualizację swojej wersji MongoDB.
Proces przywracania
Niektórzy ludzie wykonują kopie zapasowe bez testowania, czy będą działać w przypadku przywrócenia. Zasadniczo kopia zapasowa ma zapewnić możliwość przywracania, w przeciwnym razie stanie się bezużyteczna. Zawsze powinieneś próbować uruchamiać kopie zapasowe na różnych serwerach testowych, aby sprawdzić, czy działają.
Czynniki wydajności i dostępna pamięć
Kopie zapasowe mają również tendencję do przybierania wielu rozmiarów, ponieważ dane z samej bazy danych i muszą być wystarczająco skompresowane, aby nie zajmować dużo niepotrzebnego miejsca, które może zmniejszyć ogólne zasoby pamięci masowej systemu. Można je archiwizować w plikach zip, zmniejszając w ten sposób ich ogólne rozmiary. Poza tym, jak wspomniano wcześniej, kopie zapasowe można archiwizować w różnych centrach danych z samej bazy danych.
Kopie zapasowe mogą decydować o różnych wydajnościach bazy danych, przez co niektóre mogą ją pogorszyć. W takim przypadku ciągłe tworzenie kopii zapasowych spowoduje pewne niepowodzenie, dlatego należy je przekonwertować na zaplanowane kopie zapasowe, aby uniknąć wyczerpywania się okien obsługi. W większości przypadków do obsługi kopii zapasowych wdrażane są serwery pomocnicze. W takim przypadku:
- Nie można konsekwentnie tworzyć kopii zapasowych pojedynczych węzłów, ponieważ MongoDB używa polecenia read-uncommitted bez oploga podczas korzystania z polecenia mongodump iw takim przypadku kopie zapasowe nie będą bezpieczne.
- Użyj węzłów drugorzędnych do tworzenia kopii zapasowych, ponieważ sam proces wymaga czasu w zależności od ilości danych, a połączone aplikacje będą wymagały pewnego przestoju. Jeśli używasz podstawowego, który musi również aktualizować Oplogs, możesz stracić niektóre dane podczas tego przestoju
- Proces przywracania zajmuje dużo czasu, ale przydzielone zasoby pamięci są niewielkie.
Elastyczność
W wielu przypadkach możesz nie chcieć niektórych danych podczas tworzenia kopii zapasowej, jak na przykład w przypadku celu punktu przywracania, można chcieć wykonać odzyskiwanie i odfiltrować dane o kliknięciach użytkownika. Aby to zrobić, potrzebujesz strategii częściowego tworzenia kopii zapasowych, która zapewni elastyczność w zakresie filtrowania danych, którymi nie będziesz zainteresowany, a tym samym skróci czas odzyskiwania i zasoby, które zostałyby zmarnowane. Przyrostowa kopia zapasowa może być również przydatna, ponieważ tylko zmienione części danych zostaną zarchiwizowane z ostatniego zrzutu, zamiast tworzenia całych kopii zapasowych dla każdego zrzutu.
Złożoność wdrożenia
Twoja strategia tworzenia kopii zapasowych powinna być łatwa do ustalenia i utrzymania w miarę upływu czasu. Możesz także zaplanować tworzenie kopii zapasowych, aby nie trzeba było ich robić ręcznie, kiedy tylko chcesz.
Wnioski
Systemy baz danych gwarantują „życie po śmierci”, jeśli tylko istnieje dobrze ugruntowany system tworzenia kopii zapasowych. Baza danych może zostać zniszczona przez czynniki katastroficzne, błąd ludzki lub ataki na bezpieczeństwo, które mogą prowadzić do utraty lub uszkodzenia danych. Przed wykonaniem kopii zapasowej należy rozważyć rodzaj danych pod względem rozmiaru i ważności. Nie zaleca się przechowywania kopii zapasowych w tym samym centrum danych, co baza danych, aby zmniejszyć prawdopodobieństwo jednoczesnego zniszczenia kopii zapasowych. Kopie zapasowe mogą zmienić wydajność bazy danych, dlatego należy uważać na strategię i czas wykonywania kopii zapasowej. Nie twórz kopii zapasowych na węźle podstawowym, ponieważ może to spowodować przestój systemu podczas tworzenia kopii zapasowej, a w konsekwencji utratę ważnych danych.
