DevOps-insin\u00f6\u00f6reille ja j\u00e4rjestelm\u00e4yll\u00e4pit\u00e4jille virtuaalikoneiden (VM) tilannevedokset eli snapshotit ovat perusty\u00f6kalu. Ne tarjoavat nopean ja k\u00e4tev\u00e4n tavan tallentaa palvelimen tila ennen riskialtista p\u00e4ivityst\u00e4, merkitt\u00e4v\u00e4\u00e4 konfiguraatiomuutosta tai sovelluksen k\u00e4ytt\u00f6\u00f6nottoa. Jos jokin menee vikaan, palauttaminen vie vain sekunteja.<\/p>\n
Kuitenkin, kun t\u00e4t\u00e4 samaa menetelm\u00e4\u00e4 sovelletaan transaktiotietokantoihin \u2013 kuten PostgreSQL, MySQL, Oracle tai Microsoft SQL Server \u2013 virtuaalikoneiden tilannevedokset muuttuvat turvaverkosta tikitt\u00e4v\u00e4ksi aikapommiksi.<\/p>\n
Hypervisor-tason standardien tilannevedosten k\u00e4ytt\u00e4minen tietokantojen varmuuskopiointiin on yksi yleisimmist\u00e4 syist\u00e4 tietojen korruptoitumiseen, rikkin\u00e4isiin sivuihin (torn pages) ja palautuskelvottomiin tuotantokatkoksiin. T\u00e4ss\u00e4 artikkelissa tutkimme hypervisorien ja tietokantamoottorien v\u00e4list\u00e4 arkkitehtuuriristiriitaa, tilannevedosten aikana tapahtuvan tietojen korruptoitumisen mekaniikkaa sek\u00e4 parhaita k\u00e4yt\u00e4nt\u00f6j\u00e4 virtualisoitujen tietokantojen turvalliseen varmuuskopiointiin.<\/p>\n
Ymm\u00e4rt\u00e4\u00e4ksemme, miksi virtuaalikoneiden tilannevedokset vaarantavat tietokannat, meid\u00e4n on ensin tarkasteltava, miten molemmat j\u00e4rjestelm\u00e4t hallitsevat tilaa ja I\/O-operaatioita.<\/p>\n
Kun hypervisor (kuten VMware ESXi, Microsoft Hyper-V tai KVM) ottaa tilannevedoksen, se ei kopioi levy\u00e4. Sen sijaan se j\u00e4\u00e4dytt\u00e4\u00e4 nykyisen virtuaalilevytiedoston (esim. Kun tilannevedos poistetaan, hypervisorin on yhdistett\u00e4v\u00e4 (konsolidoitava) tiedot delta-levylt\u00e4 takaisin peruslevylle. Standardit tilannevedokset eiv\u00e4t ole lainkaan tietoisia vierask\u00e4ytt\u00f6j\u00e4rjestelm\u00e4ss\u00e4 toimivista sovelluksista. Ne tallentavat levyn tilan t\u00e4sm\u00e4lleen sellaisena kuin se on kyseisell\u00e4 mikrosekunnilla.<\/p>\n Transaktiotietokannat on suunniteltu ACID-ominaisuuksien (Atomicity, Consistency, Isolation, Durability) ymp\u00e4rille. Korkean suorituskyvyn saavuttamiseksi ja ACID-yhteensopivuuden s\u00e4ilytt\u00e4miseksi tietokannat eiv\u00e4t kirjoita jokaista transaktiota v\u00e4litt\u00f6m\u00e4sti levyn ensisijaisiin datatiedostoihin. Sen sijaan ne k\u00e4ytt\u00e4v\u00e4t monimutkaista, monitasoista arkkitehtuuria:<\/p>\n T\u00e4m\u00e4n arkkitehtuurin vuoksi levyn fyysiset datatiedostot ovat l\u00e4hes aina ep\u00e4tahdissa tietokannan todellisen tilan kanssa. Tietokannan todellinen tila on olemassa vain yhdistelm\u00e4n\u00e4 levyn datatiedostoja, WAL\/Redo-lokeja ja t\u00e4ll\u00e4 hetkell\u00e4 muistissa olevia tietoja.<\/p>\n Kun otat standardin virtuaalikoneen tilannevedoksen tietokantapalvelimesta, tallennat kaatumisen kest\u00e4v\u00e4n<\/strong> (crash-consistent) tilan.<\/p>\n Kaatumisen kest\u00e4v\u00e4 tilannevedos vastaa virtajohdon irrottamista fyysisest\u00e4 palvelimesta. Levyn tila tallennetaan, mutta kaikki muistissa ollut katoaa, ja kaikki, mik\u00e4 oli matkalla tallennusohjaimelle, katkeaa \u00e4killisesti.<\/p>\n Vaikka nykyaikaiset tietokannat on suunniteltu toipumaan odottamattomasta s\u00e4hk\u00f6katkosta toistamalla Write-Ahead Log -lokia, kaatumisen j\u00e4lkeiseen palautukseen luottaminen ensisijaisena varmuuskopiostrategiana on eritt\u00e4in vaarallista. Jos tietokantasi jakautuu useille virtuaalilevyille (esim. datatiedostot Tilannevedoksen luontiprosessi \u2013 ja mik\u00e4 t\u00e4rke\u00e4mp\u00e4\u00e4, tilannevedoksen konsolidointiprosessi \u2013 aiheuttaa ilmi\u00f6n, joka tunnetaan nimell\u00e4 ”VM Stun”.<\/p>\n Jotta I\/O voidaan turvallisesti siirt\u00e4\u00e4 peruslevylt\u00e4 delta-levylle, hypervisorin on keskeytett\u00e4v\u00e4 (stun) virtuaalikone hetkeksi. Kevyesti kuormitetulla verkkopalvelimella t\u00e4m\u00e4 keskeytys voi kest\u00e4\u00e4 10\u201350 millisekuntia eik\u00e4 sit\u00e4 huomata. Kuitenkin korkean suorituskyvyn tietokannalla, jossa on massiivinen I\/O, suuren delta-levyn konsolidointi voi pys\u00e4ytt\u00e4\u00e4 virtuaalikoneen useiksi sekunneiksi.<\/p>\n VM Stun -ilmi\u00f6n aikana: Tietokantamoottorit kirjoittavat tietoja yleens\u00e4 tietyiss\u00e4 sivukoissa (esim. 8 kt PostgreSQL:lle ja SQL Serverille, 16 kt InnoDB:lle). Taustalla oleva k\u00e4ytt\u00f6j\u00e4rjestelm\u00e4 ja tallennusj\u00e4rjestelm\u00e4t k\u00e4sittelev\u00e4t kuitenkin I\/O:ta pienemmiss\u00e4 lohkoissa (esim. 4 kt tai 512 tavua).<\/p>\n Jos hypervisor ottaa tilannevedoksen juuri silloin, kun tietokanta kirjoittaa 8 kt:n sivua, tilannevedos saattaa tallentaa uuden tiedon ensimm\u00e4iset 4 kt ja vanhan tiedon viimeiset 4 kt. T\u00e4m\u00e4 luo rikkin\u00e4isen sivun<\/strong> (torn page). Kun yrit\u00e4t palauttaa tilannevedoksen, tietokanta lukee sivun, ep\u00e4onnistuu tarkistussumman validoinnissa ja merkitsee tietokannan korruptoituneeksi.<\/p>\n Eri tietokantamoottorit reagoivat kaatumisen kest\u00e4viin tilannevedoksiin eri tavoin, mutta mik\u00e4\u00e4n niist\u00e4 ei k\u00e4sittele niit\u00e4 tyylikk\u00e4\u00e4sti tuotantoymp\u00e4rist\u00f6ss\u00e4.<\/p>\n Suojataksesi transaktiotietokantoja, sinun on siirrytt\u00e4v\u00e4 kaatumisen kest\u00e4vist\u00e4 varmuuskopioista sovellustason kest\u00e4viin<\/strong> (application-consistent) varmuuskopioihin. T\u00e4m\u00e4 edellytt\u00e4\u00e4, ett\u00e4 varmuuskopiointimekanismi kommunikoi tietokantamoottorin kanssa, pakottaen sen tyhjent\u00e4m\u00e4\u00e4n muistin levylle ja keskeytt\u00e4m\u00e4\u00e4n I\/O-operaatiot hetkellisesti tilannevedoksen ottamisen ajaksi.<\/p>\n Windows (SQL Server):<\/strong> Linux (PostgreSQL \/ MySQL):<\/strong> T\u00e4ss\u00e4 on esimerkki VMwaren Ja vastaava Vaikka sovellustason kest\u00e4v\u00e4t tilannevedokset ovat parempia kuin standardit tilannevedokset, niihin liittyy silti VM Stun -riski. Turvallisin tapa tietokantojen varmuuskopiointiin on k\u00e4ytt\u00e4\u00e4 natiiveja, suoratoistavia varmuuskopiointity\u00f6kaluja, jotka toimivat riippumatta hypervisorista.<\/p>\n PostgreSQL (pg_basebackup):<\/strong><\/p>\n MySQL\/MariaDB (Percona XtraBackup \/ Mariabackup):<\/strong> SQL Server (T-SQL):<\/strong><\/p>\n P\u00e4ivitt\u00e4inen tilannevedos tai t\u00e4ysi varmuuskopio suojaa sinua vain siihen minuuttiin asti, jolloin se otettiin. Jos tietokantasi kaatuu klo 16:00 ja viimeisin tilannevedoksesi oli klo 02:00, menet\u00e4t 14 tuntia transaktiotietoja.<\/p>\n Todellisen yritystason kest\u00e4vyyden saavuttamiseksi sinun on yhdistett\u00e4v\u00e4 t\u00e4ydet sovellustason kest\u00e4v\u00e4t varmuuskopiot jatkuvaan lokiarkistointiin (varmuuskopioimalla WAL-, Redo- tai transaktiolokit muutaman minuutin v\u00e4lein). T\u00e4m\u00e4 mahdollistaa tietokannan palauttamisen tiettyyn minuuttiin tai jopa tiettyyn transaktio-ID:hen ennen katastrofia.<\/p>\n Mukautettujen pre-freeze-skriptien, natiivien dumppien cron-ajastusten ja lokien siirron hallinta kymmenill\u00e4 tietokantapalvelimilla on DevOps-tiimeille operatiivinen painajainen. T\u00e4ss\u00e4 kohtaa yritystason alusta, kuten CloudSave, muuttuu kriittiseksi.<\/p>\n CloudSave kuroo umpeen virtuaalistamisen ja tietokanta-arkkitehtuurin v\u00e4lisen kuilun. Sen sijaan, ett\u00e4 luotettaisiin sokeisiin hypervisor-tilannevedoksiin, CloudSave hy\u00f6dynt\u00e4\u00e4 sovellustietoisia agentteja, jotka integroituvat natiivisti SQL Serveriin, PostgreSQL:\u00e4\u00e4n, MySQL:\u00e4\u00e4n ja Oracleen.<\/p>\n Kun CloudSave k\u00e4ynnist\u00e4\u00e4 varmuuskopion: Ulkoistamalla sovellustason kest\u00e4vyyden monimutkaisuuden CloudSavelle, tietokantayll\u00e4pit\u00e4j\u00e4t ja j\u00e4rjestelm\u00e4yll\u00e4pit\u00e4j\u00e4t voivat taata tietojen eheyden uhraamatta tuotantoklustereidensa suorituskyky\u00e4 tai k\u00e4ytett\u00e4vyytt\u00e4.<\/p>\n Virtuaalikoneiden tilannevedokset ovat uskomaton ty\u00f6kalu infrastruktuurin hallintaan, mutta ne ovat pohjimmiltaan yhteensopimattomia transaktiotietokantojen ACID-vaatimusten kanssa. Kaatumisen kest\u00e4viin hypervisor-tilannevedoksiin luottaminen altistaa organisaatiosi rikkin\u00e4isille sivuille, rikkoutuneille replikointiketjuille ja katastrofaaliselle tietojen menetykselle.<\/p>\n Suojataksesi kriittisi\u00e4 tietojasi, sinun on toteutettava sovellustietoinen j\u00e4\u00e4dytys, k\u00e4ytett\u00e4v\u00e4 natiiveja tietokantojen varmuuskopiointimenetelmi\u00e4 ja yll\u00e4pidett\u00e4v\u00e4 jatkuvia transaktiolokiarkistoja. Ottamalla k\u00e4ytt\u00f6\u00f6n tarkoitukseen suunniteltuja yritystason varmuuskopiointiratkaisuja voit varmistaa, ett\u00e4 tietokantasi pysyv\u00e4t korkean k\u00e4ytett\u00e4vyyden tilassa, t\u00e4ysin palautettavissa ja t\u00e4ysin suojattuina.<\/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":[423],"tags":[3344,3638,3639,3640,3641,3642,3643],"class_list":["post-5479","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> tai .vhdx<\/code>) vain luku -tilaan ja luo uuden delta-levyn (erolevy). Kaikki my\u00f6hemm\u00e4t kirjoitukset ohjataan t\u00e4lle delta-levylle.<\/p>\nMiten transaktiotietokannat hallitsevat tilaa<\/h3>\n
\n
Vaaravy\u00f6hyke: Mit\u00e4 tapahtuu virtuaalikoneen tilannevedoksen aikana<\/h2>\n
Kaatumisen kest\u00e4vyys vs. sovellustason kest\u00e4vyys<\/h3>\n
D-asemalla<\/code> ja WAL E-asemalla<\/code>), hypervisor ei v\u00e4ltt\u00e4m\u00e4tt\u00e4 ota tilannevedosta molemmista levyist\u00e4 t\u00e4sm\u00e4lleen samalla mikrosekunnilla. Jos WAL-levyn tilannevedos otetaan murto-osasekunti datalevyn tilannevedoksen j\u00e4lkeen, tietokanta ei pysty t\u00e4sm\u00e4ytt\u00e4m\u00e4\u00e4n j\u00e4rjestysnumeroita palautuksen yhteydess\u00e4, mik\u00e4 johtaa kohtalokkaaseen korruptioon.<\/p>\n”VM Stun” -ilmi\u00f6n vaikutus korkean transaktiom\u00e4\u00e4r\u00e4n j\u00e4rjestelmiin<\/h3>\n
\n* Verkkoyhteydet katkeavat, mik\u00e4 aiheuttaa sovellusten aikakatkaisuja.
\n* Korkean k\u00e4ytett\u00e4vyyden klusterit (kuten SQL Server Always On, PostgreSQL Patroni tai MySQL Galera) missaavat syketarkistukset.
\n* Klusteri saattaa olettaa pys\u00e4ytetyn solmun olevan kuollut, mik\u00e4 k\u00e4ynnist\u00e4\u00e4 tarpeettoman ja h\u00e4iritsev\u00e4n vikasietoisuuden (split-brain-skenaario).<\/p>\nRikkin\u00e4iset sivut ja I\/O-kohdistusvirheet<\/h3>\n
K\u00e4yt\u00e4nn\u00f6n seuraukset tietyille tietokantamoottoreille<\/h2>\n
\n
pg_wal<\/code>-hakemistoon. Jos tilannevedos tallentaa datahakemiston ($PGDATA<\/code>) ja WAL-lokin ep\u00e4tahdissa, PostgreSQL ei k\u00e4ynnisty ja antaa virheen PANIC: could not locate a valid checkpoint record<\/code>.<\/li>\nibdata1<\/code>-tiedosto ja ib_logfile<\/code> tallennetaan ep\u00e4tahdissa, InnoDB-moottori kaatuu palautuksen yhteydess\u00e4.<\/li>\nParhaat k\u00e4yt\u00e4nn\u00f6t virtualisoitujen tietokantojen turvalliseen varmuuskopiointiin<\/h2>\n
1. Hy\u00f6dynn\u00e4 sovellustietoinen j\u00e4\u00e4dytys (VSS ja fsfreeze)<\/h3>\n
\nVarmista aina, ett\u00e4 varmuuskopiointiratkaisusi k\u00e4ytt\u00e4\u00e4 Microsoft Volume Shadow Copy Service (VSS) -palvelua. Kun VSS-tietoinen varmuuskopio k\u00e4ynnistet\u00e4\u00e4n, SQL Server VSS Writer j\u00e4\u00e4dytt\u00e4\u00e4 tietokannan I\/O:n, tyhjent\u00e4\u00e4 odottavat transaktiot levylle ja varmistaa, ett\u00e4 tilannevedos on t\u00e4ysin sovellustason kest\u00e4v\u00e4.<\/p>\n
\nLinuxilla ei ole natiivia vastinetta VSS:lle. Sovellustason kest\u00e4vyyden saavuttamiseksi sinun on k\u00e4ytett\u00e4v\u00e4 pre-freeze- ja post-thaw-skriptej\u00e4 yhdess\u00e4 hypervisorin vierasty\u00f6kalujen (esim. VMware Tools) kanssa.<\/p>\npre-freeze-script<\/code>-skriptist\u00e4 PostgreSQL 15+:lle, joka valmistelee tietokannan turvallisesti tilannevedosta varten:<\/p>\n#!\/bin\/bash\n# \/usr\/sbin\/pre-freeze-script\n# Varmista, ett\u00e4 skripti on suoritettava (chmod +x)\n\n# 1. K\u00e4ske PostgreSQL:\u00e4\u00e4 valmistautumaan varmuuskopiointiin\nsu - postgres -c \"psql -c \"SELECT pg_backup_start('vm_snapshot', true);\"\"\n\n# 2. Tyhjenn\u00e4 tiedostoj\u00e4rjestelm\u00e4n puskurit levylle\nsync\n\n# 3. J\u00e4\u00e4dyt\u00e4 tiedostoj\u00e4rjestelm\u00e4 (olettaen, ett\u00e4 data on hakemistossa \/var\/lib\/pgsql)\nfsfreeze -f \/var\/lib\/pgsql\n<\/code><\/pre>\npost-thaw-script<\/code>-skripti toimintojen jatkamiseksi:<\/p>\n#!\/bin\/bash\n# \/usr\/sbin\/post-thaw-script\n\n# 1. Poista tiedostoj\u00e4rjestelm\u00e4n j\u00e4\u00e4dytys\nfsfreeze -u \/var\/lib\/pgsql\n\n# 2. Ilmoita PostgreSQL:lle, ett\u00e4 varmuuskopiointi on valmis\nsu - postgres -c \"psql -c \"SELECT pg_backup_stop();\"\"\n<\/code><\/pre>\n2. K\u00e4yt\u00e4 tietokantojen natiiveja varmuuskopiointity\u00f6kaluja<\/h3>\n
pg_basebackup -h localhost -U replication_user -D \/mnt\/backups\/pg_backup -Ft -z -P\n<\/code><\/pre>\n
\nN\u00e4m\u00e4 ty\u00f6kalut ottavat ”kuumia”, ei-lukitsevia varmuuskopioita kopioimalla datatiedostot ja seuraamalla samanaikaisesti muutoksia redo-lokissa.<\/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. Toteuta Point-in-Time Recovery (PITR) lokiarkistoinnin avulla<\/h3>\n
Yritystason varmuuskopiointistrategiat CloudSaven avulla<\/h2>\n
\n1. Se kommunikoi suoraan tietokantamoottorin kanssa natiivien rajapintojen kautta (kuten VSS Windowsille tai natiivi WAL-suoratoisto Linuxille).
\n2. Se orkestroi muistipuskurien tyhjent\u00e4misen levylle aiheuttamatta h\u00e4iritsevi\u00e4 VM Stun -keskeytyksi\u00e4.
\n3. Se tallentaa datatiedostot turvallisesti ja hallitsee automaattisesti transaktiolokin katkaisun.
\n4. Se varmuuskopioi transaktiolokit jatkuvasti, mahdollistaen tarkan Point-in-Time Recovery (PITR) -palautuksen muutamalla klikkauksella.<\/p>\nJohtop\u00e4\u00e4t\u00f6s<\/h2>\n