Nieprzewidziane zjawiska, takie jak awaria sprzętu, uszkodzenie bazy danych, błędy użytkowników czy nawet złośliwe ataki mogą zwiększyć ryzyko utraty danych. Rozwiązaniem są kopie zapasowe baz danych, dzięki którym łatwiej odzyskasz dane i utrzymasz funkcjonowanie firmy w sytuacji kryzysowej. Kopie zapasowe nie są remedium wyłącznie na sytuacje kryzysowe. W normalnych warunkach pomagają one spełnić wymagania dotyczące zgodności i audytu oraz umożliwiają przywrócenie kopii bazy danych do określonego momentu w przeszłości.
MySQL stanowi w tym wypadku odpowiednie wsparcie. Dostarcza kilku opcji tworzenia kopii zapasowych baz danych o różnych mocach. To od Ciebie zależy wybór kombinacji metod, które w najlepszym stopniu odpowiedzą na Twoje potrzeby.
Typy kopii zapasowej bazy danych
W jaki sposób utworzyć kopię zapasową bazy MySQL? Istnieją na to dwa sposoby: fizyczny i logiczny.
Fizyczna kopia bazy danych polega na kopiowaniu rzeczywistych plików danych, podczas gdy logiczna kopia zapasowa generuje instrukcje takie jak CREATE TABLE oraz INSERT. Umożliwiają one późniejsze odtworzenie danych.
Fizyczna kopia bazy danych MySQL
Tak jak w skrócie przedstawiliśmy to wyżej, fizyczna kopia zapasowa bazy danych MySQL zawiera surowe kopie wszystkich plików i katalogów w takiej formie, w jakiej istnieją na dysku. Kto powinien zdecydować się na ten typ?
Fizyczna kopia danych zapasowych jest dobrym rozwiązaniem w przypadku dużych baz danych. Kopiowanie nieprzetworzonych plików jest znacznie szybsze w porównaniu do wykonywania logicznej kopii zapasowej
Zalety:
- Prostota i wydajność – fizyczne kopie zapasowe nie wymagają dużo pamięci ani wielu cykli procesora.
- Ograniczenie dodatkowej pracy – wystarczy skopiować surowe pliki oraz katalogi do docelowej lokalizacji kopii zapasowej.
- Szybsze przywracanie – ponieważ MySQL nie musi odtwarzać obiektów baz danych czy importować danych, fizyczne przywracanie bazy danych następuje szybciej niż w przypadku przywracania logicznego.
Wady:
- Zajęcie więcej miejsca – minusem fizycznych kopii zapasowych baz danych MySQL jest to, że zawierają dzienniki transakcji (transaction logs) i dzienniki cofania (udndo logs) – to wszystko zajmuje miejsce na dyskach.
- Trudność w przenoszeniu między środowiskami – dla tego typu kopii zapasowych problemem może okazać się brak możliwości przenoszenia baz między platformami, systemami operacyjnymi czy wersjami MySQL.
- Powielanie uszkodzonych plików – przenosząc w całości uszkodzone surowe pliki zostawiamy je w takiej samej, niepoprawnie działającej postaci.
Z jakich narzędzi można skorzystać przy fizycznym tworzeniu kopii zapasowych baz MySQL? Do najbardziej popularnych należą:
- MySQL Enterprise Backup,
- PerconaXtraBackup,
- MariaDB Mariabackup.
Logiczna kopia bazy danych MySQL
Logiczna kopia zapasowa bazy MySQL zawiera dane, które MySQL może zinterpretować jako SQL lub jako tekst rozdzielany (delimited text). Mówimy więc o reprezentacji bazy danych w postaci sekwencji instrukcji SQL, które można wykonać w celu odtworzenia obiektów bazy danych i zaimportowania danych. Kto powinien rozważyć wybór logicznej kopii zapasowej bazy danych MySQL?
Z pewnością jest to rozwiązanie dedykowane małym bazą danych, gdyż odwrotnie niż w przypadku kopii fizycznej, przywracanie logicznych kopii zapasowych zajmuje więcej czasu. Warto z niego skorzystać podczas migracji do zarządzanych usług bazy danych w chmurze, lub też w kierunku odwrotnym.
Zalety:
- Elastyczność – duża szczegółowość operacji tworzenia kopii zapasowych i przywracania na poziomie serwera, poziomie bazy danych, poziomie tabeli czy nawet poziomie wiersza (jeżeli wiersze tabeli spełniają warunek WHERE) zapewnia sporą elastyczność.
- Łatwość przywracania – logiczne kopie zapasowe są łatwiejsze do przywracania. Wystarczy przesłać plik kopii zapasowej do klient MySQL i użyć instrukcji LOAD DATA lub też polecenia mysqlimport, aby załadować pliki rozdzielone tekstem.
- Zdalne uruchamianie – logiczne kopie zapasowe można uruchomić zdalnie co umożliwia tworzenie kopii zapasowych lub też przywracanie baz danych przez sieć. Rozwiązanie to przydaje się szczególnie w przypadku baz danych w chmurze, bez względu czy będzie to Google Cloud SQL, Amazon RDS czy Microsoft Azure.
- Unikanie uszkodzenia danych – o ile w przypadku kopii fizycznych, uszkodzone dane mogą pozostać niezauważone aż do momentu weryfikacji, to w przypadku kopii logicznych, które są najczęściej plikami tekstowymi, łatwo jest je przejrzeć za pomocą edytora tekstu i wykryć wszelkie uszkodzenia.
- Łatwość przenoszenia – tu kolejna odwrotność w stosunku do kopii fizycznych. Logiczne kopie baz danych łatwo przenosi się pomiędzy platformami, systemami operacyjnymi oraz wersjami MySQL.
- Wysoki poziom kompresji kopii zapasowych.
Wady:
- Czasochłonność – kopie zapasowe są tutaj tworzone wolniej, gdyż konieczne jest wysyłanie zapytania do serwera MySQL w celu uzyskania schematu i wierszy, które następnie muszą zostać przekonwertowane do formatu logicznego.
- Długotrwałe przywracanie logicznych kopii zapasowych – to kolejne działanie, które może zająć sporo czasu. MySQL musi wykonać instrukcje SQL aby utworzyć tabele, zaimportować wiersze i odbudować indeksy.
- Wymagane większe zasoby serwera – do operacji tworzenia logicznych kopii zapasowych wymagane jest wykorzystanie większych zasobów procesora czy pamięci RAM.
Do popularnych narzędzi służących do tworzenia logicznych kopii zapasowych należą:
- mysqldump,
- mydumper,
- Mysqlpump.
Zarezerwuj rozmowę z architektem chmurowym.
Point-in-time recovery (PITR)
Po różne narzędzia odzyskiwania danych sięgamy najczęściej w wyniku sytuacji, w której w wyniku błędu tracimy do nich dostęp. Point-in-time recovery pozwala odzyskać instancji do określonego momentu, czyli jeżeli błąd spowodował utratę danych, to korzystając z narzędzia PITR można odzyskać bazę w stanie, w jakim była przed nastąpieniem błędu.
PITR jest procesem dwuetapowym, opierającym się na logach binarnych. W pierwszym przywraca pełną fizyczną lub logiczną kopię zapasową jaka była w momencie jej utworzenia.
W drugim etapie, stosując dzienniki binarne można odtworzyć zmiany między momentem utworzenia kopii zapasowej a żądanym momentem. Dzienniki binarne zawierają wszelkie zmiany wprowadzone w instancji bazy danych w tym utworzenie tabeli czy wstawienie, aktualizację lub usunięcie wiersza.
Jak to wygląda w praktyce? Jeżeli kopie zapasowe tworzone są codziennie o godzinie 8 rano, a problem pojawił się o godzinie 12 to w pierwszym kroku przywracane są kopie zapasowe z godziny 10, a następnie z wykorzystaniem dziennika binarnego odtwarzane są zdarzenia z czterogodzinnego okna czasowego pomiędzy godziną 10 a 12.
Backup bazy danych w ramach Google Cloud
W ramach Google Cloud mamy do czynienia z zarządzaną bazą – Cloud SQL. O tym jak w jej ramach działa backup pisaliśmy w tym artykule. Możesz też skorzystać z wiedzy i doświadczenia architektów Google Cloud firmy FOTC, którzy pomogą Ci zabezpieczyć bazy danych przed skutkami awarii.
