Kodėl VM momentinės kopijos nėra saugios operacijų duomenų bazėms: DBA vadovas duomenų vientisumui užtikrinti

DevOps inžinieriams ir sistemų administratoriams virtualiųjų mašinų (VM) momentinės kopijos (angl. snapshots) yra pamatinis įrankis. Jos suteikia greitą ir patogų būdą užfiksuoti serverio būseną prieš rizikingą pataisymą, didelį konfigūracijos pakeitimą ar programos diegimą. Jei kas nors nepavyksta, sugrąžinimas į ankstesnę būseną užtrunka vos kelias sekundes.

Tačiau, kai ši metodika taikoma transakcinėms duomenų bazėms – tokioms kaip „PostgreSQL“, „MySQL“, „Oracle“ ar „Microsoft SQL Server“ – VM momentinės kopijos iš saugumo priemonės virsta tiksinčia bomba.

Pasikliovimas standartinėmis hipervizoriaus momentinėmis kopijomis darant duomenų bazių atsargines kopijas yra viena dažniausių duomenų sugadinimo, „plyšusių puslapių“ (angl. torn pages) ir neatkuriamų gamybinių sistemų prastovų priežasčių. Šiame straipsnyje aptarsime architektūrinį konfliktą tarp hipervizorių ir duomenų bazių variklių, duomenų sugadinimo mechaniką kuriant momentines kopijas bei inžinerinę praktiką, būtiną saugiam virtualizuotų duomenų bazių atsarginių kopijų kūrimui.

Architektūrinis konfliktas: hipervizoriai prieš duomenų bazių variklius

Norint suprasti, kodėl VM momentinės kopijos kelia pavojų duomenų bazėms, pirmiausia turime išnagrinėti, kaip abi sistemos valdo būseną ir I/O (įvesties/išvesties) operacijas.

Kaip hipervizoriai atlieka momentines kopijas

Kai hipervizorius (pvz., „VMware ESXi“, „Microsoft Hyper-V“ arba KVM) sukuria momentinę kopiją, jis nekopijuoja viso disko. Vietoj to, jis užšaldo esamą virtualaus disko failą (pvz., .vmdk arba .vhdx) į tik skaitymo būseną ir sukuria naują „delta“ diską (skirtumų diską). Visi vėlesni įrašymo veiksmai nukreipiami į šį „delta“ diską.

Kai momentinė kopija ištrinama, hipervizorius turi įrašyti (konsoliduoti) duomenis iš „delta“ disko atgal į pagrindinį diską. Standartinės momentinės kopijos visiškai „nežino“ apie svečio operacinėje sistemoje veikiančias programas. Jos užfiksuoja disko būseną tiksliai tokią, kokia ji yra tą mikrosekundę.

Kaip transakcinės duomenų bazės valdo būseną

Transakcinės duomenų bazės yra sukurtos remiantis ACID savybėmis (atomumas, nuoseklumas, izoliacija, patvarumas). Siekiant užtikrinti aukštą našumą ir kartu išlaikyti ACID atitiktį, duomenų bazės ne visada iškart įrašo kiekvieną transakciją tiesiai į pagrindinius duomenų failus diske. Vietoj to jos naudoja sudėtingą, kelių pakopų architektūrą:

1. Buferio fondas / bendrinami buferiai: duomenys nuskaitomi ir modifikuojami sistemos atmintyje.
2. Įrašymo žurnalas (WAL) / „Redo“ žurnalai: pakeitimai nuosekliai įrašomi į itin optimizuotą žurnalo failą diske, kad būtų užtikrintas patvarumas.
3. Kontroliniai taškai / „Lazy Writers“: periodiškai duomenų bazė iš atminties į tikruosius duomenų failus diske perkelia modifikuotus („nešvarius“) puslapius.

Dėl šios architektūros fiziniai duomenų failai diske beveik visada nesutampa su tikrąja duomenų bazės būsena. Tikroji duomenų bazės būsena egzistuoja tik kaip duomenų failų diske, WAL/„Redo“ žurnalų ir šiuo metu atmintyje esančių duomenų derinys.

Pavojinga zona: kas vyksta kuriant VM momentinę kopiją

Kai kuriate standartinę VM momentinę kopiją duomenų bazės serveryje, užfiksuojate nuoseklią avarijos atveju (angl. crash-consistent) būseną.

Nuoseklumas avarijos atveju prieš nuoseklumą programos lygiu

Nuosekli avarijos atveju momentinė kopija prilygsta maitinimo laido ištraukimui iš fizinio serverio. Disko būsena užfiksuojama, tačiau tai, kas buvo atmintyje, prarandama, o tai, kas buvo pakeliui į saugojimo valdiklį, staiga nutraukiama.

Nors šiuolaikinės duomenų bazės yra sukurtos taip, kad atsigautų po netikėto maitinimo praradimo peržaisdamos įrašymo žurnalą (WAL), pasikliauti avarijos atkūrimu kaip pagrindine atsarginių kopijų strategija yra labai pavojinga. Jei jūsų duomenų bazė apima kelis virtualius diskus (pvz., duomenų failai D: diske, o WAL – E: diske), hipervizorius gali nepadaryti abiejų diskų momentinės kopijos tą pačią mikrosekundę. Jei WAL disko momentinė kopija užfiksuojama bent sekundės dalimi vėliau nei duomenų disko, atkūrimo metu duomenų bazė negali suderinti sekos numerių, todėl įvyksta lemtinga korupcija.

„VM Stun“ efektas didelio transakcijų skaičiaus sistemose

Momentinės kopijos kūrimo procesas – ir, dar svarbiau, jos konsolidavimo procesas – sukelia reiškinį, vadinamą „VM Stun“ (virtualios mašinos sustingimu).

Kad saugiai perjungtų I/O iš pagrindinio disko į „delta“ diską, hipervizorius turi trumpam pristabdyti (sustingdyti) virtualią mašiną. Lengvai apkrautam žiniatinklio serveriui šis sustingimas gali trukti 10–50 milisekundžių ir likti nepastebėtas. Tačiau duomenų bazei su dideliu I/O srautu didelio „delta“ disko konsolidavimas gali sustingdyti VM kelioms sekundėms.

VM sustingimo metu:
* Nutrūksta tinklo ryšiai, todėl programos patiria skirtąjį laiką (timeout).
* Didelio pasiekiamumo klasteriai (pvz., „SQL Server Always On“, „PostgreSQL Patroni“ ar „MySQL Galera“) praleidžia „širdies plakimo“ (heartbeat) patikras.
* Klasteris gali nuspręsti, kad sustingęs mazgas yra negyvas, ir inicijuoti nereikalingą bei trikdančią perjungimą (angl. failover) (vadinamasis „split-brain“ scenarijus).

„Plyšę puslapiai“ ir I/O nesuderinamumas

Duomenų bazių varikliai paprastai rašo duomenis tam tikro dydžio puslapiais (pvz., 8 KB „PostgreSQL“ ir „SQL Server“, 16 KB „InnoDB“). Tačiau pagrindinė operacinė sistema ir saugojimo masyvai apdoroja I/O mažesniais blokais (pvz., 4 KB arba 512 baitų).

Jei hipervizorius sukuria momentinę kopiją tiksliai tuo metu, kai duomenų bazė rašo 8 KB puslapį, momentinė kopija gali užfiksuoti pirmuosius 4 KB naujų duomenų ir paskutinius 4 KB senų duomenų. Tai sukuria „plyšusį puslapį“. Bandant atkurti momentinę kopiją, duomenų bazė perskaitys puslapį, nepraeis kontrolinės sumos patikros ir pažymės duomenų bazę kaip sugadintą.

Realaus pasaulio pasekmės konkretiems duomenų bazių varikliams

Skirtingi duomenų bazių varikliai į nuoseklias avarijos atveju momentines kopijas reaguoja skirtingai, tačiau nė vienas iš jų gamybinėje aplinkoje to neatlieka sklandžiai.

• PostgreSQL: „PostgreSQL“ labai priklauso nuo pg_wal katalogo. Jei momentinė kopija užfiksuoja duomenų katalogą ($PGDATA) ir WAL nesinchronizuotai, „PostgreSQL“ nepavyks paleisti, išmetant klaidą PANIC: could not locate a valid checkpoint record.
• MySQL/InnoDB: „InnoDB“ naudoja „doublewrite“ buferį, kad išvengtų „plyšusių puslapių“, o tai suteikia tam tikrą apsaugą nuo nuoseklių avarijos atveju būsenų. Tačiau, jei ibdata1 failas ir ib_logfile užfiksuojami nesinchronizuotai, „InnoDB“ variklis atkūrimo metu sugrius.
• Microsoft SQL Server: „SQL Server“ yra itin jautrus I/O užšaldymui. Be tinkamos VSS (Volume Shadow Copy Service) integracijos, „SQL Server“ atkūrimas iš standartinės VM momentinės kopijos dažnai baigiasi „įtartinomis“ (suspect) duomenų bazėmis ir nutrūkusiomis žurnalų grandinėmis, taip sunaikinant jūsų galimybes atkurti duomenis konkrečiu laiku (PITR).

Geriausia praktika saugiam virtualizuotų duomenų bazių atsarginių kopijų kūrimui

Norėdami apsaugoti transakcines duomenų bazes, turite pereiti nuo nuoseklių avarijos atveju atsarginių kopijų prie nuoseklių programos lygiu atsarginių kopijų. Tai reikalauja, kad atsarginių kopijų kūrimo mechanizmas susisiektų su duomenų bazės varikliu, priversdamas jį išvalyti atmintį į diską ir laikinai pristabdyti I/O operacijas, kol daroma momentinė kopija.

1. Pasinaudokite programos lygio užšaldymu (VSS ir fsfreeze)

„Windows“ (SQL Server):
Visada užtikrinkite, kad jūsų atsarginių kopijų kūrimo sprendimas naudoja „Microsoft Volume Shadow Copy Service“ (VSS). Kai inicijuojama VSS palaikanti atsarginė kopija, „SQL Server VSS Writer“ užšaldo duomenų bazės I/O, išvalo laukiančias transakcijas į diską ir užtikrina, kad momentinė kopija būtų visiškai nuosekli programos lygiu.

„Linux“ (PostgreSQL / MySQL):
„Linux“ neturi vietinio VSS atitikmens. Norėdami pasiekti programos lygio nuoseklumą, turite naudoti „pre-freeze“ ir „post-thaw“ scenarijus kartu su hipervizoriaus svečio įrankiais (pvz., „VMware Tools“).

Štai „VMware“ pre-freeze-script pavyzdys „PostgreSQL 15+“ versijai, kuris saugiai paruošia duomenų bazę momentinei kopijai:

#!/bin/bash
# /usr/sbin/pre-freeze-script
# Įsitikinkite, kad šis scenarijus yra vykdomasis (chmod +x)

# 1. Nurodykite „PostgreSQL“ pasiruošti atsarginei kopijai
su - postgres -c "psql -c "SELECT pg_backup_start('vm_snapshot', true);""

# 2. Išvalykite failų sistemos buferius į diską
sync

# 3. Užšaldykite failų sistemą (darant prielaidą, kad duomenys yra /var/lib/pgsql)
fsfreeze -f /var/lib/pgsql

Ir atitinkamas post-thaw-script operacijoms atnaujinti:

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

# 1. Atšaldykite failų sistemą
fsfreeze -u /var/lib/pgsql

# 2. Nurodykite „PostgreSQL“, kad atsarginė kopija baigta
su - postgres -c "psql -c "SELECT pg_backup_stop();""

2. Naudokite vietines duomenų bazių atsarginių kopijų priemones

Nors programos lygiu nuoseklios momentinės kopijos yra geriau nei standartinės, jos vis tiek kelia VM sustingimo riziką. Saugiausias būdas duomenų bazių atsarginėms kopijoms – naudoti vietines, srautines atsarginių kopijų priemones, kurios veikia nepriklausomai nuo hipervizoriaus.

PostgreSQL (pg_basebackup):

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

MySQL/MariaDB (Percona XtraBackup / Mariabackup):
Šie įrankiai daro „karštas“, neblokuojančias atsargines kopijas, kopijuodami duomenų failus ir kartu sekdami pakeitimus „redo“ žurnale.

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. Įdiekite atkūrimą konkrečiu laiku (PITR) per žurnalų archyvavimą

Kasdienė momentinė kopija ar pilna atsarginė kopija apsaugo jus tik iki tos minutės, kai ji buvo padaryta. Jei jūsų duomenų bazė sugenda 16:00 val., o paskutinė momentinė kopija buvo 02:00 val., prarandate 14 valandų transakcinių duomenų.

Norėdami pasiekti tikrą įmonės lygio atsparumą, turite derinti pilnas, programos lygiu nuoseklias atsargines kopijas su nuolatiniu žurnalų archyvavimu (WAL, „Redo“ žurnalų ar transakcijų žurnalų atsarginių kopijų kūrimas kas kelias minutes). Tai leidžia duomenų bazių administratoriams atkurti duomenų bazę iki konkrečios minutės ar net konkretaus transakcijos ID prieš įvykstant nelaimei.

Įmonės atsarginių kopijų strategijos su „CloudSave“

Individualių „pre-freeze“ scenarijų, „cron“ užduočių vietiniams duomenų bazės išrašams ir žurnalų siuntimo valdymas dešimtyse duomenų bazių serverių yra operacinis košmaras „DevOps“ komandoms. Čia tampa kritiškai svarbi įmonės lygio platforma, tokia kaip „CloudSave“.

„CloudSave“ sujungia virtualizaciją ir duomenų bazių architektūrą. Užuot pasikliovusi aklais hipervizoriaus momentiniais vaizdais, „CloudSave“ naudoja programos lygio agentus, kurie natūraliai integruojasi su „SQL Server“, „PostgreSQL“, „MySQL“ ir „Oracle“.

Kai „CloudSave“ inicijuoja atsarginę kopiją:
1. Ji tiesiogiai bendrauja su duomenų bazės varikliu per vietines API (pvz., VSS „Windows“ arba vietinį WAL srautinį perdavimą „Linux“).
2. Ji suderina atminties buferių išvalymą į diską nesukeldama trikdančių VM sustingimų.
3. Ji saugiai užfiksuoja duomenų failus ir automatiškai valdo transakcijų žurnalų sutrumpinimą.
4. Ji nuolat kuria transakcijų žurnalų atsargines kopijas, įgalindama tikslų atkūrimą konkrečiu laiku (PITR) vos keliais paspaudimais.

Perleisdami programos lygio nuoseklumo sudėtingumą „CloudSave“, duomenų bazių administratoriai ir sistemų administratoriai gali garantuoti duomenų vientisumą neaukodami savo gamybinių klasterių našumo ar pasiekiamumo.

Išvada

Virtualiųjų mašinų momentinės kopijos yra neįtikėtinas įrankis infrastruktūros valdymui, tačiau jos iš esmės nesuderinamos su transakcinių duomenų bazių ACID reikalavimais. Pasikliovimas nuosekliomis avarijos atveju hipervizoriaus momentinėmis kopijomis jūsų organizaciją atveria „plyšusių puslapių“, nutrūkusių replikacijos grandinių ir katastrofiško duomenų praradimo rizikai.

Norėdami apsaugoti savo kritinius duomenis, privalote įdiegti programos lygio užšaldymą, naudoti vietines duomenų bazių atsarginių kopijų metodikas ir palaikyti nuolatinius transakcijų žurnalų archyvus. Priimdami specialiai tam sukurtus įmonės lygio atsarginių kopijų sprendimus, galite užtikrinti, kad jūsų duomenų bazės išliks itin pasiekiamos, visiškai atkuriamos ir visiškai saugios.