Kopia zapasowa bazy danych jest kluczowym elementem zarządzania bazą danych i musi być starannie zaplanowana. Zaplanowanie kopii zapasowej nie wystarczy, dane kopii zapasowej należy również zweryfikować pod kątem spójności i integralności. Istnieją inne kwestie, takie jak szyfrowanie i archiwizacja poza siedzibą. Dobry menedżer kopii zapasowych miałby funkcje, które uwzględniają wszystkie te różne względy.
W tym poście na blogu przyjrzymy się, jak zaplanować tworzenie kopii zapasowych bazy danych za pomocą ClusterControl.
Kopie zapasowe bazy danych za pomocą ClusterControl
ClusterControl obsługuje wiele metod tworzenia kopii zapasowych w zależności od typu klastra, co podsumowano w poniższej tabeli:
| Typ klastra | Obsługiwana metoda tworzenia kopii zapasowej |
|---|---|
| MySQL (replikacja, Galera, klaster NDB, replikacja grupowa) |
|
| MongoDB (zestaw replik, klaster dzielony) |
|
| PostgreSQL (replikacja strumieniowa) |
|
Podczas planowania tworzenia kopii zapasowej za pomocą ClusterControl, każda z metod tworzenia kopii zapasowych jest konfigurowalna z zestawem opcji dotyczących sposobu wykonywania kopii zapasowej. Różne obciążenia bazy danych i strategie tworzenia kopii zapasowych wymagają obsługi różnych funkcji, na przykład:
- Ograniczanie IOPS dysku
- Ograniczanie przepustowości sieci
- Blokady kopii zapasowych
- Szyfrowanie
- Kompresja
- Okres przechowywania
- Weryfikacja
ClusterControl automatycznie ustawi szereg opcji tworzenia kopii zapasowych, zgodnie z najlepszymi praktykami danego dostawcy bazy danych. Na przykład, jeśli docelowy węzeł bazy danych ma włączony dziennik binarny, dołączy dodatkową flagę, --master-data aby uwzględnić współrzędne dziennika binarnego (nazwę pliku i pozycję) zrzuconego serwera. Jeśli jest to węzeł Galera, a metodą kopii zapasowej jest xtrabackup, ClusterControl dołączy dodatkową flagę --galera-info który zawiera stan węzła lokalnego w momencie tworzenia kopii zapasowej.
Planowanie kopii zapasowej
Zanim zaplanujemy jakąkolwiek kopię zapasową, musimy zaplanować, jak powinna wyglądać operacja tworzenia kopii zapasowej. Przed utworzeniem harmonogramu tworzenia kopii zapasowych pomocne byłyby odpowiedzi na następujące przykładowe pytania:
- Jakiej metody tworzenia kopii zapasowej chcesz użyć? Niektóre metody tworzenia kopii zapasowych są nieblokujące, ale bardzo intensywnie wykorzystują zasoby. Zrozum kompromisy, aby nie być zaskoczonym, jak zachowuje się proces w produkcji.
- Jak często chcesz tworzyć kopie zapasowe baz danych? Wykonanie pełnej kopii zapasowej może być bolesne, jeśli interwał tworzenia kopii zapasowej jest zbyt krótki. Prawdopodobnie potrzebujesz kombinacji pełnych i przyrostowych kopii zapasowych.
- Jak szybko chcesz przywrócić swoje dane? Fizyczna kopia zapasowa jest zwykle o wiele szybsza niż logiczna kopia zapasowa pod względem pełnego czasu przywracania. Z drugiej strony, logiczna kopia zapasowa jest zwykle szybsza w przypadku częściowego przywracania.
- Jak duży jest twój rozmiar danych? W niektórych przypadkach logiczna kopia zapasowa nie jest dobrym wyborem dla dużych baz danych, a kopia binarna to jedyna droga.
- Ile wolnego miejsca potrzebujesz na przechowywanie kopii zapasowej? Kopie zapasowe zajmują dużo miejsca. Zdecyduj, czy kompresja jest potrzebna i na jaki poziom kompresji możesz sobie pozwolić. Lepsza kompresja wymaga większego użycia procesora.
- Co się stanie, jeśli serwer kopii zapasowych nie będzie działał w czasie tworzenia kopii zapasowej? Czy należy przełączyć kopię zapasową awaryjnie na inny dostępny host? Pomijanie kopii zapasowej z powodu przerwy konserwacyjnej zwykle nie jest dobrym pomysłem.
- Jak zapewnić integralność tworzonej kopii zapasowej? Pamiętaj, że kopia zapasowa nie jest kopią zapasową, jeśli nie można jej przywrócić.
- Czy ufasz magazynowi kopii zapasowych? Szyfrowanie może być dobrym pomysłem do ochrony danych.
Generalnie, odpowiadając na te pytania, możemy wymyślić odpowiednią strategię tworzenia kopii zapasowych. Lista pytań może być dłuższa w zależności od zasad tworzenia kopii zapasowych i przywracania.
Szczegółowo omówiliśmy ten rozdział w naszym oficjalnym dokumencie, Przewodnik DevOps dotyczący tworzenia kopii zapasowych baz danych dla MySQL i MariaDB.
Planowanie kopii zapasowej
Dzięki ClusterControl planowanie jest całkiem proste. Przejdź bezpośrednio do Kopia zapasowa -> Utwórz kopię zapasową -> Zaplanuj tworzenie kopii zapasowej, a zostanie wyświetlone następujące okno dialogowe:
W zależności od typu klastra opcje mogą się różnić, jak pokazano na poniższych zrzutach ekranu dla PostgreSQL i MongoDB:
PostgreSQL 
MongoDB Większość opcji nie wymaga wyjaśnień i zostały szczegółowo omówione w Podręczniku użytkownika. Po utworzeniu harmonogramu możesz edytować kopie zapasowe konfiguracji, włączyć/wyłączyć kopię zapasową lub usunąć harmonogram w zakładce „Zaplanowane kopie zapasowe”:
Zwróć uwagę podczas planowania kopii zapasowej za pomocą ClusterControl, że cały czas musi być zaplanowany w strefie czasowej UTC serwera ClusterControl. Powodem tego jest odcięcie zamieszania związanego z czasem wykonywania kopii zapasowej. Podczas pracy z klastrem serwery baz danych mogą być rozmieszczone w różnych strefach czasowych i różnych obszarach geograficznych. Korzystanie z jednej referencyjnej strefy czasowej do zarządzania nimi wszystkimi zapewni, że kopie zapasowe będą zawsze wykonywane we właściwym czasie.
Możesz monitorować postęp tworzenia kopii zapasowej, patrząc na Aktywność -> Zadania, gdy nadejdzie czas. Jeśli zadanie kopii zapasowej nie powiodło się, od razu zobaczysz błąd:
Powyższy dziennik jest również dostępny w zakładce Kopia zapasowa w każdym wpisie kopii zapasowej:
Kontrole i weryfikacja po utworzeniu kopii zapasowej
Zakończenie zadania tworzenia kopii zapasowej nie oznacza, że Twoja odpowiedzialność się skończyła. Jest kilka rzeczy, którymi należy się zająć. Najważniejszym z nich jest stan tworzonej kopii zapasowej. ClusterControl zapewnia powiadomienia e-mail i powiadomi Cię o statusie. Ta usługa powiadomień jest oczywiście konfigurowalna na podstawie wagi w Ustawieniach -> Ustawienia ogólne -> Ustawienia powiadomień e-mail -> Kopia zapasowa:
Dostarcz oznacza, że ClusterControl wyśle powiadomienie e-mailem natychmiast po zgłoszeniu alarmu dla tego komponentu. Możesz również skonfigurować go jako Ignoruj lub Digest, gdzie ClusterControl wysyła codzienne podsumowanie zgłoszonych alarmów.
Jeśli kopia zapasowa zostanie pomyślnie utworzona, zdecydowanie zaleca się sprawdzenie, czy można ją przywrócić. Możesz użyć funkcji weryfikacji kopii zapasowej, klikając przycisk „Przywróć” wybranego identyfikatora kopii zapasowej, a zostaną wyświetlone dwie opcje przywracania:
Funkcja „Przywróć i weryfikuj na samodzielnym hoście” wymaga oddzielnego hosta, który nie jest już częścią konfiguracji bazy danych. ClusterControl najpierw wdroży instancję MySQL na docelowym hoście, uruchomi usługę, skopiuje kopię zapasową z repozytorium kopii zapasowych i rozpocznie przywracanie. Po zakończeniu możesz mieć opcję wyłączenia serwera po przywróceniu lub pozostawienia go do działania, aby móc przeprowadzić dalsze dochodzenie na serwerze.
Porządkowanie jest również ważne, aby przechowywać tylko przydatne kopie zapasowe w pamięci. Dlatego w razie potrzeby skonfiguruj przechowywanie kopii zapasowych. Domyślnie ClusterControl usuwa kopie zapasowe starsze niż 30 dni. Możesz także dostosować każdy z harmonogramów tworzenia kopii zapasowych za pomocą różnych okresów przechowywania.
Jeśli miejsce na kopię zapasową zbliża się do limitu miejsca lub chcesz zarchiwizować kopię zapasową poza nią, możesz ręcznie usunąć plik, klikając ikonę kosza lub przesłać go do chmury, jak podkreślono poniżej:
W chwili pisania tego tekstu obsługiwane są AWS S3 i GCP Cloud Storage. Poświadczenia chmury muszą być wstępnie skonfigurowane w menu bocznym -> Integracje -> Dostawcy chmury.
To wszystko, ludzie. Miłego klastrowania!
