Kasutajate juhend andmebaaside varukoopiate tegemiseks

– O, ükski varjupaik ei suuda meteoriidihitti taluda. Kuid teil, nagu kõigil, on varu, nii et võite muretseda.

Stanislav Lem, „Ijóna Tihhõ Tähtede päevikud“

Varundamine tähendab andmete koopia salvestamist kusagil väljaspool nende peamist salvestuskohta.

Varundamise peamine eesmärk on andmete taastamine nende kadumise korral. Seetõttu kuuleme sageli, et kui andmebaasil on koopia, saab sellelt alati andmeid taastada ja varundamine pole vajalik. Tegelikult aitab varundamine lahendada vähemalt kolme ülesannet, mida ei saa lahendada koopia abil, ning varukoopiat ilma varunduseta ei saa algatada.

Esiteks võimaldab varukoopia taastada andmeid pärast loogilist viga. Näiteks kustutab raamatupidaja seeria kannetest või andmebaasi administraator hävitab tabeliruumi. Mõlemad toimingud on andmebaasi seisukohalt täiesti legitimne ja replikatsiooniprotsess kordab neid koopiakandjas.

Teiseks, tänapäevased andmebaasisüsteemid on üsna usaldusväärsed tarkvarakompleksid, kuid aeg-ajalt juhtub siiski andmebaasi sisemiste struktuuride riknemist, mille järel andmetele ligipääs kaob. Mis on eriti kurb, toimub taoline rike tavaliselt siis, kui koormus on suur või kui paigaldatakse mõni uuendus. Kuid nii kõrge koormus kui ka regulaarne uuendamine viitavad sellele, et andmebaas pole just katsetuslik ja selles hoitavad andmed on väärtuslikud.

Lõpuks on kolmas ülesanne, mille lahendamine nõuab varukoopia olemasolu, andmebaasi kloonimine, näiteks testimiseesmärkidel.

Andmebaasi varundamine põhineb ühel kahest põhimõttest:

• Andmete tõstmine ja seejärel salvestamine vabatahtlikus formaadis;
• Andmebaasi failide oleku jäädvustamine ja ajakirjade salvestamine.

Vaadakem neid põhimõtteid ja neid rakendavaid tööriistu lähemalt.

Andmete väljatoomine

Iga andmebaasisüsteemiga kaasnevate tööriistade komplektis on kindlasti tööriistad andmete väljatoomiseks ja laadimiseks. Andmed salvestatakse kas tekstivormingus või konkreetse andmebaasi erivormingus. Allpool on toodud selliste tööriistade loetelu:

Binaarne vorming
Tekstivorming

Oracle
DataPump Export/DataPump Import
Ekspordi / Importi
SQL*Plus / SQL*Loader

PostgreSQL
pg_dump, pg_dumpall / pg_restore
pg_dump, pg_dumpall / psql

Microsoft SQL Server
bcp
bcp

DB2
väljatõmbamine / laadimine
väljatõmbamine / laadimine

MySQL

mysqldump, mysqlpump / mysql, mysqlimport

MongoDB
mongodump / mongorestore
mongoexport / mongoimport

Cassandra
nodetool snapshot / sstableloader
cqlsh

Tekstilisel formaadil on eelis, et seda saab redigeerida või isegi luua väliste programmide kaudu, samas kui binaarne formaat on hea, kuna see võimaldab andmete kiiret ekspordi ja impordi protsessi, säästes ressursse vormingute konverteerimise pealt.

Hoolimata andmete väljaviimise lihtsusest ja ilmsusest, kasutatakse seda meetodit harva koormatud tööstuslike andmebaaside резервimiseks. Siin on põhjused, miks andmete väljavõtmine ei sobi täieõiguslikuks varundamiseks:

• väljaviimise protsess tekitab märkimisväärset koormust allika süsteemile;
• väljaviimine võtab kaua aega – väljaviimise lõpuks on see juba ebaoluline;
• kõikide andmebaasi andmete kooskõlaliselt väljaviimine kõrge koormuse ajal on peaaegu võimatu, kuna andmehalduse süsteem peab salvestama oma seisundi pildi selle väljaviimise algusaegadel. Mida rohkem tehinguid on toimunud alates väljaviimise algusest, seda suurem on pildi maht (mitteaktuaalsed andmekoopiad PostgreSQL-is, undo-ruum Oracle'is, tempdb Microsoft SQL Serveris jne);
• väljaviimine säilitab andmete loogilise struktuuri, kuid ei säilita nende füüsilist struktuuri – tabelite füüsilise salvestamise parameetrid, indeksid jms.

Sellegipoolest on väljaviimisel ka eeliseid:

• kõrge valikulisus: saab väljaviia eraldi tabeleid, eraldi välju ja isegi eraldi ridasid;
• Väljaviidud andmeid saab laadida teise versiooniga andmebaasi ning kui väljaviimine on tehtud tekstiformaadis, siis ka teise andmebaasi.

Seega kasutatakse väljaviimist peamiselt selliste ülesannete täitmiseks nagu väikeste tabelite (näiteks viidete) varundamine või andmete komplektide levitamine rakenduse järgmise väljaandmisega.

Ainuüksi andmebaaside varundamise kõige levinum meetod on andmebaasi failide kopeerimine.

"Külm" andmebaasi failide säilitamine

Ilmselge idee on andmebaasi peatamine ja kõikide selle failide kopeerimine. Sellist varukoopiat nimetatakse "külmaks". Meetod on äärmiselt usaldusväärne ja lihtne, kuid sellel on kaks ilmselget puudust:

• «Külmalt» varukoopiast saab taastada vaid andmebaasi selle hetke seisundi, mil see peatati; pärast andmebaasi taaskäivitamist tehtud tehingud ei jõua «külma» varukoopia sisse;
• Kaugelt ei ole igal andmebaasil tehnoloogilist akent, millal andmebaasi peatada saab.

Kui «külm» varundamine sobib, siis tuleb meeles pidada, et

• «Külm» koopia peab mõnikord sisaldama ka ajalugu. Meetodid, kuidas määrata, millised ajakirjad peavad «külma» koopia sisse minema, on iga DBMS-i jaoks individuaalsed. Näiteks Oracle'is tuleb kopeerida nn online redo, mis on teatud hulk ajakirja faile spetsiaalses kataloogis, isegi siis, kui andmebaas on korrektselt peatatud. PostgreSQL-is tuleb salvestada kõik ajakirjad alates ajakirjast, mis sisaldab viimast kontrollpunkti, mille teave on juhtfailis.
• Andmebaasi kataloog võib sisaldada piisavalt suuri ajutiste tabeliruumi faile, mida ei ole tingimata vaja varukoopiasse kaasata. Üldiselt kehtib see märkuse ka «kuuma» varundamise kohta.

«Kuum» failide salvestamine

Enamik kaasaegsete andmebaaside varukoopiaid tehakse andmebaasi failide kopeerimise teel ilma andmebaasi peatamata. Siin on mitmeid probleeme:

• Kopeerimise hetkel ei pruugi andmebaasi sisu vastata failide sisule, kuna osa teabest on vahemälus ja pole veel kettale kirjutatud.
• Kopeerimise ajal võib andmebaasi sisu muutuda. Kui kasutatakse muudetavaid and strukture, muutub failide sisu, ja kui kasutatakse muutumatuid strukture, siis muutub failide komplekt: uued failid ilmuvad, samas kui vanad eemaldatakse.
• Kuna andmete kirjutamine andmebaasi ja DB failide lugemine ei ole kuidagi sünkroonitud, võib varundusprogramm lugeda vale lehe, millel pool on vana versioon lehelt ja teine pool – uus.

Kuna varukoopia peaks olema järjepidev, on igal DBMS-il käsu, mis teatab, et varundusprotsess on alanud. Süntaktiliselt võib see käsk välja näha erinev:

• Oracle'is on see eraldi käsk ALTER DATABASE/TABLESPACE BEGIN BACKUP;
• PostgreSQL-is – funktsioon pg_start_backup();
• Microsoft SQL Serveris ja DB2-s toimub varundamise valmistamine automaatselt BACKUP DATABASE käsu käivitamise protsessi käigus;
• MySQL Enterprise'is, Cassandra's ja MongoDB-s toimub valmistamine automaatselt väline utiliit – mysqlbackup, OpsCenter ja Ops Manager vastavalt.

Hoolimata süntaktilistest erinevustest näeb varundamise ettevalmistamise protsess välja samasugune.

Nii näeb välja varundamise ettevalmistamine andmebaasihaldussüsteemides, millel on muudetavad ketastruktuurid, st kõikides traditsioonilistes kettal põhinevates relatsioonilistes süsteemides:

1. Salvestatakse varundamise algushetk; varukoopia peab sisaldama andmebaasi žurnaleid alates sellest hetkest.
2. Teostatakse kontrollpunkt, see tähendab, et kõik andmefailide lehtedel toimunud muudatused salvestatakse enne salvestatud hetke kettale. See tagab, et žurnaalid varundamise algushetke enne taastamist ei ole vajalikud.
3. Lülitatakse sisse eriline žurnaliseerimisrežiim: kui andmeleht on esmakordselt pärast kettale laadimist muudetud, salvestab andmebaas muutuse žurnali asemel lehe tervikuna. Valmistamisprotsessi käigus sunnitakse kõik lehed kettale, mistõttu esmakordne muutus toimub alati kui käsk lehe tervikuna kaustas toimetatakse. Kui varundamise käigus leht uuesti kettale sunnitakse, toob järgmine selle muudatus samuti kaasa lehe täieliku koopia ilmumise žurnalis. See tagab, et kui andmefaili kopeerimisel leht muutub vigaseks, muudab žurnali kasutamine selle taas õigeks.
4. Ainult andmefaili päise muutmine on blokeeritud, st selle osa muutused, mida žurnaalides ei peegeldata. See tagab, et päis kopeeritakse õigesti ja seejärel rakendatakse andmefailile õigesti žurnaalid.

Pärast kõigi eespool nimetatud protseduuride lõpetamist on võimalik kopeerida andmefailid operaatori süsteemi vahenditega – cp, rsync ja teistega. Varundusrežiimi sisselülitamine vähendab andmebaasi jõudlust: esiteks suureneb logide maht ja teiseks, kui varundusrežiimi ajal peaks tekkima tõrge, muutub taastamine pikemaks, kuna andmefailide päised ei uuendata. Mida kiiremini varundamine lõpeb, seda parem andmebaasi jaoks, seega on asjakohane kasutada selliseid vahendeid nagu failisüsteemi hetkeseis (snapshot) või peegeldise katkemine (BCV) kettamassiivis. Mõned andmebaasisüsteemid (Oracle, PostgreSQL) jätavad administraatorile võimaluse ise valitud kopeerimismeetodi kasutamiseks, teised (Microsoft SQL Server) pakuvad liidest oma varundusutiliitide integreerimiseks failisüsteemide või andmemassiivide mehhanismidega.

Kuna varundamine on lõpule viidud, tuleb andmebaas viia tagasi tavapärasesse olekusse. Oracle'is tehakse seda käsuga ALTER DATABASE/TABLESPACE END BACKUP, PostgreSQL-is funktsiooni pg_stop_backup() kutsumisega ning teistes andmebaasides vastavate käskude või väliste teenuste sisemiste alprogrammidena.

Nii näeb välja ajadiagramm varundamisprotsessi kohta:

• Varundamiseks ettevalmistamine (begin backup) võtab aega, mõnikord märkimisväärselt. Isegi kui kasutatakse peegeldavaid mahte või failisüsteeme, mis võimaldavad hetkeseisude loomist, ei ole varundamisprotsess kohe käivituv.
• Koos andmefailidega on vajalik salvestada logid alates varundamise ettevalmistamise algusest kuni hetkeni, mil andmebaas naaseb normaalsesse olekusse.
• Selle varukoopia põhjal on võimalik taastuda andmebaasi normaalsesse olekusse tagasiviimise hetkel. Varundamine varasemasse hetke ei ole võimalik.

Andmebaasidega, mis kasutavad muutumatuid andmestruktuure (mäluseisud, LSM-puud), on olukord lihtsam. Varundamiseks ettevalmistamine koosneb järgmistest sammudest:

1. Mälu andmed kirjutatakse kettale.
2. Fikseeritakse failide nimekiri, mis kuuluvad varukoopiasse. Kuni varundamisprotsess ei ole lõpetatud, on andmebaasil keelatud need failid kustutada, isegi kui need muutuvad ebavajalikuks.

Kopeerimise lõpumängu signaaliga võib andmebaas, mille struktuurid on muutumatud, taas kustutada mitte vajalikud failid.

Taastamine ajas

Kopeerimine võimaldab taastada andmebaasi olek, milles see oli, kui taastus käsk tagas sisse kodulampi kopeerimise. Siiski võib õnnetus, mille järel taastamine on vajalik, juhtuda igal ajal. Andmebaasi oleku taastamise ülesanne mingis punktis ajas on seotud "taastamine ajas" (point-in-time recovery).

Selle võimaluse tagamiseks on vaja säilitada andmebaasi žurnaalid alates kopeerimise lõpust ja taastamise käigus jätkata žurnalide rakendamist taastatud kopeerimisse. Pärast seda, kui andmebaas on taastatud kopeerimisest kopeerimise hetkel, on andmebaasi (failide ja vahemälulehtede) olek tagatud ning seetõttu ei ole erilist žurnaliseerimist vaja. Rakendades žurnaleid kuni soovitud hetkeni, on võimalik saada andmebaasi olek igas ajas.

Kui kopeerimise taastamise kiirus on piiratud ainult ketta läbilaskevõimega, siis žurnalide rakendamise kiirus on tavaliselt piiratud protsessori jõudlusega. Kui peamises andmebaasis toimuvad muudatused paralleelselt, siis taastamise käigus viiakse kõik muudatused ellu järjestikku - vastavalt žurnalist lugemisele. Seega on taastamise aeg lineaarne, sõltudes sellest, kui kaugel taastamispunkt on kopeerimise lõpp-punktist. Seetõttu tuleb sageli teha täielikke kopeerimisi – vähemalt kord nädalas vähenenud tehingukoormusega andmebaaside jaoks ja kuni iga päev kõrge koormusega andmebaaside jaoks.

Inkrementaalne kopeerimine

Kuna soovitatakse kiirendada ajas taastamist, soovitakse, et oleks võimalik kopeerimist teha nii sageli kui võimalik, kuid samas mitte kasutada liigselt ketta ruumi ega üle koormata andmebaasi kopeerimise ülesannetega.

Probleemi lahendus on inkrementaalne kopeerimine, see tähendab ainult nende andmelehtede kopeerimine, mis on muutunud alates eelmisest kopeerimisest.
Inkrementaalne varukoopia on mõttekas ainult muudetud andmestruktuure kasutavate andmebaaside jaoks.

Inkrementi saab arvestada kas täisvarukoopia (kumulatiivne koopia) või mõne varasema koopia (diferentsiaalne koopia) alusel.

Kahjuks ei ole ühtset terminoloogiat ning erinevad tootjad kasutavad erinevaid termineid:

Diferentsiaalne
Kumulatiivne

Oracle
Diferentsiaalne
Kumulatiivne

PostgresPro
Incrementaalne
—

Microsoft SQL Server
—
Diferentsiaalne

IBM DB2
Delta
Incrementaalne

Kui olemas on inkrementaalsed koopiad, näeb taastamisprotsess punktist välja järgnev:

• taastatakse viimane täisvarukoopia, mis tehti enne taastamise hetke;
• täiskoopiale taastatakse inkrementaalsed koopiad;
• rakendatakse logisid varukoopia alguspunktist taastamispunktini.

Kumulatiivne koopia kiirendab taastamisprotsessi. Näiteks, et taastada andmebaasi seisund punktis T3 ja T4 vahel, tuleb taastada kaks inkrementaalset koopiat, kuid T4 järel taastamiseks piisab ainult ühest.
On ilmne, et ühe kumulatiivse koopia maht on väiksem kui mitme diferentsiaalse koopia maht, kuna mõned lehed on muutunud mitu korda ja iga inkrementaalne koopia sisaldab oma lehe versiooni.

Inkrementaalse koopia tegemiseks on kolm võimalust:

1. täiskoopiate loomine ja erinevuste arvutamine eelmise täiskoopiaga;
2. logide analüüs, muudetud lehtede loendi koostamine ja loendis sisalduvate lehtede varundamine;
3. muudetud lehtede pärimine andmebaasist.

Esimene meetod säästab ketta ruumi, kuid ei lahenda andmebaasi koormuse vähendamise probleemi. Veelgi enam, kui meil on täisvarukoopia, siis ei ole mõttekas seda inkrementaalseks muuta, kuna täiskoopiate taastamine on kiirem kui eelmise täiskoopia ja inkrementa taastamine. Ketta ruumi küsimuse lahendamise tuleks jätta spetsiaalsetele komponentidele, millel on sisseehitatud deduplikatsiooni mehhanismid. Need võivad olla nii spetsiaalsed andmemagamise seadmed (EMC DataDomain, HPE StorageWorks VLS, kogu NetApp'i tootesari) kui ka tarkvaratooted (ZFS, Veritas NetBackup PureFile, Windows Server Data Deduplication).

Teised ja kolmandad meetodid erinevad muudetud lehtede loendi määramise mehhanismi poolest. Logide analüüs on ressursinõudlikum ning selle rakendamiseks tuleb teada logifailide struktuuri. Küsida andmebaasilt, millised täpselt lehed on muutunud, on kõige lihtsam, kuid selleks peab andmebaasi juhtfunktsioon olema muudetud blokkide jälgimise funktsionaalsus (block change tracking).

Esmakordselt loodi inkrementaalse varundamise funktsionaalsus Oracle Recovery Manager (RMAN) tarkvaras, mis ilmus Oracle 8i versioonis. Oracle rakendas kohe muudetud blokkide jälgimist, seega pole logide analüüsi vajadust.

PostgreSQL ei jälgi muudetud bloke, mistõttu Venemaa ettevõtte Postgres Professional välja töötatud tööriist pg_probackup määrab muudetud lehed logi analüüsi teel. Siiski on ettevõte välja andnud ka andmebaasi PostgresPro, mis sisaldab laiendust ptrack, mis jälgib lehtede muutusi. Kui kasutada pg_probackup'i koos PostgresPro andmebaasiga, küsib tööriist muudetud lehti andmebaasilt - samuti nagu RMAN.

Microsoft SQL Server jälgib muudetud lehti sama nagu Oracle, kuid BACKUP käsk võimaldab teha ainult täis- ja kumulatiivseid varukoopiaid.

DB2-l on võimalus jälgida muudetud lehti, kuid see on vaikimisi välja lülitatud. Pärast lubamist võimaldab DB2 teha täis-, diferentseeritud ja kumulatiivseid varukoopiaid.

Oluline erinevus selles jaotises kirjeldatud tööriistade (välja arvatud pg_probackup) ja failipõhiste varundustööriistade vahel on see, et nad küsivad andmebaasilt lehtede pilte, mitte ei loe andmeid ise kõvakettalt. Selle lähenemise puuduseks on väike lisakoormus andmebaasile. Kuid see puudus kompenseeritakse täielikult, kuna loetud leht on alati korrektne, mis tähendab, et varundamise ajal ei ole vaja erilise logimistari aktiveerimist.

Veel kord märkige, et inkrementaalsete koopiate olemasolu ei tühista nõudeid logide olemasolu suhtes, et taastada andmeid suvalisse ajahetke. Seetõttu salvestatakse tööstuslikes andmebaasides logid pidevalt välisele kandjale ning täis- ja/või inkrementaalsed varukoopiad luuakse ajakava järgi.

Tänapäeva parim rakendus inkrementaalse varundamise ideele on riist- ja tarkvarakompleks (Oracle'i terminoloogias - engineered system) Zero Data Loss Recovery Appliance - Oracle'i spetsialiseeritud lahendus oma andmebaaside varundamiseks. Kompleks on klaster serverid suure ketta mahuga, millele on installitud muudetud Recovery Manager tarkvara versioon ja mis suudab töötada nii teiste Oracle'i riist- ja tarkvarakompleksidega (Database Appliance, Exadata, SPARC Supercluster) kui ka Oracle'i andmebaasidega traditsioonilisel infrastruktuuril. Erinevalt 'tavalisest' RMAN-ist rakendab ZDLRA 'igavese inkrementi' (incremental forever) kontseptsiooni. Süsteem loob ühe korra täiskope andmebaasist ning seejärel teeb ainult inkrementaalsed koopiad. Lisa RMAN moodulid võimaldavad koopiaid kombineerida, luues uusi täiskoopiaid inkrementaalsetest.

Eesti arendajate auks tuleb märkida, et ka pg_probackup oskab inkrementaalseid koopiaid ühendada.

Erinevalt paljusid sarnaseid küsimusi, küsimusel 'milline varundamismeetod on parem' on selge vastus - parim on kasutatavale andmebaasisüsteemile omane utiliit, mis võimaldab inkrementaalset varundamist.

Andmebaasi administraatori jaoks on palju olulisemad küsimused varundamisstrateegia valik ja andmebaaside varundamisvahendite integreerimine ettevõtte infrastruktuuri. Kuid need küsimused jäävad väljapoole selle artikli ulatust.

Allikas: habr.com