Categories
Database Backup

** Discover why mysqldump fails large MySQL databases and learn how to implement enterprise-grade physical backups using Percona XtraBackup and CloudSave to drastically reduce your RTO.

Przez dziesięciolecia mysqldump był niekwestionowanym szwajcarskim scyzorykiem do tworzenia kopii zapasowych baz danych MySQL. Jest wszechobecny, prosty i instalowany domyślnie w każdej dystrybucji MySQL i MariaDB. W przypadku małych i średnich baz danych sprawdza się znakomicie.

Jednak w miarę rozwoju organizacji i przekraczania przez zbiory danych progów 100 GB, 500 GB czy wielu terabajtów, poleganie na mysqldump przestaje być dobrą praktyką, a staje się krytyczną luką w architekturze. Jeśli jesteś administratorem baz danych (DBA) lub inżynierem DevOps zarządzającym wielkoskalowymi bazami produkcyjnymi, prawdopodobnie doświadczyłeś już cichych awarii, degradacji wydajności produkcji i nieakceptowalnych wskaźników Recovery Time Objective (RTO) związanych z logicznymi zrzutami danych.

W tym artykule przeanalizujemy ograniczenia architektoniczne mysqldump, wyjaśnimy, dlaczego zawodzi on na dużą skalę, oraz szczegółowo opiszemy, jak wdrożyć fizyczne strategie tworzenia kopii zapasowych klasy korporacyjnej, aby chronić Twoje krytyczne dane.

Ograniczenia architektoniczne mysqldump

Aby zrozumieć, dlaczego mysqldump zawodzi na dużą skalę, musimy przyjrzeć się jego działaniu od podszewki. mysqldump wykonuje kopie logiczne. Odpytuje silnik bazy danych, odczytuje dane i tłumaczy je na serię instrukcji SQL (głównie CREATE TABLE i INSERT INTO).

Choć tworzy to wysoce przenośny i czytelny dla człowieka plik, wprowadza poważne wąskie gardła w środowiskach o wysokiej przepustowości.

1. Wąskie gardło jednowątkowości

Z założenia mysqldump jest operacją jednowątkową. Przetwarza jedną tabelę na raz, wiersz po wierszu. Podczas gdy nowoczesny sprzęt dysponuje dziesiątkami rdzeni procesora i pamięcią NVMe zdolną do obsługi gigabajtów przepustowości na sekundę, mysqldump wykorzystuje tylko ułamek tych zasobów.

Nawet przy użyciu standardowych flag dla tabel InnoDB:

mysqldump -u root -p --single-transaction --routines --triggers --events --quick production_db > backup.sql

Flaga --quick wymusza na mysqldump pobieranie wierszy pojedynczo, zamiast buforowania całej tabeli w pamięci, co zapobiega błędom Out of Memory (OOM) po stronie klienta. Jednak jednowątkowy charakter oznacza, że zrzut 500 GB bazy danych może zająć od 10 do 15 godzin, co poważnie wpływa na Twój wskaźnik Recovery Point Objective (RPO).

2. Zanieczyszczenie puli buforów InnoDB (Buffer Pool)

Kiedy mysqldump odczytuje każdy wiersz każdej tabeli, zmusza silnik MySQL do załadowania tych danych z dysku do puli buforów InnoDB. W środowisku produkcyjnym pula buforów jest starannie wypełniona Twoim „gorącym” zestawem danych.

Ogromny zrzut logiczny „przemiecie” pulę buforów, usuwając często używane indeksy i strony danych, aby zrobić miejsce dla „zimnych” danych, które są kopiowane. Skutkuje to nagłym, ogromnym skokiem operacji wejścia/wyjścia (I/O) na dysku, ponieważ zapytania produkcyjne są zmuszone do odczytu z dysku, co prowadzi do poważnych opóźnień aplikacji.

3. Blokady metadanych i konflikty DDL

Aby zachować spójność, administratorzy polegają na fladze --single-transaction, która ustawia poziom izolacji transakcji na REPEATABLE READ i rozpoczyna transakcję przed zrzutem danych.

Choć pozwala to uniknąć blokad odczytu na poziomie tabeli (FLUSH TABLES WITH READ LOCK), nie chroni przed zmianami w języku definicji danych (DDL). Jeśli polecenie ALTER TABLE, DROP TABLE lub TRUNCATE TABLE zostanie wykonane na tabeli w trakcie działania mysqldump, kopia zapasowa zakończy się błędem table definition has changed, please retry transaction. W środowiskach CI/CD z częstymi migracjami schematu powoduje to ciągłe awarie kopii zapasowych.

4. Koszmar RTO: Czasy przywracania

Najbardziej katastrofalna wada mysqldump ujawnia się nie podczas tworzenia kopii, ale podczas jej przywracania.

Przywrócenie zrzutu logicznego wymaga od silnika MySQL przeanalizowania i wykonania milionów instrukcji INSERT. Dla każdego wstawionego wiersza MySQL musi:

  • Sprawdzić ograniczenia (klucze obce, klucze unikalne).
  • Odbudować indeksy pomocnicze w locie.
  • Zapisać dane do dziennika transakcji InnoDB (redo log).
  • Zapisać dane do dziennika binarnego (binlog, jeśli jest włączony).

Przywrócenie 1 TB bazy danych z logicznego zrzutu może zająć kilka dni. Jeśli Twoja firma ma RTO na poziomie 4 godzin, mysqldump gwarantuje, że nie dotrzymasz warunków umowy o poziomie świadczenia usług (SLA).

Alternatywy klasy korporacyjnej: Przejście na kopie fizyczne

Aby uzyskać szybkie kopie zapasowe i przywracanie dla dużych zbiorów danych, musisz porzucić kopie logiczne na rzecz kopii fizycznych.

Kopie fizyczne całkowicie omijają silnik wykonywania SQL w MySQL. Zamiast tego kopiują podstawowe binarne pliki danych (pliki .ibd, dzienniki redo i undo) bezpośrednio z systemu plików. Ponieważ polegają one jedynie na kopiowaniu plików, mogą działać z maksymalną sekwencyjną prędkością odczytu/zapisu Twojego sprzętu i mogą być łatwo zrównoleglone.

Percona XtraBackup: Standard branżowy

Dla silników InnoDB i XtraDB, Percona XtraBackup jest wiodącym narzędziem open-source do tworzenia fizycznych kopii zapasowych. Wykonuje ono „gorące”, nieblokujące kopie zapasowe baz danych MySQL.

Jak działa XtraBackup

  1. Kopiowanie danych: XtraBackup rozpoczyna kopiowanie plików danych InnoDB (.ibd).
  2. Śledzenie dzienników: Ponieważ baza danych działa, dane będą się zmieniać podczas kopiowania plików. XtraBackup uruchamia wątek w tle, który monitoruje i kopiuje dziennik redo InnoDB (ib_logfile0 itd.) dla wszystkich transakcji, które wystąpiły w oknie tworzenia kopii.
  3. Przygotowanie (odzyskiwanie po awarii): Po zakończeniu tworzenia kopii, skopiowane pliki danych są w niespójnym stanie. XtraBackup stosuje skopiowane dzienniki redo do plików danych (podobnie jak MySQL wykonuje odzyskiwanie po awarii podczas uruchamiania), co skutkuje idealnie spójną migawką bazy danych w momencie zakończenia tworzenia kopii.

Wdrażanie strategii fizycznej kopii zapasowej

Oto techniczny przewodnik wdrażania strategii fizycznej kopii zapasowej przy użyciu Percona XtraBackup.

Krok 1: Strumieniowanie kopii zapasowej

Zapisywanie ogromnej kopii zapasowej na lokalnym dysku często powoduje problemy z pojemnością. Dobrą praktyką jest strumieniowanie kopii bezpośrednio do formatu archiwum, kompresowanie jej i wysyłanie do obszaru tymczasowego lub bezpośrednio na platformę do tworzenia kopii zapasowych.

Używając xbstream, możemy zrównoleglić tworzenie kopii i kompresować ją w locie:

xtrabackup --backup 
  --user=backup_user 
  --password=SecurePassword! 
  --parallel=4 
  --stream=xbstream | lz4 > /mnt/backups/mysql_prod_backup.xbstream.lz4
  • --parallel=4: Wykorzystuje 4 wątki do jednoczesnego odczytu plików danych.
  • --stream=xbstream: Wyprowadza kopię w niestandardowym formacie strumieniowym Percona.
  • lz4: Zapewnia niezwykle szybką kompresję przy niskim obciążeniu procesora.

Krok 2: Przygotowanie kopii do przywrócenia

Zanim fizyczna kopia zapasowa będzie mogła zostać przywrócona, musi zostać „przygotowana” (poprzez zastosowanie dzienników redo). Najpierw wyodrębnij i zdekompresuj strumień:

mkdir -p /data/restore
lz4 -d /mnt/backups/mysql_prod_backup.xbstream.lz4 | xbstream -x -C /data/restore

Następnie uruchom fazę przygotowania. Ten krok wymaga pamięci, więc upewnij się, że serwer ma przydzieloną odpowiednią ilość pamięci RAM:

xtrabackup --prepare --use-memory=4G --target-dir=/data/restore

Krok 3: Przywracanie bazy danych

Aby przywrócić bazę, docelowy katalog danych MySQL musi być całkowicie pusty. Zatrzymaj usługę MySQL, wyczyść katalog i skopiuj pliki z powrotem:

systemctl stop mysql
rm -rf /var/lib/mysql/*

xtrabackup --copy-back --target-dir=/data/restore

Na koniec napraw uprawnienia systemu plików przed uruchomieniem usługi:

chown -R mysql:mysql /var/lib/mysql
systemctl start mysql

Ponieważ pliki danych są już zbudowane, a indeksy skompilowane, baza danych uruchamia się natychmiast. Przywracanie, które przy użyciu mysqldump zajmowało 48 godzin, teraz trwa tylko tyle, ile skopiowanie plików przez sieć lub dysk — często skracając RTO do minut.

Optymalizacja przywracania logicznego (gdy musisz z niego korzystać)

Jeśli jesteś zmuszony przywrócić duży zrzut logiczny (np. podczas migracji między różnymi głównymi wersjami MySQL lub różnymi architekturami procesorów, gdzie pliki fizyczne są niekompatybilne), musisz tymczasowo dostosować konfigurację MySQL, aby zoptymalizować ją pod kątem ogromnej przepustowości zapisu.

Zastosuj te ustawienia w swoim my.cnf przed rozpoczęciem przywracania logicznego:

[mysqld]
# Tymczasowe wyłączenie logowania binarnego, jeśli jest to samodzielne przywracanie
disable_log_bin

# Opóźnienie zapisu na dysk w celu maksymalizacji prędkości zapisu
innodb_flush_log_at_trx_commit = 2

# Zwiększenie puli buforów, aby pomieścić jak największą część zestawu roboczego
innodb_buffer_pool_size = <Ustaw na 70% całkowitej pamięci RAM>

# Zwiększenie rozmiaru pliku dziennika, aby zapobiec agresywnemu punktowaniu kontrolnemu
innodb_log_file_size = 2G

# Wyłączenie bufora doublewrite (ryzykowne dla produkcji, bezpieczne dla początkowego ładowania)
innodb_doublewrite = 0

Uwaga: Zawsze przywracaj te ustawienia do ich domyślnych wartości zgodnych z ACID (innodb_flush_log_at_trx_commit = 1, innodb_doublewrite = 1) i restartuj usługę MySQL przed zezwoleniem na ruch produkcyjny.

Automatyzacja i zabezpieczanie kopii zapasowych za pomocą CloudSave

Podczas gdy narzędzia takie jak Percona XtraBackup rozwiązują kwestię wydajnego wyodrębniania danych, prawdziwa strategia odzyskiwania po awarii klasy korporacyjnej wymaga orkiestracji, bezpiecznego przechowywania poza siedzibą firmy i zarządzania cyklem życia. Poleganie na niestandardowych skryptach bash i zadaniach cron do zarządzania fizycznymi kopiami zapasowymi wiąże się z wysokim ryzykiem cichych awarii i naruszeń zgodności.

W tym miejscu kluczowa staje się integracja warstwy bazy danych z platformą korporacyjną, taką jak CloudSave.

CloudSave wypełnia lukę między surowymi narzędziami bazodanowymi a zgodnością korporacyjną. Wykorzystując możliwości skryptowania przed i po operacji w CloudSave, zespoły DevOps mogą wyzwolić XtraBackup w celu wygenerowania spójnej fizycznej migawki. CloudSave następnie płynnie pobiera strumień kopii zapasowej, stosuje szyfrowanie AES-256 i deduplikuje dane przed replikacją do niezmiennej pamięci masowej w chmurze.

Taka architektura zapewnia, że:

  1. Utrzymana jest wydajność produkcji: Kopie zapasowe działają z prędkością pamięci masowej bez zanieczyszczania puli buforów InnoDB.
  2. Ochrona przed ransomware: Zasady niezmienności pamięci masowej w CloudSave uniemożliwiają złośliwym podmiotom usuwanie lub szyfrowanie Twoich archiwów baz danych.
  3. Zautomatyzowana retencja: Zasady retencji GFS (Grandfather-Father-Son) są obsługiwane automatycznie, zapewniając zgodność z wymogami suwerenności danych i audytu.
  4. Przewidywalne RTO: Ponieważ CloudSave zarządza fizycznymi archiwami plików, przywracanie wieloterabajtowej bazy danych do nowej instancji może być szybko zaaranżowane, spełniając rygorystyczne cele RTO.

Podsumowanie

Dalsze używanie mysqldump dla wielkoskalowych baz danych to hazard z dostępnością i integralnością danych Twojej organizacji. Jednowątkowy charakter, zanieczyszczanie puli buforów i katastrofalne czasy przywracania sprawiają, że jest on zasadniczo nieodpowiedni dla nowoczesnych środowisk o wysokiej przepustowości.

Przechodząc na fizyczne kopie zapasowe przy użyciu narzędzi takich jak Percona XtraBackup oraz organizując cykl życia, szyfrowanie i replikację poza siedzibą firmy za pośrednictwem solidnej platformy, takiej jak CloudSave, przekształcasz swoją strategię tworzenia kopii zapasowych z kruchego obciążenia w odporny zasób klasy korporacyjnej. Oceń swoje obecne wskaźniki RTO i RPO już dziś — jeśli przywracanie trwa dłużej, niż Twoja firma może sobie pozwolić na bycie offline, czas porzucić mysqldump.

Kategorie