Podstawą ClusterControl jest jego automatyzacja, podobnie jak zapewnienie, że Twoje dane są bezpiecznie archiwizowane i gotowe do przywrócenia, gdy coś pójdzie nie tak. Posiadanie skutecznej strategii tworzenia kopii zapasowych i planu odzyskiwania po awarii jest kluczem do sukcesu każdej aplikacji lub środowiska.
W naszej najnowszej wersji, ClusterControl 1.5, wprowadziliśmy szereg ulepszeń do tworzenia kopii zapasowych systemów opartych na MySQL i MariaDB.
Jednym z kluczowych ulepszeń jest możliwość tworzenia kopii zapasowych z ClusterControl do wybranego dostawcy chmury. Dostawcy usług w chmurze, tacy jak Google Cloud Services i Amazon S3, oferują praktycznie nieograniczone miejsce na dane, zmniejszając lokalne zapotrzebowanie na przestrzeń. Pozwala to na dłuższe przechowywanie plików kopii zapasowej tak długo, jak chcesz i nie ma obaw związanych z lokalną przestrzenią dyskową.
Przyjrzyjmy się wszystkim ekscytującym nowym funkcjom tworzenia kopii zapasowych w ClusterControl 1.5...
Przeprojektowanie kreatora kopii zapasowych/przywracania
Przede wszystkim zauważysz, że kreatory tworzenia kopii zapasowych i przywracania zostały zmodernizowane, aby poprawić wrażenia użytkownika. Załaduje się teraz jako menu boczne po prawej stronie ekranu:
Lista kopii zapasowych również zostaje drobna poprawka, w której szczegóły kopii zapasowej są wyświetlane po kliknięciu określonej kopii zapasowej:
Będziesz mógł zobaczyć lokalizację kopii zapasowej i które bazy danych znajdują się w kopii zapasowej. Istnieją również opcje przywrócenia kopii zapasowej lub przesłania jej do chmury.
Kopia zapasowa zgodna z PITR
ClusterControl wykonuje standardową kopię zapasową mysqldump z oddzielnym schematem i zrzutami danych. Ułatwia to przywracanie częściowych kopii zapasowych. Jednak narusza to spójność kopii zapasowej (schemat i dane są zrzucane w dwóch oddzielnych sesjach), dlatego nie można go użyć do udostępnienia urządzenia podrzędnego lub odzyskiwania do punktu w czasie.
Kopia zapasowa zgodna z mysqldump PITR zawiera jeden plik zrzutu z informacjami GTID, plikiem binlogu i pozycją. W związku z tym tylko węzeł bazy danych, który generuje dziennik binarny, będzie miał dostępną opcję „zgodność z PITR”, jak pokazano na poniższym zrzucie ekranu:
Gdy opcja kompatybilna z PITR jest przełączona, pola bazy danych i tabeli są wyszarzone, ponieważ ClusterControl zawsze wykona kopię zapasową we wszystkich bazach danych, zdarzeniach, wyzwalaczach i procedurach docelowego serwera MySQL.
Następujące wiersze pojawią się w pierwszych ~50 wierszach ukończonego pliku zrzutu:
$ head -50 mysqldump_2017-11-07_072250_complete.sql
...
-- GTID state at the beginning of the backup
--
SET @@GLOBAL.GTID_PURGED='20dc5247-4a98-ee18-73af-5c79373388ee:1-1681';
--
-- Position to start replication or point-in-time recovery from
--
CHANGE MASTER TO MASTER_LOG_FILE='binlog.000001', MASTER_LOG_POS=2457790;
...Informacje te mogą być wykorzystane do zbudowania urządzeń podrzędnych z kopii zapasowej lub wykonania odzyskiwania do określonego momentu wraz z dziennikami binarnymi, gdzie można rozpocząć odzyskiwanie z plików MASTER_LOG_FILE i MASTER_LOG_POS zgłoszonych w pliku zrzutu za pomocą narzędzia „mysqlbinlog”. Pamiętaj, że logi binarne nie są archiwizowane przez ClusterControl.
Buduj urządzenia podrzędne z kopii zapasowej Inną funkcją jest możliwość zbudowania urządzenia podrzędnego bezpośrednio z kopii zapasowej zgodnej z PITR, zamiast robić to z wybranego urządzenia nadrzędnego. Jest to ogromna zaleta, ponieważ odciąża serwer główny. Ta opcja może być używana z MySQL Replication lub Galera Cluster. Istniejąca kopia zapasowa może zostać wykorzystana do odbudowania istniejącego urządzenia podrzędnego replikacji lub dodania nowego urządzenia podrzędnego replikacji w fazie przemieszczania, jak pokazano na poniższym zrzucie ekranu:
Po zakończeniu inscenizacji niewolnik połączy się z wybranym mistrzem i zacznie nadrabiać zaległości. Wcześniej ClusterControl wykonywał strumieniową kopię zapasową bezpośrednio z wybranego mastera za pomocą Percona Xtrabackup. Może to mieć wpływ na wydajność mastera podczas skalowania dużego zestawu danych, mimo że operacja nie blokuje mastera. Dzięki nowej opcji, jeśli kopia zapasowa jest przechowywana w ClusterControl, tylko te hosty (ClusterControl + urządzenie podrzędne) będą zajęte podczas umieszczania danych na urządzeniu podrzędnym.
Kopia zapasowa w chmurze
Kopie zapasowe można teraz automatycznie przesyłać do chmury. Wymaga to zainstalowania modułu ClusterControl o nazwie clustercontrol-cloud (moduł integracji z chmurą) i clustercontrol-clud (cLI pobierania/przesyłania w chmurze), które są dostępne w wersji 1.5 i nowszych. Instrukcje aktualizacji zostały dołączone do tych pakietów i są dostarczane bez dodatkowej konfiguracji. Obecnie wspieranymi platformami chmurowymi są Amazon Web Services i Google Cloud Platform. Poświadczenia chmury są konfigurowane w ClusterControl -> Ustawienia -> Integracje -> Dostawcy chmury.
Podczas tworzenia lub planowania kopii zapasowej, po przełączeniu opcji „Prześlij kopię zapasową do chmury” powinieneś zobaczyć następujące dodatkowe opcje:
Ta funkcja umożliwia jednorazowe przesłanie lub zaplanowanie przesyłania kopii zapasowych po zakończeniu (Amazon S3 lub Google Cloud Storage). Następnie możesz pobrać i przywrócić kopie zapasowe zgodnie z wymaganiami.
Niestandardowa kompresja dla mysqldump
Ta funkcja została po raz pierwszy wprowadzona w ClusterControl v1.4.2 po jego wydaniu. Dodaliśmy poziom kompresji kopii zapasowej oparty na gzip. Wcześniej ClusterControl używał domyślnej kompresji kopii zapasowej (poziom 6), jeśli miejsce docelowe kopii zapasowej znajdowało się w węźle kontrolera. Najniższa kompresja (poziom 1 — najszybsza, mniejsza kompresja) była używana, jeśli miejsce docelowe kopii zapasowej znajdowało się na hoście bazy danych, aby zapewnić minimalny wpływ na bazę danych podczas operacji kompresji.
W tej wersji dopracowaliśmy aspekt kompresji i możesz teraz dostosować poziom kompresji, niezależnie od miejsca docelowego kopii zapasowej. Podczas uaktualniania instancji ClusterControl wszystkie zaplanowane kopie zapasowe zostaną automatycznie przekonwertowane na poziom 6, chyba że wyraźnie zmienisz je w wersji 1.5.
Kompresja kopii zapasowej ma kluczowe znaczenie, gdy zestaw danych jest duży, w połączeniu z długimi zasadami przechowywania kopii zapasowych, a przestrzeń dyskowa jest ograniczona. Mysqldump, który jest oparty na tekście, może korzystać z kompresji, oszczędzając do 60% miejsca na dysku oryginalnego rozmiaru pliku. W niektórych przypadkach najwyższy stopień kompresji jest najlepszą opcją, chociaż wiąże się to z ceną dłuższej dekompresji podczas przywracania.
Funkcja bonusowa:automatyczna weryfikacja kopii zapasowej
Jak mówią starzy administratorzy — kopia zapasowa nie jest kopią zapasową, jeśli nie można jej przywrócić. Weryfikacja kopii zapasowej to coś, co zwykle jest przez wielu zaniedbywane. Niektórzy administratorzy opracowali w tym celu wewnętrzne procedury, zwykle bardziej ręczne niż automatyczne. Automatyzacja jest trudna, głównie ze względu na złożoność całej operacji - począwszy od udostępnienia hosta, instalacji i przygotowania MySQL, transferu plików kopii zapasowych, dekompresji, operacji przywracania, procedur weryfikacji i wreszcie oczyszczenia systemu po zakończeniu procesu. Wszystkie te kłopoty sprawiają, że ludzie zaniedbują tak ważny aspekt niezawodnej kopii zapasowej. Generalnie test przywracania kopii zapasowej powinien być wykonywany przynajmniej raz w miesiącu lub w przypadku znaczących zmian w wielkości danych lub strukturze bazy danych. Znajdź harmonogram, który Ci odpowiada i sformalizuj go za pomocą zaplanowanego wydarzenia.
ClusterControl może zautomatyzować weryfikację kopii zapasowej, wykonując przywracanie na świeżym hoście, bez naruszania którejkolwiek z wyżej wymienionych procedur weryfikacji. Można to zrobić z pewnym opóźnieniem lub zaraz po zakończeniu tworzenia kopii zapasowej. Zgłosi stan kopii zapasowej na podstawie kodu zakończenia operacji przywracania, wykona automatyczne zamknięcie, jeśli kopia zapasowa zostanie zweryfikowana, lub po prostu zezwoli na działanie przywróconego hosta, aby przeprowadzić dodatkową ręczną weryfikację danych.
Podczas tworzenia lub planowania kopii zapasowej będziesz mieć dodatkowe opcje, jeśli opcja „Zweryfikuj kopię zapasową” jest włączona:
Jeśli opcja „Zainstaluj oprogramowanie bazy danych” jest włączona, ClusterControl usunie wszelkie istniejące instalacje MySQL na hoście docelowym i ponownie zainstaluje oprogramowanie bazy danych w tej samej wersji, co istniejący serwer MySQL. W przeciwnym razie, jeśli masz określoną konfigurację przywracanego hosta, możesz pominąć tę opcję. Pozostałe opcje są oczywiste.
Funkcja bonusowa:nie zapomnij o PostgreSQL
Oprócz całej tej wspaniałej funkcjonalności dla MySQL i MariaDB, ClusterControl 1.5 zapewnia również PostgreSQL z dodatkową metodą tworzenia kopii zapasowych (pg_basebackup), której można używać do tworzenia kopii zapasowych online. Kopie zapasowe wykonane za pomocą pg_basebackup można później wykorzystać do odzyskiwania do określonego punktu w czasie oraz jako punkt wyjścia do przesyłania dzienników lub serwerów rezerwowych replikacji strumieniowej.
To na razie tyle. Wypróbuj ClusterControl v1.5, pobaw się nowymi funkcjami i daj nam znać, co myślisz.
