Pełne przywracanie klastra MySQL lub MariaDB Galera z kopii zapasowej

Regularne wykonywanie kopii zapasowych klastra bazy danych jest niezbędne do zapewnienia wysokiej dostępności i odzyskiwania po awarii. Jeśli z jakiegoś powodu utraciłeś cały klaster i musiałeś wykonać pełne przywracanie z kopii zapasowej, potrzebujesz niezawodnej i aktualnej kopii zapasowej, aby zacząć od niej.

Najlepsze praktyki dotyczące kopii zapasowych

Kilka zaleceń, które należy wziąć pod uwagę w celu uzyskania dobrego harmonogramu tworzenia kopii zapasowych:

Powinieneś być w stanie całkowicie odzyskać dane po katastrofalnej awarii z co najmniej dwóch poprzednich pełnych kopii zapasowych. Na wypadek, gdyby najnowsza pełna kopia zapasowa została uszkodzona, utracona lub uszkodzona,
Twoja kopia zapasowa powinna zawierać co najmniej jedną pełną kopię zapasową w wybranym cyklu, zwykle co tydzień,
Przechowuj kopie zapasowe z dala od bieżącej lokalizacji danych, najlepiej poza siedzibą
Użyj kombinacji mysqldump i Xtrabackup dla dodatkowego bezpieczeństwa i nie polegaj na jednej metodzie,
Testuj regularne przywracanie kopii zapasowych, np. co dwa miesiące.

Zwykle wystarcza cotygodniowa pełna kopia zapasowa w połączeniu z codzienną przyrostową kopią zapasową. Przechowywanie pewnej liczby kopii zapasowych przez pewien okres czasu jest zawsze dobrym planem, być może przechowuj każdą cotygodniową kopię zapasową przez jeden miesiąc. Pozwala to na odzyskanie starszej bazy danych w sytuacjach awaryjnych lub w przypadku uszkodzenia lokalnego pliku kopii zapasowej.

mysqldump lub Xtrabackup

mysqldump jest prawdopodobnie najpopularniejszym sposobem tworzenia kopii zapasowej MySQL. Wykonuje logiczną kopię zapasową danych, odczytując z każdej tabeli za pomocą instrukcji SQL, a następnie eksportując dane do plików tekstowych. Przywracanie mysqldump jest tak proste, jak tworzenie pliku zrzutu. Główną wadą jest to, że jest bardzo powolny w przypadku dużych baz danych, nie jest „gorący” i wymazuje pulę buforów InnoDB.

Xtrabackup wykonuje kopie zapasowe na gorąco, nie blokuje bazy danych podczas tworzenia kopii zapasowej i generalnie jest szybszy. Kopie zapasowe na gorąco są ważne dla wysokiej dostępności, ponieważ działają bez blokowania aplikacji. Jest to również ważny czynnik w przypadku korzystania z Galera, ponieważ Galera opiera się na replikacji synchronicznej. Jednak przywracanie xtrabackup przy użyciu ręcznych sposobów może być trochę trudne.

ClusterControl obsługuje planowanie zarówno mysqldump, jak i Xtrabackup (pełne i przyrostowe), a także przywracanie kopii zapasowych bezpośrednio z interfejsu użytkownika.

Pełne przywracanie z kopii zapasowej

W tym poście pokażemy, jak przywrócić Xtrabackup (pełny + przyrostowy) do pustego klastra działającego na MariaDB Galera Cluster. Te kroki powinny również działać w klastrze Percona XtraDB lub Galera Cluster for MySQL firmy Codership.

W naszym pierwotnym klastrze mieliśmy codziennie zaplanowaną pełną xtrabackup, z przyrostowymi kopiami zapasowymi tworzonymi co godzinę. Kopie zapasowe są przechowywane w ClusterControl, jak pokazano na poniższym zrzucie ekranu:

Załóżmy teraz, że straciliśmy oryginalny klaster i musimy wykonać pełne przywracanie do nowego klastra. Kroki obejmują:

Skonfiguruj nowy serwer ClusterControl.
Skonfiguruj nowy klaster MariaDB.
Eksportuj kopie zapasowe i pliki do nowego serwera ClusterControl.
Rozpocznij proces przywracania.
Uruchom pozostałe węzły.

Poniższy diagram ilustruje naszą architekturę dla tego ćwiczenia:

Krok 1 — skonfiguruj nowy klaster MariaDB

Zainstaluj ClusterControl i wdróż nowy klaster MariaDB. Przejdź do ClusterControl -> Wdróż -> Wdróż klaster bazy danych -> MySQL Galera i podaj wymagane informacje w oknie wdrażania:

Kliknij przycisk Wdróż i rozpocznij wdrażanie. Ponieważ mamy klaster tylko na starym serwerze, identyfikator klastra powinien być identyczny (identyfikator klastra:1) w nowej instancji.

Krok 2 — Eksportuj i importuj pliki kopii zapasowych Po wdrożeniu klastra będziemy musieli zaimportować kopie zapasowe ze starego serwera ClusterControl do nowego. Najpierw wyeksportuj zawartość cmon.backup_records do plików zrzutu. Ponieważ stary identyfikator klastra i nowy są identyczne, wystarczy zmodyfikować plik zrzutu przy użyciu nowego adresu IP i zaimportować go do nowego węzła ClusterControl. Jeśli identyfikator klastra jest inny, musisz odpowiednio zmienić wartość „cid” w plikach zrzutu przed zaimportowaniem do CMON DB w nowym węźle. Ponadto łatwiej jest zachować lokalizację przechowywania kopii zapasowych, jak na starym serwerze, dzięki czemu nowy ClusterControl może zlokalizować pliki kopii zapasowych na nowym serwerze.

Na starym serwerze ClusterControl wyeksportuj tabelę backup_records do plików zrzutu:

$ mysqldump -uroot -p --single-transaction --no-create-info cmon backup_records > backup_records.sql

Następnie wykonaj zdalne kopiowanie plików kopii zapasowej ze starego serwera na nowy serwer ClusterControl:

$ scp -r /root/backups 192.168.55.150:/root/
$ scp ~/backup_records.sql 192.168.55.150:~

Następnie należy zmodyfikować pliki zrzutu, aby odzwierciedlały nowy adres IP serwera ClusterControl. Nie zapomnij zamienić kropki w adresie IP:

$ sed -i "s/192\.168\.55\.170/192\.168\.55\.150/g" backup_records.sql

Na nowym serwerze ClusterControl zaimportuj pliki zrzutu:

$ mysql -uroot -p cmon < backup_records.sql

Sprawdź, czy lista kopii zapasowych jest poprawna na nowym serwerze ClusterControl:

Jak widać, wszystkie wystąpienia poprzedniego adresu IP (192.168.55.170) zostały zastąpione nowym adresem IP (192.168.55.150). Teraz jesteśmy gotowi do przywrócenia na nowym serwerze.

Krok 3 — Wykonaj przywracanie

Wykonywanie przywracania za pomocą interfejsu użytkownika ClusterControl to prosty krok typu „wskaż i kliknij”. Wybierz kopię zapasową do przywrócenia i kliknij przycisk „Przywróć”. Zamierzamy przywrócić najnowszą dostępną przyrostową kopię zapasową (Kopia zapasowa:9). Kliknij przycisk „Przywróć” tuż pod nazwą kopii zapasowej, a zostanie wyświetlone następujące okno dialogowe przed przywróceniem:

Wygląda na to, że rozmiar kopii zapasowej jest dość mały (165,6 kB). To naprawdę nie ma znaczenia, ponieważ ClusterControl przygotuje wszystkie przyrostowe kopie zapasowe zgrupowane w zestawie kopii zapasowych 6, który zawiera pełną Xtrabackup. Masz również kilka opcji po przywróceniu:

Przywróć kopię zapasową na — wybierz węzeł, na którym chcesz przywrócić kopię zapasową.
Tmp Dir — Katalog będzie używany na lokalnym serwerze ClusterControl jako tymczasowy magazyn podczas przygotowywania kopii zapasowej. Musi być tak duży, jak szacowany katalog danych MySQL.
Bootstrap klaster z przywróconego węzła — ponieważ jest to nowy klaster, włączymy to, aby ClusterControl automatycznie uruchomił klaster po pomyślnym przywróceniu.
Zrób kopię katalogu datadir przed przywróceniem kopii zapasowej — Jeśli przywrócone dane są uszkodzone lub nie tak, jak oczekiwano, będziesz mieć kopię zapasową poprzedniego katalogu danych MySQL. Ponieważ jest to nowy klaster, zignorujemy ten.

Przywrócenie Percona Xtrabackup spowoduje zatrzymanie klastra. ClusterControl:

Zatrzymaj wszystkie węzły w klastrze.
Przywróć kopię zapasową w wybranym węźle.
Bootstrap wybranego węzła.

Aby zobaczyć postęp przywracania, przejdź do Aktywność -> Zadania -> Przywróć kopię zapasową i kliknij przycisk „Pełne szczegóły zadania”. Powinieneś zobaczyć coś takiego:

Jedną ważną rzeczą, którą musisz zrobić, jest monitorowanie danych wyjściowych dziennika błędów MySQL w węźle docelowym (192.168.55.151) podczas procesu przywracania. Po zakończeniu przywracania i podczas procesu ładowania początkowego powinny pojawić się następujące linie:

Version: '10.1.22-MariaDB' socket: '/var/lib/mysql/mysql.sock' port: 3306 MariaDB Server
2017-04-07 18:03:51 140608191986432 [Warning] Access denied for user 'cmon'@'192.168.55.150' (using password: YES)
2017-04-07 18:03:51 140608191986432 [Warning] Access denied for user 'cmon'@'192.168.55.150' (using password: YES)
2017-04-07 18:03:51 140608191986432 [Warning] Access denied for user 'cmon'@'192.168.55.150' (using password: YES)
2017-04-07 18:03:52 140608191986432 [Warning] Access denied for user 'cmon'@'192.168.55.150' (using password: YES)
2017-04-07 18:03:53 140608191986432 [Warning] Access denied for user 'cmon'@'192.168.55.150' (using password: YES)
2017-04-07 18:03:54 140608191986432 [Warning] Access denied for user 'cmon'@'192.168.55.150' (using password: YES)
2017-04-07 18:03:55 140608191986432 [Warning] Access denied for user 'cmon'@'192.168.55.150' (using password: YES)

Nie panikować. Jest to oczekiwane zachowanie, ponieważ ten zestaw kopii zapasowych nie przechowuje poświadczeń logowania cmon nowego hasła cmon ClusterControl. Zamiast tego przywrócił/zastąpił starego użytkownika cmona. Musisz ponownie przydzielić użytkownika cmon z powrotem do serwera, uruchamiając następującą instrukcję na tym węźle bazy danych:

GRANT ALL PRIVILEGES ON *.* to [email protected]'192.168.55.150' IDENTIFIED BY 'mynewCMONpassw0rd' WITH GRANT OPTION;
FLUSH PRIVILEGES;

ClusterControl będzie wtedy w stanie połączyć się z węzłem ładowanym i określić stan węzła i kopii zapasowej. Jeśli wszystko jest w porządku, powinieneś zobaczyć coś takiego:

W tym momencie węzeł docelowy jest uruchamiany i uruchamiany. Pozostałe węzły możemy uruchomić w sekcji Węzły -> wybierz węzeł -> Uruchom węzeł i zaznacz pole wyboru „Wykonaj początkowy start”:

Przywracanie jest teraz zakończone i możesz oczekiwać, że Wydajność -> Przyrost bazy danych zgłosi zaktualizowany rozmiar naszego nowo przywróconego zestawu danych:

Miłego przywracania!