Dla inżynierów DevOps i administratorów systemów migawki (snapshoty) maszyn wirtualnych (VM) są podstawowym narzędziem. Zapewniają szybki i wygodny sposób na uchwycenie stanu serwera przed ryzykowną poprawką, poważną zmianą konfiguracji lub wdrożeniem aplikacji. Jeśli coś pójdzie nie tak, przywrócenie stanu zajmuje sekundy.
Jednakże, gdy ta sama metodologia jest stosowana do baz danych transakcyjnych — takich jak PostgreSQL, MySQL, Oracle czy Microsoft SQL Server — migawki VM zmieniają się z zabezpieczenia w tykającą bombę zegarową.
Poleganie na standardowych migawkach hiperwizora w celu tworzenia kopii zapasowych baz danych jest jedną z najczęstszych przyczyn uszkodzeń danych, „poszarpanych stron” (torn pages) i nieodwracalnych awarii produkcyjnych. W tym artykule przyjrzymy się konfliktowi architektonicznemu między hiperwizorami a silnikami baz danych, mechanice uszkodzeń danych podczas tworzenia migawek oraz najlepszym praktykom inżynieryjnym wymaganym do bezpiecznego tworzenia kopii zapasowych zwirtualizowanych baz danych.
Konflikt architektoniczny: Hiperwizory kontra silniki baz danych
Aby zrozumieć, dlaczego migawki VM zagrażają bazom danych, musimy najpierw zbadać, w jaki sposób oba systemy zarządzają stanem i operacjami wejścia/wyjścia (I/O).
Jak hiperwizory wykonują migawki
Kiedy hiperwizor (taki jak VMware ESXi, Microsoft Hyper-V lub KVM) wykonuje migawkę, nie kopiuje dysku. Zamiast tego zamraża bieżący plik dysku wirtualnego (np. .vmdk lub .vhdx) do stanu tylko do odczytu i tworzy nowy dysk delta (dysk różnicowy). Wszystkie kolejne operacje zapisu są kierowane na ten dysk delta.
Po usunięciu migawki hiperwizor musi zatwierdzić (skonsolidować) dane z dysku delta z powrotem do dysku bazowego. Standardowe migawki nie mają żadnej wiedzy o aplikacjach działających wewnątrz systemu operacyjnego gościa. Rejestrują stan dysku dokładnie w takiej postaci, w jakiej istnieje w danej mikrosekundzie.
Jak bazy danych transakcyjnych zarządzają stanem
Bazy danych transakcyjnych są projektowane w oparciu o właściwości ACID (Atomowość, Spójność, Izolacja, Trwałość). Aby osiągnąć wysoką wydajność przy zachowaniu zgodności z ACID, bazy danych nie zapisują każdej transakcji bezpośrednio do głównych plików danych na dysku w czasie rzeczywistym. Zamiast tego wykorzystują złożoną, wielopoziomową architekturę:
- Pula buforów / Współdzielone bufory: Dane są odczytywane i modyfikowane w pamięci systemowej.
- Dziennik transakcji (WAL) / Redo Logs: Zmiany są sekwencyjnie zapisywane w wysoce zoptymalizowanym pliku dziennika na dysku, aby zapewnić trwałość.
- Punkty kontrolne (Checkpoints) / Lazy Writers: Okresowo baza danych przenosi zmodyfikowane (brudne) strony z pamięci do właściwych plików danych na dysku.
Z powodu tej architektury fizyczne pliki danych na dysku prawie zawsze nie są zsynchronizowane z rzeczywistym stanem bazy danych. Prawdziwy stan bazy danych istnieje tylko jako kombinacja plików danych na dysku, dzienników WAL/Redo oraz danych znajdujących się aktualnie w pamięci.
Strefa zagrożenia: Co dzieje się podczas migawki VM
Kiedy wykonujesz standardową migawkę VM serwera bazy danych, rejestrujesz stan spójny w przypadku awarii (crash-consistent).
Spójność w przypadku awarii a spójność aplikacji
Migawka spójna w przypadku awarii jest odpowiednikiem wyciągnięcia kabla zasilającego z fizycznego serwera. Stan dysku zostaje uchwycony, ale wszystko, co znajdowało się w pamięci, zostaje utracone, a operacje będące w trakcie przesyłania do kontrolera pamięci masowej zostają nagle przerwane.
Chociaż nowoczesne bazy danych są zaprojektowane tak, aby odzyskiwać sprawność po nieoczekiwanej utracie zasilania poprzez odtworzenie dziennika transakcji (WAL), poleganie na odzyskiwaniu po awarii jako głównej strategii tworzenia kopii zapasowych jest bardzo niebezpieczne. Jeśli baza danych rozciąga się na wiele dysków wirtualnych (np. pliki danych na Dysku D:, a WAL na Dysku E:), hiperwizor może nie wykonać migawki obu dysków w tej samej mikrosekundzie. Jeśli migawka dysku z WAL zostanie wykonana nawet ułamek sekundy po migawce dysku z danymi, baza danych nie będzie w stanie uzgodnić numerów sekwencyjnych podczas przywracania, co doprowadzi do fatalnego uszkodzenia.
Efekt „VM Stun” w systemach o dużej liczbie transakcji
Proces tworzenia migawki — a co ważniejsze, proces konsolidacji migawki — powoduje zjawisko znane jako „VM Stun” (zamrożenie maszyny wirtualnej).
Aby bezpiecznie przełączyć operacje I/O z dysku bazowego na dysk delta, hiperwizor musi na chwilę wstrzymać (zamrozić) maszynę wirtualną. W przypadku lekko obciążonego serwera WWW to zamrożenie może trwać 10-50 milisekund i pozostać niezauważone. Jednak w przypadku bazy danych o wysokiej przepustowości z ogromnym ruchem I/O, konsolidacja dużego dysku delta może zamrozić maszynę wirtualną na kilka sekund.
Podczas zamrożenia VM:
* Połączenia sieciowe są zrywane, co powoduje przekroczenie czasu oczekiwania aplikacji.
* Klastry wysokiej dostępności (takie jak SQL Server Always On, PostgreSQL Patroni czy MySQL Galera) tracą sygnały kontrolne (heartbeat).
* Klaster może uznać zamrożony węzeł za martwy, wyzwalając niepotrzebne i zakłócające pracę przełączenie awaryjne (scenariusz split-brain).
Poszarpane strony (Torn Pages) i niedopasowanie I/O
Silniki baz danych zazwyczaj zapisują dane w określonych rozmiarach stron (np. 8 KB dla PostgreSQL i SQL Server, 16 KB dla InnoDB). Jednak podstawowy system operacyjny i macierze pamięci masowej przetwarzają operacje I/O w mniejszych blokach (np. 4 KB lub 512 bajtów).
Jeśli hiperwizor wykona migawkę dokładnie w momencie, gdy baza danych zapisuje stronę 8 KB, migawka może uchwycić pierwsze 4 KB nowych danych i ostatnie 4 KB starych danych. Tworzy to tzw. poszarpaną stronę (torn page). Podczas próby przywrócenia migawki baza danych odczyta stronę, nie przejdzie walidacji sumy kontrolnej i oznaczy bazę danych jako uszkodzoną.
Rzeczywiste konsekwencje dla konkretnych silników baz danych
Różne silniki baz danych reagują na migawki spójne w przypadku awarii na różne sposoby, ale żaden z nich nie radzi sobie z tym dobrze w środowisku produkcyjnym.
- PostgreSQL: PostgreSQL w dużym stopniu polega na katalogu
pg_wal. Jeśli migawka uchwyci katalog danych ($PGDATA) i WAL w sposób niesynchronizowany, PostgreSQL nie uruchomi się, zgłaszając błądPANIC: could not locate a valid checkpoint record. - MySQL/InnoDB: InnoDB używa bufora doublewrite, aby zapobiegać poszarpanym stronom, co zapewnia pewną ochronę przed stanami spójnymi w przypadku awarii. Jeśli jednak plik
ibdata1iib_logfilezostaną uchwycone w sposób niesynchronizowany, silnik InnoDB ulegnie awarii podczas odzyskiwania. - Microsoft SQL Server: SQL Server jest bardzo wrażliwy na zamrażanie operacji I/O. Bez odpowiedniej integracji z VSS (Volume Shadow Copy Service), przywrócenie SQL Servera ze standardowej migawki VM często skutkuje bazami danych w stanie „suspect” i zerwanymi łańcuchami dzienników, co niszczy możliwości odzyskiwania do punktu w czasie (PITR).
Najlepsze praktyki bezpiecznego tworzenia kopii zapasowych zwirtualizowanych baz danych
Aby chronić bazy danych transakcyjnych, należy przejść od kopii zapasowych spójnych w przypadku awarii do kopii zapasowych spójnych z aplikacją. Wymaga to, aby mechanizm kopii zapasowej komunikował się z silnikiem bazy danych, zmuszając go do opróżnienia pamięci na dysk i chwilowego wstrzymania operacji I/O podczas wykonywania migawki.
1. Wykorzystaj mechanizmy quiescingu świadome aplikacji (VSS i fsfreeze)
Dla Windows (SQL Server):
Zawsze upewnij się, że Twoje rozwiązanie do tworzenia kopii zapasowych wykorzystuje usługę Microsoft Volume Shadow Copy Service (VSS). Gdy wyzwalana jest kopia zapasowa obsługująca VSS, SQL Server VSS Writer zamraża operacje I/O bazy danych, opróżnia oczekujące transakcje na dysk i zapewnia, że migawka jest w pełni spójna z aplikacją.
Dla Linux (PostgreSQL / MySQL):
Linux nie posiada natywnego odpowiednika VSS. Aby osiągnąć spójność aplikacji, należy użyć skryptów pre-freeze i post-thaw w połączeniu z narzędziami gościa hiperwizora (np. VMware Tools).
Oto przykład skryptu VMware pre-freeze-script dla PostgreSQL 15+, który bezpiecznie przygotowuje bazę danych do migawki:
#!/bin/bash
# /usr/sbin/pre-freeze-script
# Upewnij się, że ten skrypt jest wykonywalny (chmod +x)
# 1. Poinformuj PostgreSQL o przygotowaniu do kopii zapasowej
su - postgres -c "psql -c "SELECT pg_backup_start('vm_snapshot', true);""
# 2. Opróżnij bufory systemu plików na dysk
sync
# 3. Zamroź system plików (zakładając, że dane są w /var/lib/pgsql)
fsfreeze -f /var/lib/pgsql
Oraz odpowiadający mu post-thaw-script, aby wznowić operacje:
#!/bin/bash
# /usr/sbin/post-thaw-script
# 1. Odmroź system plików
fsfreeze -u /var/lib/pgsql
# 2. Poinformuj PostgreSQL, że kopia zapasowa została zakończona
su - postgres -c "psql -c "SELECT pg_backup_stop();""
2. Używaj natywnych narzędzi do tworzenia kopii zapasowych baz danych
Chociaż migawki spójne z aplikacją są lepsze niż standardowe migawki, nadal niosą ze sobą ryzyko zamrożenia VM (VM stun). Najbezpieczniejszym podejściem do tworzenia kopii zapasowych baz danych jest użycie natywnych, strumieniowych narzędzi do tworzenia kopii zapasowych, które działają niezależnie od hiperwizora.
PostgreSQL (pg_basebackup):
pg_basebackup -h localhost -U replication_user -D /mnt/backups/pg_backup -Ft -z -P
MySQL/MariaDB (Percona XtraBackup / Mariabackup):
Narzędzia te wykonują „gorące”, nieblokujące kopie zapasowe poprzez kopiowanie plików danych i jednoczesne śledzenie zmian w dzienniku redo.
mariabackup --backup --target-dir=/mnt/backups/mysql_backup --user=root --password=SecurePass
SQL Server (T-SQL):
BACKUP DATABASE [ProductionDB]
TO DISK = N'Z:BackupsProductionDB.bak'
WITH NOFORMAT, NOINIT, NAME = N'ProductionDB-Full Backup',
SKIP, NOREWIND, NOUNLOAD, COMPRESSION, STATS = 10;
GO
3. Wdróż odzyskiwanie do punktu w czasie (PITR) poprzez archiwizację dzienników
Codzienna migawka lub pełna kopia zapasowa chroni Cię tylko do momentu jej wykonania. Jeśli Twoja baza danych ulegnie awarii o 16:00, a ostatnia migawka była o 2:00 w nocy, tracisz 14 godzin danych transakcyjnych.
Aby osiągnąć prawdziwą odporność klasy korporacyjnej, musisz połączyć pełne kopie zapasowe spójne z aplikacją z ciągłą archiwizacją dzienników (tworzenie kopii zapasowych WAL, Redo Logs lub Transaction Logs co kilka minut). Pozwala to administratorom baz danych przywrócić bazę do konkretnej minuty, a nawet konkretnego identyfikatora transakcji przed wystąpieniem awarii.
Strategie tworzenia kopii zapasowych klasy korporacyjnej z CloudSave
Zarządzanie niestandardowymi skryptami pre-freeze, zadaniami cron dla natywnych zrzutów i przesyłaniem dzienników na dziesiątkach serwerów baz danych to koszmar operacyjny dla zespołów DevOps. W tym miejscu kluczowa staje się platforma klasy korporacyjnej, taka jak CloudSave.
CloudSave wypełnia lukę między wirtualizacją a architekturą baz danych. Zamiast polegać na „ślepych” migawkach hiperwizora, CloudSave wykorzystuje agentów świadomych aplikacji, którzy natywnie integrują się z SQL Server, PostgreSQL, MySQL i Oracle.
Kiedy CloudSave inicjuje kopię zapasową:
1. Komunikuje się bezpośrednio z silnikiem bazy danych za pomocą natywnych interfejsów API (takich jak VSS dla Windows lub natywne strumieniowanie WAL dla Linux).
2. Orkiestruje opróżnianie buforów pamięci na dysk bez powodowania zakłócających pracę zamrożeń VM.
3. Bezpiecznie przechwytuje pliki danych i automatycznie zarządza obcinaniem dzienników transakcji.
4. Ciągle tworzy kopie zapasowe dzienników transakcji, umożliwiając granularne odzyskiwanie do punktu w czasie (PITR) za pomocą kilku kliknięć.
Przenosząc złożoność zapewniania spójności aplikacji na CloudSave, administratorzy baz danych i systemów mogą zagwarantować integralność danych bez poświęcania wydajności lub dostępności swoich klastrów produkcyjnych.
Wniosek
Migawki maszyn wirtualnych są niesamowitym narzędziem do zarządzania infrastrukturą, ale są fundamentalnie niekompatybilne z wymaganiami ACID baz danych transakcyjnych. Poleganie na migawkach hiperwizora spójnych w przypadku awarii naraża organizację na poszarpane strony, zerwane łańcuchy replikacji i katastrofalną utratę danych.
Aby chronić swoje krytyczne dane, musisz wdrożyć quiescing świadomy aplikacji, stosować natywne metodologie tworzenia kopii zapasowych baz danych i utrzymywać ciągłe archiwa dzienników transakcji. Przyjmując dedykowane rozwiązania do tworzenia kopii zapasowych klasy korporacyjnej, możesz zapewnić, że Twoje bazy danych pozostaną wysoce dostępne, w pełni odzyskiwalne i całkowicie bezpieczne.
