DevOps-inseneride ja s\u00fcsteemiadministraatorite jaoks on virtuaalmasinate (VM) hetkt\u00f5mmised (snapshotid) fundamentaalne t\u00f6\u00f6riist. Need pakuvad kiiret ja mugavat viisi serveri oleku j\u00e4\u00e4dvustamiseks enne riskantset paigaldust, suurt konfiguratsioonimuudatust v\u00f5i rakenduse juurutamist. Kui midagi l\u00e4heb valesti, v\u00f5tab taastamine aega vaid sekundeid.<\/p>\n
Kuid kui sama metoodikat rakendatakse tehingup\u00f5histele andmebaasidele \u2013 nagu PostgreSQL, MySQL, Oracle v\u00f5i Microsoft SQL Server \u2013, muutuvad VM-i hetkt\u00f5mmised turvav\u00f5rgust tiksuvaks pommiks.<\/p>\n
Tuginemine tavalistele h\u00fcperviisori hetkt\u00f5mmistele andmebaaside varundamisel on \u00fcks levinumaid andmete rikkumise, lehek\u00fclgede purunemise (torn pages) ja taastamatute tootmiskatkestuste p\u00f5hjuseid. Selles artiklis uurime arhitektuurilist konflikti h\u00fcperviisorite ja andmebaasimootorite vahel, andmete rikkumise mehhanisme hetkt\u00f5mmiste ajal ning insenertehnilisi parimaid tavasid, mis on vajalikud virtualiseeritud andmebaaside turvaliseks varundamiseks.<\/p>\n
Et m\u00f5ista, miks VM-i hetkt\u00f5mmised andmebaase ohustavad, peame esmalt uurima, kuidas m\u00f5lemad s\u00fcsteemid haldavad olekut ja I\/O-operatsioone.<\/p>\n
Kui h\u00fcperviisor (n\u00e4iteks VMware ESXi, Microsoft Hyper-V v\u00f5i KVM) teeb hetkt\u00f5mmise, ei kopeeri see ketast. Selle asemel k\u00fclmutab see praeguse virtuaalketta faili (nt Kui hetkt\u00f5mmis kustutatakse, peab h\u00fcperviisor delta-kettal olevad andmed p\u00f5hikettale tagasi kandma (konsolideerima). Tavalised hetkt\u00f5mmised ei ole teadlikud k\u00fclalisoperatsioonis\u00fcsteemis t\u00f6\u00f6tavatest rakendustest. Nad j\u00e4\u00e4dvustavad ketta oleku t\u00e4pselt sellisena, nagu see sel mikrosekundil eksisteerib.<\/p>\n Tehingup\u00f5hised andmebaasid on loodud ACID-omaduste (aatomilisus, j\u00e4rjepidevus, isolatsioon, vastupidavus) \u00fcmber. K\u00f5rge j\u00f5udluse saavutamiseks ACID-i j\u00e4rgimise ajal ei kirjuta andmebaasid iga tehingut kohe otse kettal olevatesse peamistesse andmefailidesse. Selle asemel kasutavad nad keerukat mitmetasandilist arhitektuuri:<\/p>\n Selle arhitektuuri t\u00f5ttu on kettal olevad f\u00fc\u00fcsilised andmefailid peaaegu alati andmebaasi tegeliku olekuga s\u00fcnkroonist v\u00e4ljas. Andmebaasi t\u00f5eline olek eksisteerib vaid kettal olevate andmefailide, WAL\/Redo-logide ja hetkel m\u00e4lus asuvate andmete kombinatsioonina.<\/p>\n Kui teete andmebaasiserverist tavalise VM-i hetkt\u00f5mmise, j\u00e4\u00e4dvustate krahhi-j\u00e4rjepideva<\/strong> (crash-consistent) oleku.<\/p>\n Krahhi-j\u00e4rjepidev hetkt\u00f5mmis on v\u00f5rdv\u00e4\u00e4rne toitejuhtme f\u00fc\u00fcsilisest serverist v\u00e4lja t\u00f5mbamisega. Ketta olek j\u00e4\u00e4dvustatakse, kuid k\u00f5ik m\u00e4lus olnud andmed l\u00e4hevad kaotsi ja k\u00f5ik, mis oli poolel teel salvestuskontrollerisse, katkestatakse j\u00e4rsult.<\/p>\n Kuigi kaasaegsed andmebaasid on loodud ootamatust voolukatkestusest taastuma Write-Ahead Logi taasesitamise teel, on krahhitaastumisele tuginemine peamise varundusstrateegiana \u00e4\u00e4rmiselt ohtlik. Kui teie andmebaas ulatub \u00fcle mitme virtuaalketta (nt andmefailid Hetkt\u00f5mmise loomise protsess \u2013 ja mis veelgi olulisem, hetkt\u00f5mmise konsolideerimise protsess \u2013 p\u00f5hjustab n\u00e4htuse nimega \u201eVM Stun\u201c (virtuaalmasina uimastamine).<\/p>\n I\/O ohutuks suunamiseks p\u00f5hikettalt delta-kettale peab h\u00fcperviisor virtuaalmasina korraks peatama (stun). V\u00e4ikese koormusega veebiserveri puhul v\u00f5ib see kesta 10\u201350 millisekundit ja j\u00e4\u00e4da m\u00e4rkamatuks. Kuid suure I\/O-mahuga andmebaasi puhul v\u00f5ib suure delta-ketta konsolideerimine virtuaalmasinat mitmeks sekundiks peatada.<\/p>\n VM-i peatamise ajal: Andmebaasimootorid kirjutavad andmeid tavaliselt kindla suurusega lehek\u00fclgedena (nt 8 KB PostgreSQL-i ja SQL Serveri puhul, 16 KB InnoDB puhul). Kuid aluseks olev operatsioonis\u00fcsteem ja salvestusmassiivid t\u00f6\u00f6tlevad I\/O-d v\u00e4iksemate plokkidena (nt 4 KB v\u00f5i 512 baiti).<\/p>\n Kui h\u00fcperviisor teeb hetkt\u00f5mmise t\u00e4pselt siis, kui andmebaas kirjutab 8 KB lehek\u00fclge, v\u00f5ib hetkt\u00f5mmis j\u00e4\u00e4dvustada uute andmete esimesed 4 KB ja vanade andmete viimased 4 KB. See tekitab purunenud lehek\u00fclje<\/strong> (torn page). Kui proovite hetkt\u00f5mmist taastada, loeb andmebaas lehek\u00fclge, kontrollsumma valideerimine eba\u00f5nnestub ja andmebaas m\u00e4rgitakse rikutuks.<\/p>\n Erinevad andmebaasimootorid reageerivad krahhi-j\u00e4rjepidevatele hetkt\u00f5mmistele erinevalt, kuid \u00fckski neist ei k\u00e4sitle seda tootmiskeskkonnas sujuvalt.<\/p>\n Tehingup\u00f5histe andmebaaside kaitsmiseks peate liikuma krahhi-j\u00e4rjepidevatelt varukoopiatelt rakenduse-j\u00e4rjepidevatele<\/strong> (application-consistent) varukoopiatele. See n\u00f5uab, et varundusmehhanism suhtleks andmebaasimootoriga, sundides seda m\u00e4lu kettale kirjutama ja I\/O-operatsioone hetkeks peatama, kuni hetkt\u00f5mmis tehakse.<\/p>\n Windowsi jaoks (SQL Server):<\/strong> Linuxi jaoks (PostgreSQL \/ MySQL):<\/strong> Siin on n\u00e4ide VMware Ja vastav Kuigi rakenduse-j\u00e4rjepidevad hetkt\u00f5mmised on paremad kui tavalised, kaasneb nendega endiselt VM-i peatamise oht. K\u00f5ige turvalisem l\u00e4henemine andmebaaside varundamiseks on kasutada natiivseid voogedastus-varundust\u00f6\u00f6riistu, mis t\u00f6\u00f6tavad h\u00fcperviisorist s\u00f5ltumatult.<\/p>\n PostgreSQL (pg_basebackup):<\/strong><\/p>\n MySQL\/MariaDB (Percona XtraBackup \/ Mariabackup):<\/strong> SQL Server (T-SQL):<\/strong><\/p>\n Igap\u00e4evane hetkt\u00f5mmis v\u00f5i t\u00e4isvarukoopia kaitseb teid ainult kuni selle tegemise hetkeni. Kui teie andmebaas jookseb kokku kell 16:00 ja teie viimane hetkt\u00f5mmis oli kell 02:00, kaotate 14 tunni jagu tehinguandmeid.<\/p>\n T\u00f5elise ettev\u00f5tte tasemel vastupidavuse saavutamiseks peate kombineerima t\u00e4ielikud rakenduse-j\u00e4rjepidevad varukoopiad pideva logide arhiveerimisega (WAL, Redo-logide v\u00f5i tehingulogide varundamine iga paari minuti j\u00e4rel). See v\u00f5imaldab andmebaasiadministraatoritel taastada andmebaasi konkreetse minutini v\u00f5i isegi konkreetse tehingu ID-ni enne katastroofi.<\/p>\n Kohandatud pre-freeze skriptide, natiivsete dumpide cron-t\u00f6\u00f6de ja logide saatmise haldamine k\u00fcmnetes andmebaasiserverites on DevOps-meeskondade jaoks operatiivne \u00f5udusunen\u00e4gu. Siin muutub kriitiliseks ettev\u00f5tte tasemel platvorm nagu CloudSave.<\/p>\n CloudSave \u00fcletab l\u00f5he virtualiseerimise ja andmebaasi arhitektuuri vahel. Selle asemel, et loota pimesi h\u00fcperviisori hetkt\u00f5mmistele, kasutab CloudSave rakendusteadlikke agente, mis integreeruvad natiivselt SQL Serveri, PostgreSQL-i, MySQL-i ja Oracle’iga.<\/p>\n Kui CloudSave algatab varunduse: Andes rakenduse-j\u00e4rjepidevuse keerukuse \u00fcle CloudSave’ile, saavad andmebaasiadministraatorid ja s\u00fcsteemiadministraatorid tagada andmete terviklikkuse, ohverdamata oma tootmisklastrite j\u00f5udlust v\u00f5i k\u00e4ttesaadavust.<\/p>\n Virtuaalmasinate hetkt\u00f5mmised on infrastruktuuri haldamiseks suurep\u00e4rane t\u00f6\u00f6riist, kuid need on fundamentaalselt kokkusobimatud tehingup\u00f5histe andmebaaside ACID-n\u00f5uetega. Krahhi-j\u00e4rjepidevatele h\u00fcperviisori hetkt\u00f5mmistele tuginemine j\u00e4tab teie organisatsiooni avatuks purunenud lehek\u00fclgedele, katkenud replikatsiooniahelatele ja katastroofilisele andmekaole.<\/p>\n Oma missioonikriitiliste andmete kaitsmiseks peate rakendama rakendusteadlikku k\u00fclmutamist, kasutama natiivseid andmebaasi varundusmetoodikaid ja s\u00e4ilitama pidevaid tehingulogide arhiive. V\u00f5ttes kasutusele spetsiaalselt loodud ettev\u00f5tte varunduslahendused, saate tagada, et teie andmebaasid j\u00e4\u00e4vad k\u00f5rge k\u00e4ttesaadavusega, t\u00e4ielikult taastatavateks ja t\u00e4iesti turvalisteks.<\/p>\n","protected":false},"excerpt":{"rendered":" > Discover why standard VM snapshots cause data corruption in transactional databases like PostgreSQL and SQL Server. Learn DBA best practices for application-consistent backups, avoiding VM stun, and ensuring data integrity with CloudSave.<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"closed","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"rank_math_title":"Why VM Snapshots Are Unsafe for Transactional Databases","rank_math_description":"> Discover why standard VM snapshots cause data corruption in transactional databases like PostgreSQL and SQL Server. Learn DBA best practices for application-consistent backups, avoiding VM stun, and ensuring data integrity with CloudSave.","rank_math_focus_keyword":"VM snapshots transactional databases","footnotes":""},"categories":[415],"tags":[3340,3632,3633,3634,3635,3636,3637],"class_list":["post-5478","post","type-post","status-publish","format-standard","hentry","category-database-backup","tag-data-integrity","tag-database-corruption","tag-database-recovery","tag-dba-guide","tag-hypervisor-snapshots","tag-transactional-databases","tag-vm-snapshots"],"yoast_head":"\n.vmdk<\/code> v\u00f5i .vhdx<\/code>) kirjutuskaitstud olekusse ja loob uue delta-ketta (erinevuste ketas). K\u00f5ik j\u00e4rgnevad kirjutamised suunatakse sellele delta-kettale.<\/p>\nKuidas tehingup\u00f5hised andmebaasid olekut haldavad<\/h3>\n
\n
Ohutsoon: mis juhtub VM-i hetkt\u00f5mmise ajal<\/h2>\n
Krahhi-j\u00e4rjepidevus vs. rakenduse-j\u00e4rjepidevus<\/h3>\n
Draivil D:<\/code> ja WAL Draivil E:<\/code>), ei pruugi h\u00fcperviisor m\u00f5lemat ketast t\u00e4pselt samal mikrosekundil j\u00e4\u00e4dvustada. Kui WAL-ketta hetkt\u00f5mmis j\u00e4\u00e4dvustatakse kasv\u00f5i murdosa sekundist p\u00e4rast andmeketta hetkt\u00f5mmist, ei suuda andmebaas taastamisel j\u00e4rjestusnumbreid kokku viia, mis viib fataalse riknemiseni.<\/p>\n\u201eVM Stun\u201c efekt suure tehingumahuga s\u00fcsteemides<\/h3>\n
\n* V\u00f5rgu\u00fchendused katkevad, p\u00f5hjustades rakenduste ajal\u00f5ppe.
\n* K\u00f5rge k\u00e4ttesaadavusega klastrid (nagu SQL Server Always On, PostgreSQL Patroni v\u00f5i MySQL Galera) j\u00e4tavad s\u00fcdamel\u00f6\u00f6kide kontrollid (heartbeat checks) vahele.
\n* Klaster v\u00f5ib eeldada, et peatatud s\u00f5lm on surnud, k\u00e4ivitades tarbetu ja h\u00e4iriva failoveri (split-brain stsenaarium).<\/p>\nPurunenud lehek\u00fcljed ja I\/O eba\u00fchtlus<\/h3>\n
Tegelikud tagaj\u00e4rjed konkreetsetele andmebaasimootoritele<\/h2>\n
\n
pg_wal<\/code> kataloogile. Kui hetkt\u00f5mmis j\u00e4\u00e4dvustab andmekataloogi ($PGDATA<\/code>) ja WAL-i s\u00fcnkroonist v\u00e4ljas, ei k\u00e4ivitu PostgreSQL, visates vea PANIC: could not locate a valid checkpoint record<\/code>.<\/li>\nibdata1<\/code> fail ja ib_logfile<\/code> j\u00e4\u00e4dvustatakse s\u00fcnkroonist v\u00e4ljas, jookseb InnoDB mootor taastamisel kokku.<\/li>\nParimad tavad virtualiseeritud andmebaaside turvaliseks varundamiseks<\/h2>\n
1. Kasutage rakendusteadlikku k\u00fclmutamist (VSS ja fsfreeze)<\/h3>\n
\nVeenduge alati, et teie varunduslahendus kasutab Microsoft Volume Shadow Copy Service’i (VSS). Kui k\u00e4ivitatakse VSS-teadlik varundus, k\u00fclmutab SQL Server VSS Writer andmebaasi I\/O, kirjutab ootel tehingud kettale ja tagab, et hetkt\u00f5mmis on t\u00e4ielikult rakenduse-j\u00e4rjepidev.<\/p>\n
\nLinuxil pole VSS-ile otsest vastet. Rakenduse-j\u00e4rjepidevuse saavutamiseks peate kasutama pre-freeze ja post-thaw skripte koos h\u00fcperviisori k\u00fclalist\u00f6\u00f6riistadega (nt VMware Tools).<\/p>\npre-freeze-script<\/code> skriptist PostgreSQL 15+ jaoks, mis valmistab andmebaasi turvaliselt ette hetkt\u00f5mmiseks:<\/p>\n#!\/bin\/bash\n# \/usr\/sbin\/pre-freeze-script\n# Veenduge, et see skript on k\u00e4ivitatav (chmod +x)\n\n# 1. K\u00e4skige PostgreSQL-il varunduseks valmistuda\nsu - postgres -c \"psql -c \"SELECT pg_backup_start('vm_snapshot', true);\"\"\n\n# 2. Kirjutage failis\u00fcsteemi puhvrid kettale\nsync\n\n# 3. K\u00fclmutage failis\u00fcsteem (eeldades, et andmed on \/var\/lib\/pgsql)\nfsfreeze -f \/var\/lib\/pgsql\n<\/code><\/pre>\npost-thaw-script<\/code> toimingute j\u00e4tkamiseks:<\/p>\n#!\/bin\/bash\n# \/usr\/sbin\/post-thaw-script\n\n# 1. Vabastage failis\u00fcsteem\nfsfreeze -u \/var\/lib\/pgsql\n\n# 2. Teavitage PostgreSQL-i, et varundus on l\u00f5petatud\nsu - postgres -c \"psql -c \"SELECT pg_backup_stop();\"\"\n<\/code><\/pre>\n2. Kasutage andmebaasi natiivseid varundust\u00f6\u00f6riistu<\/h3>\n
pg_basebackup -h localhost -U replication_user -D \/mnt\/backups\/pg_backup -Ft -z -P\n<\/code><\/pre>\n
\nNeed t\u00f6\u00f6riistad teevad “kuumi”, blokeerimata varukoopiaid, kopeerides andmefailid ja j\u00e4lgides samal ajal muudatusi redo-logis.<\/p>\nmariabackup --backup --target-dir=\/mnt\/backups\/mysql_backup --user=root --password=SecurePass\n<\/code><\/pre>\nBACKUP DATABASE [ProductionDB] \nTO DISK = N'Z:BackupsProductionDB.bak' \nWITH NOFORMAT, NOINIT, NAME = N'ProductionDB-Full Backup', \nSKIP, NOREWIND, NOUNLOAD, COMPRESSION, STATS = 10;\nGO\n<\/code><\/pre>\n3. Rakendage Point-in-Time Recovery (PITR) logide arhiveerimise kaudu<\/h3>\n
Ettev\u00f5tte varundusstrateegiad koos CloudSave’iga<\/h2>\n
\n1. Suhtleb see otse andmebaasimootoriga natiivsete API-de kaudu (nagu VSS Windowsi jaoks v\u00f5i natiivne WAL-voogedastus Linuxi jaoks).
\n2. See orkestreerib m\u00e4lupuhvrite kirjutamist kettale, p\u00f5hjustamata h\u00e4irivaid VM-i peatamisi.
\n3. See j\u00e4\u00e4dvustab turvaliselt andmefailid ja haldab automaatselt tehingulogide k\u00e4rpimist.
\n4. See varundab pidevalt tehinguloge, v\u00f5imaldades m\u00f5ne klikiga t\u00e4pset Point-in-Time Recovery (PITR) taastamist.<\/p>\nKokkuv\u00f5te<\/h2>\n