Miks VM-i hetktõmmised ei ole tehingupõhiste andmebaaside jaoks ohutud: DBA juhend andmete terviklikkuse tagamiseks

DevOps-inseneride ja süsteemiadministraatorite jaoks on virtuaalmasinate (VM) hetktõmmised (snapshotid) fundamentaalne tööriist. Need pakuvad kiiret ja mugavat viisi serveri oleku jäädvustamiseks enne riskantset paigaldust, suurt konfiguratsioonimuudatust või rakenduse juurutamist. Kui midagi läheb valesti, võtab taastamine aega vaid sekundeid.

Kuid kui sama metoodikat rakendatakse tehingupõhistele andmebaasidele – nagu PostgreSQL, MySQL, Oracle või Microsoft SQL Server –, muutuvad VM-i hetktõmmised turvavõrgust tiksuvaks pommiks.

Tuginemine tavalistele hüperviisori hetktõmmistele andmebaaside varundamisel on üks levinumaid andmete rikkumise, lehekülgede purunemise (torn pages) ja taastamatute tootmiskatkestuste põhjuseid. Selles artiklis uurime arhitektuurilist konflikti hüperviisorite ja andmebaasimootorite vahel, andmete rikkumise mehhanisme hetktõmmiste ajal ning insenertehnilisi parimaid tavasid, mis on vajalikud virtualiseeritud andmebaaside turvaliseks varundamiseks.

Arhitektuuriline konflikt: hüperviisorid vs. andmebaasimootorid

Et mõista, miks VM-i hetktõmmised andmebaase ohustavad, peame esmalt uurima, kuidas mõlemad süsteemid haldavad olekut ja I/O-operatsioone.

Kuidas hüperviisorid hetktõmmiseid teostavad

Kui hüperviisor (näiteks VMware ESXi, Microsoft Hyper-V või KVM) teeb hetktõmmise, ei kopeeri see ketast. Selle asemel külmutab see praeguse virtuaalketta faili (nt .vmdk või .vhdx) kirjutuskaitstud olekusse ja loob uue delta-ketta (erinevuste ketas). Kõik järgnevad kirjutamised suunatakse sellele delta-kettale.

Kui hetktõmmis kustutatakse, peab hüperviisor delta-kettal olevad andmed põhikettale tagasi kandma (konsolideerima). Tavalised hetktõmmised ei ole teadlikud külalisoperatsioonisüsteemis töötavatest rakendustest. Nad jäädvustavad ketta oleku täpselt sellisena, nagu see sel mikrosekundil eksisteerib.

Kuidas tehingupõhised andmebaasid olekut haldavad

Tehingupõhised andmebaasid on loodud ACID-omaduste (aatomilisus, järjepidevus, isolatsioon, vastupidavus) ümber. Kõrge jõudluse saavutamiseks ACID-i järgimise ajal ei kirjuta andmebaasid iga tehingut kohe otse kettal olevatesse peamistesse andmefailidesse. Selle asemel kasutavad nad keerukat mitmetasandilist arhitektuuri:

1. Puhverbassein / Jagatud puhvrid (Buffer Pool / Shared Buffers): Andmed loetakse süsteemi mällu ja neid muudetakse seal.
2. Write-Ahead Log (WAL) / Redo-logid: Muudatused kirjutatakse järjestikku kettal asuvasse optimeeritud logifaili, et tagada vastupidavus.
3. Kontrollpunktid / Lazy Writers: Perioodiliselt kirjutab andmebaas muudetud (mustad) leheküljed mälust kettal olevatesse tegelikesse andmefailidesse.

Selle arhitektuuri tõttu on kettal olevad füüsilised andmefailid peaaegu alati andmebaasi tegeliku olekuga sünkroonist väljas. Andmebaasi tõeline olek eksisteerib vaid kettal olevate andmefailide, WAL/Redo-logide ja hetkel mälus asuvate andmete kombinatsioonina.

Ohutsoon: mis juhtub VM-i hetktõmmise ajal

Kui teete andmebaasiserverist tavalise VM-i hetktõmmise, jäädvustate krahhi-järjepideva (crash-consistent) oleku.

Krahhi-järjepidevus vs. rakenduse-järjepidevus

Krahhi-järjepidev hetktõmmis on võrdväärne toitejuhtme füüsilisest serverist välja tõmbamisega. Ketta olek jäädvustatakse, kuid kõik mälus olnud andmed lähevad kaotsi ja kõik, mis oli poolel teel salvestuskontrollerisse, katkestatakse järsult.

Kuigi kaasaegsed andmebaasid on loodud ootamatust voolukatkestusest taastuma Write-Ahead Logi taasesitamise teel, on krahhitaastumisele tuginemine peamise varundusstrateegiana äärmiselt ohtlik. Kui teie andmebaas ulatub üle mitme virtuaalketta (nt andmefailid Draivil D: ja WAL Draivil E:), ei pruugi hüperviisor mõlemat ketast täpselt samal mikrosekundil jäädvustada. Kui WAL-ketta hetktõmmis jäädvustatakse kasvõi murdosa sekundist pärast andmeketta hetktõmmist, ei suuda andmebaas taastamisel järjestusnumbreid kokku viia, mis viib fataalse riknemiseni.

„VM Stun“ efekt suure tehingumahuga süsteemides

Hetktõmmise loomise protsess – ja mis veelgi olulisem, hetktõmmise konsolideerimise protsess – põhjustab nähtuse nimega „VM Stun“ (virtuaalmasina uimastamine).

I/O ohutuks suunamiseks põhikettalt delta-kettale peab hüperviisor virtuaalmasina korraks peatama (stun). Väikese koormusega veebiserveri puhul võib see kesta 10–50 millisekundit ja jääda märkamatuks. Kuid suure I/O-mahuga andmebaasi puhul võib suure delta-ketta konsolideerimine virtuaalmasinat mitmeks sekundiks peatada.

VM-i peatamise ajal:
* Võrguühendused katkevad, põhjustades rakenduste ajalõppe.
* Kõrge kättesaadavusega klastrid (nagu SQL Server Always On, PostgreSQL Patroni või MySQL Galera) jätavad südamelöökide kontrollid (heartbeat checks) vahele.
* Klaster võib eeldada, et peatatud sõlm on surnud, käivitades tarbetu ja häiriva failoveri (split-brain stsenaarium).

Purunenud leheküljed ja I/O ebaühtlus

Andmebaasimootorid kirjutavad andmeid tavaliselt kindla suurusega lehekülgedena (nt 8 KB PostgreSQL-i ja SQL Serveri puhul, 16 KB InnoDB puhul). Kuid aluseks olev operatsioonisüsteem ja salvestusmassiivid töötlevad I/O-d väiksemate plokkidena (nt 4 KB või 512 baiti).

Kui hüperviisor teeb hetktõmmise täpselt siis, kui andmebaas kirjutab 8 KB lehekülge, võib hetktõmmis jäädvustada uute andmete esimesed 4 KB ja vanade andmete viimased 4 KB. See tekitab purunenud lehekülje (torn page). Kui proovite hetktõmmist taastada, loeb andmebaas lehekülge, kontrollsumma valideerimine ebaõnnestub ja andmebaas märgitakse rikutuks.

Tegelikud tagajärjed konkreetsetele andmebaasimootoritele

Erinevad andmebaasimootorid reageerivad krahhi-järjepidevatele hetktõmmistele erinevalt, kuid ükski neist ei käsitle seda tootmiskeskkonnas sujuvalt.

• PostgreSQL: PostgreSQL toetub suuresti pg_wal kataloogile. Kui hetktõmmis jäädvustab andmekataloogi ($PGDATA) ja WAL-i sünkroonist väljas, ei käivitu PostgreSQL, visates vea PANIC: could not locate a valid checkpoint record.
• MySQL/InnoDB: InnoDB kasutab purunenud lehekülgede vältimiseks topeltkirjutamise puhvrit (doublewrite buffer), mis pakub teatud kaitset krahhi-järjepidevate olekute eest. Kui aga ibdata1 fail ja ib_logfile jäädvustatakse sünkroonist väljas, jookseb InnoDB mootor taastamisel kokku.
• Microsoft SQL Server: SQL Server on I/O külmutamise suhtes väga tundlik. Ilma korraliku VSS (Volume Shadow Copy Service) integratsioonita põhjustab SQL Serveri taastamine tavalisest VM-i hetktõmmisest sageli andmebaaside kahtlaseks muutumist ja logiahelate katkemist, hävitades teie Point-in-Time Recovery (PITR) võimalused.

Parimad tavad virtualiseeritud andmebaaside turvaliseks varundamiseks

Tehingupõhiste andmebaaside kaitsmiseks peate liikuma krahhi-järjepidevatelt varukoopiatelt rakenduse-järjepidevatele (application-consistent) varukoopiatele. See nõuab, et varundusmehhanism suhtleks andmebaasimootoriga, sundides seda mälu kettale kirjutama ja I/O-operatsioone hetkeks peatama, kuni hetktõmmis tehakse.

1. Kasutage rakendusteadlikku külmutamist (VSS ja fsfreeze)

Windowsi jaoks (SQL Server):
Veenduge alati, et teie varunduslahendus kasutab Microsoft Volume Shadow Copy Service’i (VSS). Kui käivitatakse VSS-teadlik varundus, külmutab SQL Server VSS Writer andmebaasi I/O, kirjutab ootel tehingud kettale ja tagab, et hetktõmmis on täielikult rakenduse-järjepidev.

Linuxi jaoks (PostgreSQL / MySQL):
Linuxil pole VSS-ile otsest vastet. Rakenduse-järjepidevuse saavutamiseks peate kasutama pre-freeze ja post-thaw skripte koos hüperviisori külalistööriistadega (nt VMware Tools).

Siin on näide VMware pre-freeze-script skriptist PostgreSQL 15+ jaoks, mis valmistab andmebaasi turvaliselt ette hetktõmmiseks:

#!/bin/bash
# /usr/sbin/pre-freeze-script
# Veenduge, et see skript on käivitatav (chmod +x)

# 1. Käskige PostgreSQL-il varunduseks valmistuda
su - postgres -c "psql -c "SELECT pg_backup_start('vm_snapshot', true);""

# 2. Kirjutage failisüsteemi puhvrid kettale
sync

# 3. Külmutage failisüsteem (eeldades, et andmed on /var/lib/pgsql)
fsfreeze -f /var/lib/pgsql

Ja vastav post-thaw-script toimingute jätkamiseks:

#!/bin/bash
# /usr/sbin/post-thaw-script

# 1. Vabastage failisüsteem
fsfreeze -u /var/lib/pgsql

# 2. Teavitage PostgreSQL-i, et varundus on lõpetatud
su - postgres -c "psql -c "SELECT pg_backup_stop();""

2. Kasutage andmebaasi natiivseid varundustööriistu

Kuigi rakenduse-järjepidevad hetktõmmised on paremad kui tavalised, kaasneb nendega endiselt VM-i peatamise oht. Kõige turvalisem lähenemine andmebaaside varundamiseks on kasutada natiivseid voogedastus-varundustööriistu, mis töötavad hüperviisorist sõltumatult.

PostgreSQL (pg_basebackup):

pg_basebackup -h localhost -U replication_user -D /mnt/backups/pg_backup -Ft -z -P

MySQL/MariaDB (Percona XtraBackup / Mariabackup):
Need tööriistad teevad “kuumi”, blokeerimata varukoopiaid, kopeerides andmefailid ja jälgides samal ajal muudatusi redo-logis.

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. Rakendage Point-in-Time Recovery (PITR) logide arhiveerimise kaudu

Igapäevane hetktõmmis või täisvarukoopia kaitseb teid ainult kuni selle tegemise hetkeni. Kui teie andmebaas jookseb kokku kell 16:00 ja teie viimane hetktõmmis oli kell 02:00, kaotate 14 tunni jagu tehinguandmeid.

Tõelise ettevõtte tasemel vastupidavuse saavutamiseks peate kombineerima täielikud rakenduse-järjepidevad varukoopiad pideva logide arhiveerimisega (WAL, Redo-logide või tehingulogide varundamine iga paari minuti järel). See võimaldab andmebaasiadministraatoritel taastada andmebaasi konkreetse minutini või isegi konkreetse tehingu ID-ni enne katastroofi.

Ettevõtte varundusstrateegiad koos CloudSave’iga

Kohandatud pre-freeze skriptide, natiivsete dumpide cron-tööde ja logide saatmise haldamine kümnetes andmebaasiserverites on DevOps-meeskondade jaoks operatiivne õudusunenägu. Siin muutub kriitiliseks ettevõtte tasemel platvorm nagu CloudSave.

CloudSave ületab lõhe virtualiseerimise ja andmebaasi arhitektuuri vahel. Selle asemel, et loota pimesi hüperviisori hetktõmmistele, kasutab CloudSave rakendusteadlikke agente, mis integreeruvad natiivselt SQL Serveri, PostgreSQL-i, MySQL-i ja Oracle’iga.

Kui CloudSave algatab varunduse:
1. Suhtleb see otse andmebaasimootoriga natiivsete API-de kaudu (nagu VSS Windowsi jaoks või natiivne WAL-voogedastus Linuxi jaoks).
2. See orkestreerib mälupuhvrite kirjutamist kettale, põhjustamata häirivaid VM-i peatamisi.
3. See jäädvustab turvaliselt andmefailid ja haldab automaatselt tehingulogide kärpimist.
4. See varundab pidevalt tehinguloge, võimaldades mõne klikiga täpset Point-in-Time Recovery (PITR) taastamist.

Andes rakenduse-järjepidevuse keerukuse üle CloudSave’ile, saavad andmebaasiadministraatorid ja süsteemiadministraatorid tagada andmete terviklikkuse, ohverdamata oma tootmisklastrite jõudlust või kättesaadavust.

Kokkuvõte

Virtuaalmasinate hetktõmmised on infrastruktuuri haldamiseks suurepärane tööriist, kuid need on fundamentaalselt kokkusobimatud tehingupõhiste andmebaaside ACID-nõuetega. Krahhi-järjepidevatele hüperviisori hetktõmmistele tuginemine jätab teie organisatsiooni avatuks purunenud lehekülgedele, katkenud replikatsiooniahelatele ja katastroofilisele andmekaole.

Oma missioonikriitiliste andmete kaitsmiseks peate rakendama rakendusteadlikku külmutamist, kasutama natiivseid andmebaasi varundusmetoodikaid ja säilitama pidevaid tehingulogide arhiive. Võttes kasutusele spetsiaalselt loodud ettevõtte varunduslahendused, saate tagada, et teie andmebaasid jäävad kõrge kättesaadavusega, täielikult taastatavateks ja täiesti turvalisteks.