Fyrir DevOps-verkfræðinga og kerfisstjóra eru skyndimyndir (snapshots) af sýndarvélum (VM) grundvallartæki. Þær bjóða upp á skjóta og þægilega leið til að fanga ástand netþjóns fyrir áhættusamar uppfærslur, stórar breytingar á stillingum eða uppsetningu forrita. Ef eitthvað fer úrskeiðis tekur aðeins nokkrar sekúndur að snúa breytingum við.
Hins vegar, þegar þessi sama aðferðafræði er notuð á gagnagrunna sem byggja á færslum (transactional databases) — svo sem PostgreSQL, MySQL, Oracle eða Microsoft SQL Server — breytast skyndimyndir sýndarvéla úr öryggisneti í tímasprengju.
Að treysta á staðlaðar skyndimyndir frá sýndarvélastýrikerfum (hypervisors) fyrir afritun gagnagrunna er ein algengasta orsök gagnaeyðileggingar, „rifinna síðna“ (torn pages) og óbætanlegra truflana í framleiðsluumhverfi. Í þessari grein munum við skoða áreksturinn í arkitektúr milli sýndarvélastýrikerfa og gagnagrunnsvéla, hvernig gagnaeyðilegging á sér stað við skyndimyndatöku og bestu verkfræðilegu starfsvenjur sem þarf til að taka örugg afrit af sýndum gagnagrunnum.
Árekstur arkitektúra: Sýndarvélastýrikerfi vs. gagnagrunnsvélar
Til að skilja hvers vegna skyndimyndir sýndarvéla ógna gagnagrunnum verðum við fyrst að skoða hvernig bæði kerfin stýra ástandi og I/O-aðgerðum.
Hvernig sýndarvélastýrikerfi framkvæma skyndimyndir
Þegar sýndarvélastýrikerfi (eins og VMware ESXi, Microsoft Hyper-V eða KVM) tekur skyndimynd, afritar það ekki diskinn. Í staðinn frystir það núverandi sýndardiskaskrá (t.d. .vmdk eða .vhdx) í skrifvarð ástand og býr til nýjan mismunadisk (delta disk). Allar síðari skrifaðgerðir eru beint á þennan mismunadisk.
Þegar skyndimyndinni er eytt verður sýndarvélastýrikerfið að sameina (consolidate) gögnin úr mismunadisknum aftur inn í grunndiskinn. Staðlaðar skyndimyndir hafa enga vitneskju um þau forrit sem keyra inni í gestastýrikerfinu. Þær fanga ástand disksins nákvæmlega eins og það er á því örsekúndubroti.
Hvernig gagnagrunnar stýra ástandi
Gagnagrunnar sem byggja á færslum eru hannaðir í kringum ACID-eiginleika (Atomicity, Consistency, Isolation, Durability). Til að ná miklum afköstum á meðan ACID-samræmi er viðhaldið, skrifa gagnagrunnar ekki hverja færslu beint í aðalgagnaskrárnar á disknum strax. Í staðinn nota þeir flókinn, fjöllaga arkitektúr:
- Buffer Pool / Shared Buffers: Gögn eru lesin inn í og breytt í vinnsluminni kerfisins.
- Write-Ahead Log (WAL) / Redo Logs: Breytingar eru skrifaðar í röð í mjög fínstillta annálaskrá á disknum til að tryggja varanleika.
- Checkpoints / Lazy Writers: Með reglulegu millibili skolar gagnagrunnurinn breyttum síðum úr vinnsluminni yfir í raunverulegar gagnaskrár á disknum.
Vegna þessa arkitektúrs eru líkamlegar gagnaskrár á disknum næstum alltaf úr takti við raunverulegt ástand gagnagrunnsins. Sanna ástand gagnagrunnsins er aðeins til sem samsetning af gagnaskrám á disknum, WAL/Redo-annálum og þeim gögnum sem eru í vinnsluminni hverju sinni.
Hættusvæðið: Hvað gerist við skyndimyndatöku sýndarvélar
Þegar þú tekur staðlaða skyndimynd af gagnagrunnsþjóni ertu að fanga ástand sem er „crash-consistent“ (samræmt við kerfishrun).
Samræmi við kerfishrun vs. samræmi við forrit
Skyndimynd sem er „crash-consistent“ jafngildir því að kippa rafmagnssnúrunni úr líkamlega þjóninum. Ástand disksins er fangað, en allt sem var í vinnsluminni glatast og allt sem var á leiðinni í geymslustýringuna er skyndilega rofið.
Þótt nútíma gagnagrunnar séu hannaðir til að jafna sig eftir óvænt rafmagnsleysi með því að spila Write-Ahead Log-annálana aftur, er mjög hættulegt að treysta á það sem aðal-afritunarstefnu. Ef gagnagrunnurinn þinn spannar marga sýndardiska (t.d. gagnaskrár á Drifi D: og WAL á Drifi E:), gæti sýndarvélastýrikerfið ekki tekið skyndimynd af báðum diskum á nákvæmlega sömu örsekúndu. Ef skyndimynd WAL-disksins er tekin jafnvel broti úr sekúndu á eftir skyndimynd gagnadisksins, getur gagnagrunnurinn ekki samræmt raðnúmerin við endurheimt, sem leiðir til banvænnar gagnaspillingar.
„VM Stun“-áhrifin á kerfi með mikla umferð
Ferlið við að búa til skyndimynd — og enn mikilvægara, ferlið við að sameina hana — veldur fyrirbæri sem kallast „VM Stun“ (frysting sýndarvélar).
Til að skipta I/O-umferð á öruggan hátt frá grunndiski yfir á mismunadisk verður sýndarvélastýrikerfið að gera stutt hlé (frysta) á sýndarvélinni. Fyrir létt hlaðinn vefþjón gæti þessi frysting varað í 10-50 millisekúndur og farið fram hjá notendum. Hins vegar, fyrir gagnagrunn með mikla umferð og gríðarlegt I/O-álag, getur sameining stórs mismunadisks fryst sýndarvélina í nokkrar sekúndur.
Meðan á frystingu stendur:
* Nettengingar rofna, sem veldur tímamörkum (timeouts) í forritum.
* Hátiltæk klasakerfi (eins og SQL Server Always On, PostgreSQL Patroni eða MySQL Galera) missa af hjartsláttarathugunum.
* Klasinn gæti haldið að frysti hnúturinn sé dauður, sem kallar fram óþarfa og truflandi yfirfærslu (failover) (split-brain atburðarás).
Rifnar síður (Torn Pages) og I/O-misræmi
Gagnagrunnsvélar skrifa venjulega gögn í ákveðnum síðustærðum (t.d. 8KB fyrir PostgreSQL og SQL Server, 16KB fyrir InnoDB). Hins vegar vinnur undirliggjandi stýrikerfi og geymslukerfi úr I/O í minni einingum (t.d. 4KB eða 512 bæti).
Ef sýndarvélastýrikerfi tekur skyndimynd nákvæmlega á meðan gagnagrunnurinn er að skrifa 8KB síðu, gæti skyndimyndin fangað fyrstu 4KB af nýju gögnunum og síðustu 4KB af gömlu gögnunum. Þetta skapar rifna síðu. Þegar þú reynir að endurheimta skyndimyndina mun gagnagrunnurinn lesa síðuna, mistakast við staðfestingu á eftirlitssummu (checksum) og merkja gagnagrunninn sem skemmdan.
Raunverulegar afleiðingar fyrir tilteknar gagnagrunnsvélar
Mismunandi gagnagrunnsvélar bregðast við „crash-consistent“ skyndimyndum á ýmsa vegu, en engin þeirra höndlar það vel í framleiðsluumhverfi.
- PostgreSQL: PostgreSQL reiðir sig mikið á
pg_walmöppuna. Ef skyndimynd fangar gagnamöppuna ($PGDATA) og WAL-annálana úr takti, mun PostgreSQL ekki ræsast og kasta villunniPANIC: could not locate a valid checkpoint record. - MySQL/InnoDB: InnoDB notar tvöfaldan skrif-biðminni (doublewrite buffer) til að koma í veg fyrir rifnar síður, sem býður upp á einhverja vörn gegn „crash-consistent“ ástandi. Hins vegar, ef
ibdata1skráin ogib_logfileeru fangaðar úr takti, mun InnoDB-vélin hrynja við endurheimt. - Microsoft SQL Server: SQL Server er mjög viðkvæmur fyrir frystingu á I/O. Án réttrar VSS (Volume Shadow Copy Service) samþættingar mun endurheimt á SQL Server úr staðlaðri skyndimynd oft leiða til þess að gagnagrunnar verða merktir sem „suspect“ og annálakeðjur rofna, sem eyðileggur möguleika þína á endurheimt að tilteknum tímapunkti (PITR).
Bestu starfsvenjur fyrir örugga afritun sýndra gagnagrunna
Til að vernda gagnagrunna sem byggja á færslum verður þú að fara frá „crash-consistent“ afritum yfir í „application-consistent“ (forritssamræmd) afrit. Þetta krefst þess að afritunarbúnaðurinn eigi samskipti við gagnagrunnsvélina, neyði hana til að skola vinnsluminni yfir á disk og gera hlé á I/O-aðgerðum augnablik á meðan skyndimyndin er tekin.
1. Nýttu forritssamræmda frystingu (VSS og fsfreeze)
Fyrir Windows (SQL Server):
Gakktu alltaf úr skugga um að afritunarlausnin þín noti Microsoft Volume Shadow Copy Service (VSS). Þegar VSS-samhæft afrit er ræst, frystir SQL Server VSS Writer I/O-aðgerðir gagnagrunnsins, skolar biðfærslum yfir á disk og tryggir að skyndimyndin sé fullkomlega forritssamræmd.
Fyrir Linux (PostgreSQL / MySQL):
Linux hefur ekki innbyggðan valkost við VSS. Til að ná forritssamræmi verður þú að nota „pre-freeze“ og „post-thaw“ skriftur í tengslum við gestaverkfæri sýndarvélastýrikerfisins (t.d. VMware Tools).
Hér er dæmi um VMware pre-freeze-script fyrir PostgreSQL 15+ sem undirbýr gagnagrunninn á öruggan hátt fyrir skyndimynd:
#!/bin/bash
# /usr/sbin/pre-freeze-script
# Gakktu úr skugga um að þessi skrifta sé keyranleg (chmod +x)
# 1. Segðu PostgreSQL að undirbúa sig fyrir afritun
su - postgres -c "psql -c "SELECT pg_backup_start('vm_snapshot', true);""
# 2. Skolaðu biðminni skráarkerfisins yfir á disk
sync
# 3. Frystu skráarkerfið (að því gefnu að gögnin séu á /var/lib/pgsql)
fsfreeze -f /var/lib/pgsql
Og samsvarandi post-thaw-script til að halda áfram starfsemi:
#!/bin/bash
# /usr/sbin/post-thaw-script
# 1. Af-frystu skráarkerfið
fsfreeze -u /var/lib/pgsql
# 2. Segðu PostgreSQL að afritun sé lokið
su - postgres -c "psql -c "SELECT pg_backup_stop();""
2. Notaðu innbyggð afritunarverkfæri gagnagrunna
Þótt forritssamræmdar skyndimyndir séu betri en staðlaðar skyndimyndir, bera þær samt með sér hættu á „VM stun“. Öruggasta leiðin fyrir afritun gagnagrunna er að nota innbyggð, streymandi afritunarverkfæri sem starfa óháð sýndarvélastýrikerfinu.
PostgreSQL (pg_basebackup):
pg_basebackup -h localhost -U replication_user -D /mnt/backups/pg_backup -Ft -z -P
MySQL/MariaDB (Percona XtraBackup / Mariabackup):
Þessi verkfæri taka „hot“, óhindrandi afrit með því að afrita gagnaskrárnar og fylgjast samtímis með breytingum í redo-annálnum.
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. Innleiða endurheimt að tilteknum tímapunkti (PITR) með annála-arkíveringu
Dagleg skyndimynd eða fullt afrit verndar þig aðeins fram að þeirri mínútu sem það var tekið. Ef gagnagrunnurinn hrynur kl. 16:00 og síðasta skyndimynd var kl. 02:00, tapar þú 14 klukkustundum af færslugögnum.
Til að ná raunverulegu viðskiptaþoli verður þú að sameina full forritssamræmd afrit og samfellda annála-arkíveringu (afritun á WAL, Redo-annálum eða færsluannálum á nokkurra mínútna fresti). Þetta gerir gagnagrunnsstjórum kleift að endurheimta gagnagrunninn að tiltekinni mínútu eða jafnvel tilteknu færslunúmeri fyrir hamfarir.
Afritunarstefnur fyrirtækja með CloudSave
Að stýra sérsniðnum „pre-freeze“-skriftum, cron-verkefnum fyrir innbyggð afrit og annálasendingum yfir tugi gagnagrunnsþjóna er rekstrarlegur martröð fyrir DevOps-teymi. Þetta er þar sem fyrirtækjalausn eins og CloudSave verður mikilvæg.
CloudSave brúar bilið milli sýndarvæðingar og gagnagrunnsarkitektúrs. Í stað þess að treysta á blindar skyndimyndir sýndarvélastýrikerfa, notar CloudSave forritssamræmda umboðsmenn (agents) sem samþættast innbyggt við SQL Server, PostgreSQL, MySQL og Oracle.
Þegar CloudSave ræsir afritun:
1. Á það samskipti beint við gagnagrunnsvélina í gegnum innbyggð API (eins og VSS fyrir Windows eða innbyggt WAL-streymi fyrir Linux).
2. Það skipuleggur skolun á vinnsluminni yfir á disk án þess að valda truflandi frystingu á sýndarvélinni.
3. Það fangar gagnaskrárnar á öruggan hátt og stýrir sjálfkrafa styttingu færsluannála.
4. Það afritar færsluannála stöðugt, sem gerir kleift að endurheimta gögn að tilteknum tímapunkti (PITR) með örfáum smellum.
Með því að færa flækjustigið við forritssamræmi yfir á CloudSave geta gagnagrunnsstjórar og kerfisstjórar tryggt heilleika gagna án þess að fórna afköstum eða tiltækileika framleiðsluklasanna sinna.
Niðurstaða
Skyndimyndir sýndarvéla eru ótrúlegt tæki fyrir innviðastjórnun, en þær eru í grundvallaratriðum ósamrýmanlegar ACID-kröfum gagnagrunna sem byggja á færslum. Að treysta á „crash-consistent“ skyndimyndir sýndarvélastýrikerfa útsetur fyrirtækið þitt fyrir rifnum síðum, rofnum afritunarkeðjum og hörmulegu gagnatapi.
Til að vernda mikilvæg gögn þín verður þú að innleiða forritssamræmda frystingu, nota innbyggðar afritunaraðferðir gagnagrunna og viðhalda samfelldum annálum af færslum. Með því að tileinka þér sérhæfðar afritunarlausnir fyrir fyrirtæki geturðu tryggt að gagnagrunnar þínir haldist tiltækir, fullkomlega endurheimtanlegir og algjörlega öruggir.
