Za DevOps inženjere i sistemske administratore, snimci virtuelnih mašina (VM snapshots) su osnovni alat. Oni pružaju brz i praktičan način za snimanje stanja servera prije rizičnog ažuriranja, velike promjene konfiguracije ili implementacije aplikacije. Ako nešto krene po zlu, vraćanje na prethodno stanje traje nekoliko sekundi.
Međutim, kada se ista metodologija primijeni na transakcione baze podataka—kao što su PostgreSQL, MySQL, Oracle ili Microsoft SQL Server—snimci virtuelnih mašina se pretvaraju iz sigurnosne mreže u tempiranu bombu.
Oslanjanje na standardne hipervizorske snimke za pravljenje rezervnih kopija baza podataka jedan je od najčešćih uzroka oštećenja podataka, “pocijepanih” stranica (torn pages) i nepopravljivih prekida u radu produkcionih sistema. U ovom članku ćemo istražiti arhitektonski sukob između hipervizora i mehanizama baza podataka, mehaniku oštećenja podataka tokom snimanja i inženjerske najbolje prakse potrebne za sigurno pravljenje rezervnih kopija virtuelizovanih baza podataka.
Arhitektonski sukob: Hipervizori protiv mehanizama baza podataka
Da bismo razumjeli zašto snimci virtuelnih mašina ugrožavaju baze podataka, prvo moramo ispitati kako oba sistema upravljaju stanjem i I/O operacijama.
Kako hipervizori izvršavaju snimke
Kada hipervizor (kao što je VMware ESXi, Microsoft Hyper-V ili KVM) napravi snimak, on ne kopira disk. Umjesto toga, on zamrzava trenutnu datoteku virtuelnog diska (npr. .vmdk ili .vhdx) u stanje samo za čitanje i kreira novi delta disk (disk za razlike). Sva naknadna pisanja se usmjeravaju na ovaj delta disk.
Kada se snimak izbriše, hipervizor mora da potvrdi (konsoliduje) podatke sa delta diska nazad u osnovni disk. Standardni snimci su potpuno nesvjesni aplikacija koje rade unutar gostujućeg operativnog sistema. Oni snimaju stanje diska tačno onako kako postoji u toj mikrosekundi.
Kako transakcione baze podataka upravljaju stanjem
Transakcione baze podataka su dizajnirane oko ACID svojstava (Atomicity, Consistency, Isolation, Durability – atomičnost, konzistentnost, izolacija, trajnost). Da bi postigle visoke performanse uz održavanje ACID usklađenosti, baze podataka ne zapisuju svaku transakciju direktno u primarne datoteke podataka na disku odmah. Umjesto toga, koriste složenu arhitekturu na više nivoa:
- Buffer Pool / Shared Buffers: Podaci se čitaju i modifikuju unutar sistemske memorije.
- Write-Ahead Log (WAL) / Redo Logs: Promjene se sekvencijalno zapisuju u visoko optimizovanu datoteku dnevnika na disku kako bi se osigurala trajnost.
- Checkpoints / Lazy Writers: Periodično, baza podataka ispire modifikovane (prljave) stranice iz memorije u stvarne datoteke podataka na disku.
Zbog ove arhitekture, fizičke datoteke podataka na disku su gotovo uvijek nesinhronizovane sa stvarnim stanjem baze podataka. Pravo stanje baze podataka postoji samo kao kombinacija datoteka podataka na disku, WAL/Redo dnevnika i podataka koji se trenutno nalaze u memoriji.
Zona opasnosti: Šta se dešava tokom snimka virtuelne mašine
Kada napravite standardni snimak virtuelne mašine servera baze podataka, snimate stanje koje je konzistentno u slučaju pada (crash-consistent).
Konzistentnost u slučaju pada naspram konzistentnosti aplikacije
Snimak konzistentan u slučaju pada je ekvivalentan izvlačenju kabla za napajanje iz fizičkog servera. Stanje diska je snimljeno, ali sve što je bilo u memoriji je izgubljeno, a sve što je bilo na putu ka kontroleru skladištenja je naglo prekinuto.
Iako su moderne baze podataka dizajnirane da se oporave od neočekivanog gubitka napajanja ponovnim pokretanjem Write-Ahead dnevnika, oslanjanje na oporavak od pada kao primarnu strategiju rezervnih kopija je veoma opasno. Ako vaša baza podataka obuhvata više virtuelnih diskova (npr. datoteke podataka na Drive D: i WAL na Drive E:), hipervizor možda neće snimiti oba diska u istoj mikrosekundi. Ako se snimak WAL diska napravi čak i djelić sekunde nakon snimka diska sa podacima, baza podataka ne može uskladiti sekvencijalne brojeve prilikom vraćanja, što rezultira fatalnim oštećenjem.
Efekat “VM Stun” na sisteme sa visokim brojem transakcija
Proces kreiranja snimka—i što je još važnije, proces konsolidacije snimka—uzrokuje fenomen poznat kao “VM Stun” (zamrzavanje virtuelne mašine).
Da bi bezbjedno prebacio I/O sa osnovnog diska na delta disk, hipervizor mora nakratko pauzirati (zamrznuti) virtuelnu mašinu. Za web server sa malim opterećenjem, ovo zamrzavanje može trajati 10-50 milisekundi i proći neprimijećeno. Međutim, za bazu podataka sa visokim protokom i masivnim I/O, konsolidacija velikog delta diska može zamrznuti virtuelnu mašinu na nekoliko sekundi.
Tokom zamrzavanja virtuelne mašine:
* Mrežne veze pucaju, uzrokujući vremenska ograničenja (timeouts) aplikacija.
* Klasteri visoke dostupnosti (kao što su SQL Server Always On, PostgreSQL Patroni ili MySQL Galera) propuštaju provjere “otkucaja srca” (heartbeat).
* Klaster može pretpostaviti da je zamrznuti čvor mrtav, pokrećući nepotreban i ometajući prelazak na rezervni sistem (scenario podijeljenog mozga – split-brain).
Pocijepane stranice i I/O neusklađenost
Mehanizmi baza podataka obično zapisuju podatke u određenim veličinama stranica (npr. 8KB za PostgreSQL i SQL Server, 16KB za InnoDB). Međutim, osnovni operativni sistem i nizovi za skladištenje obrađuju I/O u manjim blokovima (npr. 4KB ili 512 bajtova).
Ako hipervizor napravi snimak tačno dok baza podataka zapisuje stranicu od 8KB, snimak može uhvatiti prvih 4KB novih podataka i posljednjih 4KB starih podataka. Ovo stvara pocijepanu stranicu (torn page). Kada pokušate da vratite snimak, baza podataka će pročitati stranicu, neće proći validaciju kontrolne sume i označiće bazu podataka kao oštećenu.
Posljedice u stvarnom svijetu za specifične mehanizme baza podataka
Različiti mehanizmi baza podataka reaguju na snimke konzistentne u slučaju pada na različite načine, ali nijedan od njih to ne podnosi elegantno u produkcionom okruženju.
- PostgreSQL: PostgreSQL se u velikoj mjeri oslanja na
pg_waldirektorijum. Ako snimak uhvati direktorijum sa podacima ($PGDATA) i WAL nesinhronizovano, PostgreSQL se neće pokrenuti, izbacujući greškuPANIC: could not locate a valid checkpoint record. - MySQL/InnoDB: InnoDB koristi bafer za dvostruko pisanje (doublewrite buffer) kako bi spriječio pocijepane stranice, što nudi određenu zaštitu od stanja konzistentnih u slučaju pada. Međutim, ako su datoteka
ibdata1iib_logfilesnimljene nesinhronizovano, InnoDB mehanizam će se srušiti prilikom oporavka. - Microsoft SQL Server: SQL Server je veoma osjetljiv na zamrzavanje I/O operacija. Bez pravilne VSS (Volume Shadow Copy Service) integracije, vraćanje SQL Servera iz standardnog snimka virtuelne mašine često će rezultirati sumnjivim bazama podataka i prekinutim lancima dnevnika, uništavajući vaše mogućnosti oporavka do određene tačke u vremenu (PITR).
Najbolje prakse za sigurno pravljenje rezervnih kopija virtuelizovanih baza podataka
Da biste zaštitili transakcione baze podataka, morate preći sa rezervnih kopija konzistentnih u slučaju pada na rezervne kopije konzistentne sa aplikacijom. Ovo zahtijeva da mehanizam za pravljenje rezervnih kopija komunicira sa mehanizmom baze podataka, prisiljavajući ga da ispere memoriju na disk i privremeno pauzira I/O operacije dok se snimak pravi.
1. Iskoristite “Application-Aware Quiescing” (VSS i fsfreeze)
Za Windows (SQL Server):
Uvijek osigurajte da vaše rješenje za rezervne kopije koristi Microsoft Volume Shadow Copy Service (VSS). Kada se pokrene rezervna kopija svjesna VSS-a, SQL Server VSS Writer zamrzava I/O baze podataka, ispire transakcije na čekanju na disk i osigurava da je snimak savršeno konzistentan sa aplikacijom.
Za Linux (PostgreSQL / MySQL):
Linux nema izvorni ekvivalent VSS-u. Da biste postigli konzistentnost aplikacije, morate koristiti skripte za zamrzavanje prije (pre-freeze) i odmrzavanje poslije (post-thaw) u kombinaciji sa alatima za goste hipervizora (npr. VMware Tools).
Evo primjera VMware pre-freeze-script za PostgreSQL 15+ koji bezbjedno priprema bazu podataka za snimak:
#!/bin/bash
# /usr/sbin/pre-freeze-script
# Osigurajte da je ova skripta izvršna (chmod +x)
# 1. Recite PostgreSQL-u da se pripremi za rezervnu kopiju
su - postgres -c "psql -c "SELECT pg_backup_start('vm_snapshot', true);""
# 2. Ispirite bafer sistema datoteka na disk
sync
# 3. Zamrznite sistem datoteka (pod pretpostavkom da su podaci na /var/lib/pgsql)
fsfreeze -f /var/lib/pgsql
I odgovarajuća post-thaw-script za nastavak operacija:
#!/bin/bash
# /usr/sbin/post-thaw-script
# 1. Odmrznite sistem datoteka
fsfreeze -u /var/lib/pgsql
# 2. Recite PostgreSQL-u da je rezervna kopija završena
su - postgres -c "psql -c "SELECT pg_backup_stop();""
2. Koristite izvorne uslužne programe za rezervne kopije baza podataka
Iako su snimci konzistentni sa aplikacijom bolji od standardnih snimaka, oni i dalje nose rizik od zamrzavanja virtuelne mašine. Najsigurniji pristup za rezervne kopije baza podataka je korištenje izvornih, striming uslužnih programa za rezervne kopije koji rade nezavisno od hipervizora.
PostgreSQL (pg_basebackup):
pg_basebackup -h localhost -U replication_user -D /mnt/backups/pg_backup -Ft -z -P
MySQL/MariaDB (Percona XtraBackup / Mariabackup):
Ovi alati prave “vruće”, neblokirajuće rezervne kopije kopiranjem datoteka podataka i istovremenim praćenjem promjena u redo dnevniku.
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. Implementirajte oporavak do određene tačke u vremenu (PITR) putem arhiviranja dnevnika
Dnevni snimak ili potpuna rezervna kopija vas štiti samo do trenutka kada je napravljena. Ako se vaša baza podataka sruši u 16:00, a vaš posljednji snimak je bio u 02:00, gubite 14 sati transakcionih podataka.
Da biste postigli istinsku otpornost na nivou preduzeća, morate kombinovati potpune rezervne kopije konzistentne sa aplikacijom sa kontinuiranim arhiviranjem dnevnika (pravljenje rezervnih kopija WAL-a, Redo dnevnika ili transakcionih dnevnika svakih nekoliko minuta). Ovo omogućava administratorima baza podataka da vrate bazu podataka na određeni minut ili čak određeni ID transakcije prije katastrofe.
Strategije rezervnih kopija za preduzeća sa CloudSave-om
Upravljanje prilagođenim skriptama za zamrzavanje, cron poslovima za izvorne dumpove i slanjem dnevnika na desetine servera baza podataka je operativna noćna mora za DevOps timove. Ovdje platforma poslovnog nivoa kao što je CloudSave postaje kritična.
CloudSave premošćuje jaz između virtuelizacije i arhitekture baza podataka. Umjesto oslanjanja na “slijepe” snimke hipervizora, CloudSave koristi agente svjesne aplikacija koji se izvorno integrišu sa SQL Serverom, PostgreSQL-om, MySQL-om i Oracle-om.
Kada CloudSave pokrene rezervnu kopiju:
1. Komunicira direktno sa mehanizmom baze podataka putem izvornih API-ja (kao što je VSS za Windows ili izvorno WAL strimovanje za Linux).
2. Orkestrira ispiranje memorijskih bafera na disk bez izazivanja ometajućih zamrzavanja virtuelne mašine.
3. Bezbjedno snima datoteke podataka i automatski upravlja skraćivanjem transakcionih dnevnika.
4. Kontinuirano pravi rezervne kopije transakcionih dnevnika, omogućavajući granularni oporavak do određene tačke u vremenu (PITR) sa nekoliko klikova.
Prebacivanjem složenosti konzistentnosti aplikacije na CloudSave, administratori baza podataka i sistemski administratori mogu garantovati integritet podataka bez žrtvovanja performansi ili dostupnosti svojih produkcionih klastera.
Zaključak
Snimci virtuelnih mašina su nevjerovatan alat za upravljanje infrastrukturom, ali su fundamentalno nekompatibilni sa ACID zahtjevima transakcionih baza podataka. Oslanjanje na snimke hipervizora konzistentne u slučaju pada izlaže vašu organizaciju pocijepanim stranicama, prekinutim lancima replikacije i katastrofalnom gubitku podataka.
Da biste zaštitili svoje kritične podatke, morate implementirati “application-aware” zamrzavanje, koristiti izvorne metodologije za pravljenje rezervnih kopija baza podataka i održavati kontinuirane arhive transakcionih dnevnika. Usvajanjem namjenskih rješenja za rezervne kopije za preduzeća, možete osigurati da vaše baze podataka ostanu visoko dostupne, potpuno oporavljive i potpuno sigurne.
