- Oh, nijedno sklonište ne može izdržati udar meteorita. Ali i vi, kao i svi ostali, imate rezervu, tako da ne morate da brinete.
Stanislav Lem, „Zvezdani dnevnici Ijona Tihog”
Sigurnosna kopija se odnosi na spremanje kopije podataka negdje izvan njihove primarne lokacije za pohranu.
Glavna svrha sigurnosne kopije je vraćanje podataka nakon što su izgubljeni. S tim u vezi, često čujete da ako imate repliku baze podataka, uvijek možete vratiti podatke iz nje i nema potrebe za sigurnosnom kopijom. Zapravo, sigurnosna kopija vam omogućava da riješite najmanje tri problema koja se ne mogu riješiti upotrebom replike, a replika se ne može inicijalizirati bez sigurnosne kopije.
Prvo, sigurnosna kopija vam omogućava da oporavite podatke nakon logičke greške. Na primjer, računovođa je izbrisao grupu transakcija ili je administrator baze podataka uništio prostor tablice. Obje operacije su potpuno legalne sa stanovišta baze podataka, a proces replikacije će ih reproducirati u bazi podataka replika.
Drugo, savremeni DBMS-ovi su vrlo pouzdani softverski sistemi, ali povremeno dolazi do oštećenja internih struktura baze podataka, nakon čega se gubi pristup podacima. Ono što je posebno uvredljivo je da se takvo kršenje obično dešava pod velikim opterećenjem ili prilikom instaliranja neke vrste ažuriranja. Ali i veliko opterećenje i redovna ažuriranja ukazuju na to da baza podataka nipošto nije testna baza podataka i da su podaci pohranjeni u njoj vrijedni.
Konačno, treći zadatak, za čije rješenje je potrebna rezervna kopija, je kloniranje baze podataka, na primjer, za potrebe testiranja.
Sigurnosna kopija baze podataka je na ovaj ili onaj način zasnovana na jednom od dva principa:
- Uzorkovanje podataka i naknadno pohranjivanje u prilagođeni format;
- Snimak datoteka baze podataka i spremanje dnevnika.
Pogledajmo bliže ove principe i alate koji ih implementiraju.
Učitavanje podataka
Skup uslužnih programa uključenih u bilo koji DBMS mora uključivati alate za upload i učitavanje podataka. Podaci se pohranjuju ili u tekstualnom formatu ili u binarnom formatu specifičnom za određeni DBMS. Tabela u nastavku daje listu takvih alata:
Binarni format
Format teksta
proročanstvo
DataPump Export/DataPump Import
Izvoz / uvoz
SQL*Plus/SQL*Loader
PostgreSQL
pg_dump, pg_dumpall/pg_restore
pg_dump, pg_dumpall/psql
Microsoft SQLServer
bcp
bcp
DB2
istovar/utovar
istovar/utovar
MySQL
mysqldump, mysqlpump/mysql, mysqlimport
MongoDB
mongodump/mongorestore
mongoexport/mongoimport
Cassandra
nodetool snapshot/stableloader
cqlsh
Dobra stvar kod formata teksta je to što ga mogu uređivati ili čak kreirati eksterni programi, a binarni format je zauzvrat dobar jer vam omogućava brže učitavanje i preuzimanje podataka štedeći resurse na konverziji formata.
Unatoč jednostavnosti i očiglednosti ideje preuzimanja podataka, ova metoda se rijetko koristi za sigurnosno kopiranje učitanih industrijskih baza podataka. Evo razloga zašto istovar nije pogodan za potpunu sigurnosnu kopiju:
- proces istovara stvara značajno opterećenje na izvornom sistemu;
- istovar traje dosta vremena - do završetka istovara više neće biti relevantan;
- Skoro je nemoguće izvršiti koordinirano rasterećenje cijele baze podataka pod velikim opterećenjem, budući da je DBMS prisiljen pohraniti snimku svog stanja u trenutku kada počinje istovar. Što je više transakcija završeno od početka otpremanja, to je veća veličina snimka (nebitne kopije podataka u PostgreSQL-u, poništiti prostor u Oracleu, tempdb u Microsoft SQL Serveru, itd.);
- unloading čuva logičku strukturu podataka, ali ne čuva njihovu fizičku strukturu - parametre fizičkog skladištenja tabela, indeksa itd.
Međutim, učitavanje ima i svojih prednosti:
- visoka selektivnost: možete preuzeti pojedinačne tabele, pojedinačna polja, pa čak i pojedinačne redove;
- preuzeti podaci mogu se učitati u bazu podataka druge verzije, a ako se preuzimanje vrši u tekstualnom formatu, onda u drugu bazu podataka.
Dakle, učitavanje se koristi uglavnom za zadatke kao što je pravljenje rezervnih kopija malih tabela (na primjer, direktorija) ili distribucija skupova podataka sa sljedećim izdanjem aplikacije.
Najčešći način izrade sigurnosne kopije baze podataka je kopiranje datoteka baze podataka.
Hladno skladištenje datoteka baze podataka
Očigledna ideja je zaustaviti bazu podataka i kopirati sve njene datoteke. Ova sigurnosna kopija se naziva “hladna” sigurnosna kopija. Metoda je izuzetno pouzdana i jednostavna, ali ima dva očita nedostatka:
- Iz “hladne” sigurnosne kopije možete vratiti samo stanje baze podataka koje je bilo u vrijeme gašenja; transakcije napravljene nakon ponovnog pokretanja baze podataka neće biti uključene u “hladnu” rezervnu kopiju;
- Nema svaka baza podataka tehnološki prozor kada se baza podataka može zaustaviti.
Ako vam odgovara “hladno” sigurnosno kopiranje, morate to zapamtiti
- Hladna kopija ponekad mora uključivati dnevnike. Metode za određivanje dnevnika koji treba da idu u “hladnu” kopiju su individualni za svaki DBMS. Na primjer, u Oracleu je potrebno kopirati takozvani online redo, odnosno fiksni broj log datoteka u poseban direktorij, čak i kada je baza podataka ispravno zaustavljena. U PostgreSQL-u morate sačuvati sve evidencije počevši od dnevnika koji sadrži posljednju kontrolnu tačku, informacije o kojoj se nalaze u kontrolnoj datoteci.
- Direktorij baze podataka može sadržavati privremene datoteke prostora tablice koje su dovoljno velike da ih ne treba uključiti u sigurnosnu kopiju. Inače, ova primjedba vrijedi i za vruće sigurnosne kopije.
Vruće čuvanje fajlova
Većina modernih sigurnosnih kopija baze podataka se izvodi kopiranjem datoteka baze podataka bez zaustavljanja baze podataka. Ovdje postoji nekoliko problema:
- Kada započne kopiranje, sadržaj baze podataka se možda neće podudarati sa sadržajem datoteka, jer se neke informacije nalaze u kešu i još nisu zapisane na disk.
- Tokom kopiranja, sadržaj baze podataka se može promijeniti. Ako se koriste promjenjive strukture podataka, sadržaj datoteka se mijenja, a kada se koriste nepromjenjive strukture, skup datoteka se mijenja: pojavljuju se nove datoteke, a stare se brišu.
- Budući da upisivanje podataka u bazu podataka i čitanje datoteka baze podataka nisu ni na koji način sinkronizirani, backup program može pročitati pogrešnu stranicu, u kojoj će polovina biti sa stare verzije stranice, a druga polovina iz nove.
Da bi sigurnosna kopija bila konzistentna, svaki DBMS ima naredbu koja obavještava da je proces izrade sigurnosne kopije počeo. Sintaktički, ova naredba može izgledati drugačije:
- u Oracleu ovo je zasebna naredba ALTER DATABASE/TABLESPACE BEGIN BACKUP;
- u PostgreSQL – funkcija pg_start_backup();
- U Microsoft SQL Serveru i DB2, priprema za sigurnosno kopiranje se izvodi implicitno tijekom izvođenja naredbe BACKUP DATABASE;
- u MySQL Enterprise, Cassandra i MongoDB, priprema se implicitno izvodi od strane eksternog uslužnog programa - mysqlbackup, OpsCenter i Ops Manager, respektivno.
Uprkos sintaksičkim razlikama, proces pripreme za sigurnosnu kopiju izgleda isto.
Ovako izgleda priprema za backup u DBMS-u sa promjenjivim strukturama diska, odnosno u svim tradicionalnim disk relacionim sistemima:
- Pamti se trenutak pokretanja sigurnosne kopije; sigurnosna kopija će morati sadržavati dnevnike baze podataka od ovog trenutka nadalje.
- Izvodi se kontrolna tačka, to jest, sve promjene koje su se dogodile na stranicama podataka prije zapamćenog trenutka se prebacuju na disk. Ovo osigurava da nikakvi zapisnici nisu potrebni prije nego što sigurnosna kopija počne tokom oporavka.
- Omogućen je poseban način evidentiranja: ako se stranica s podacima promijenila po prvi put nakon učitavanja s diska, tada će umjesto upisivanja promjena stranice u dnevnik, baza podataka upisati tu cijelu stranicu. Prilikom izvođenja postupka pripreme, sve stranice se ispuštaju na disk, tako da će se prilikom prve promjene cijeli blok uvijek upisati u dnevnik. Ali ako se stranica ponovo izbaci na disk tokom procesa izrade sigurnosne kopije, sljedeća promjena na njoj će također rezultirati pojavom pune kopije stranice u dnevniku. Ovo osigurava da ako se ispostavi da stranica nije tačna prilikom kopiranja datoteke s podacima, primjena dnevnika će je ponovo učiniti ispravnom.
- Blokiraju se promjene zaglavlja datoteke podataka, odnosno onaj dio čije promjene se ne odražavaju u evidenciji. Ovo osigurava da je zaglavlje ispravno kopirano i da se zapisnici ispravno primjenjuju na datoteku podataka.
Nakon što su sve gore navedene procedure završene, možete kopirati datoteke podataka koristeći alate operativnog sistema - cp, rsync i druge. Omogućavanje režima sigurnosne kopije smanjuje performanse baze podataka: prvo, povećava se volumen dnevnika, a drugo, ako se iznenada dogodi kvar u sigurnosnom načinu rada, oporavak će trajati duže jer se zaglavlja datoteka s podacima ne ažuriraju. Što se rezervna kopija brže završi, to je bolje za bazu podataka, pa je prikladno koristiti takve alate kao što su snimak sistema datoteka ili razbijanje ogledala (BCV) u nizu diskova. Neki DBMS-ovi (Oracle, PostgreSQL) ostavljaju administratoru mogućnost da samostalno odabere metodu kopiranja, drugi (Microsoft SQL Server) pružaju interfejs za integraciju sopstvenih uslužnih programa za pravljenje rezervnih kopija sa sistemom datoteka ili mehanizmima skladištenja.
Nakon što je sigurnosna kopija završena, morate vratiti bazu podataka u njeno normalno stanje. U Oracleu se to radi pomoću naredbe ALTER DATABASE/TABLESPACE END BACKUP, u PostgreSQL-u pozivanjem funkcije pg_stop_backup(), au drugim bazama podataka internim rutinama odgovarajućih naredbi ili eksternih servisa.
Evo kako izgleda vremenska traka procesa pravljenja rezervnih kopija:
- Priprema za rezervnu kopiju zahtijeva vrijeme, ponekad i dosta vremena. Čak i ako se koriste zrcaljeni volumeni ili sistemi datoteka koji podržavaju snapshot, proces sigurnosne kopije neće biti trenutan.
- Uz fajlove sa podacima potrebno je pohraniti logove od trenutka kada počnete sa pripremama za backup do trenutka kada se baza podataka vrati u normalno stanje.
- Možete vratiti iz ove sigurnosne kopije u trenutku kada se baza vrati u normalno stanje. Vraćanje na raniju tačku nije moguće.
Sa bazama podataka koje koriste nepromjenjive strukture podataka (snimke memorije, LSM stabla), situacija je jednostavnija. Priprema za sigurnosnu kopiju sastoji se od sljedećih koraka:
- Podaci iz memorije se prebacuju na disk.
- Snima se lista datoteka uključenih u sigurnosnu kopiju. Dok se proces sigurnosne kopije ne završi, bazi podataka je zabranjeno brisanje ovih datoteka, čak i ako više nisu potrebne.
Nakon signala da je sigurnosna kopija završena, baza podataka sa nepromjenjivim strukturama može ponovo izbrisati nepotrebne datoteke.
Oporavak do tačke
Rezervna kopija vam omogućava da vratite stanje baze podataka do trenutka kada je komanda za povratak iz backup moda završena. Međutim, nesreća koja zahtijeva oporavak može se dogoditi u bilo kojem trenutku. Zadatak vraćanja stanja baze podataka u proizvoljnom trenutku naziva se “oporavak u trenutku”.
Da biste bili sigurni da je to moguće, trebali biste sačuvati evidencije baze podataka počevši od kraja sigurnosne kopije, a tokom procesa oporavka, nastavite primjenjivati evidencije na vraćenu kopiju. Nakon što se baza podataka vrati iz rezervne kopije u trenutku kada je kopiranje završeno, stanje baze podataka (fajlovi i keširane stranice) je zagarantovano ispravno, tako da poseban način evidentiranja nije potreban. Primjenom dnevnika u pravom trenutku možete dobiti stanje baze podataka u bilo kojem trenutku.
Dok je brzina kojom se rezervna kopija može vratiti ograničena samo propusnim opsegom diska, brzina kojom se zapisnici mogu primijeniti je obično ograničena performansama procesora. Ako se promjene događaju paralelno u glavnoj bazi podataka, tada se tijekom oporavka sve promjene izvode uzastopno - redoslijedom kojim se čitaju iz dnevnika. Dakle, vrijeme oporavka linearno ovisi o tome koliko je točka oporavka udaljena od krajnje točke sigurnosne kopije. Zbog toga je potrebno dosta često praviti potpune sigurnosne kopije - barem jednom tjedno za baze podataka s malim opterećenjem transakcija i do dnevnih kopija visoko opterećenih baza podataka.
Inkrementalna sigurnosna kopija
Da bih do neke tačke ubrzao oporavak, želio bih da mogu raditi sigurnosne kopije što je češće moguće, ali da u isto vrijeme ne zauzimam dodatni prostor na disku i ne učitavam bazu podataka zadacima sigurnosnog kopiranja.
Rješenje problema je inkrementalno sigurnosno kopiranje, odnosno kopiranje samo onih stranica podataka koje su se promijenile od prethodne sigurnosne kopije.
Inkrementalne sigurnosne kopije imaju smisla samo za DBMS-ove koji koriste promjenjive strukture podataka.
Povećanje se može računati ili od pune rezervne kopije (kumulativna kopija) ili od bilo koje prethodne kopije (diferencijalna kopija).
Nažalost, ne postoji jedinstvena terminologija, a različiti proizvođači koriste različite termine:
diferencijal
Kumulativno
proročanstvo
Diferencijal
Kumulativno
PostgreSQL
Inkrementalno
-
Microsoft SQLServer
-
Diferencijal
IBM DB2
delta
Inkrementalno
Ako postoje inkrementalne kopije, proces vraćanja na tačku je sljedeći:
- posljednja potpuna sigurnosna kopija napravljena prije obnavljanja;
- inkrementalne kopije se vraćaju na potpunu kopiju;
- dnevnici se skupljaju od početne točke sigurnosne kopije do točke oporavka.
Kumulativna kopija ubrzava proces oporavka. Tako, na primjer, da biste vratili stanje baze podataka na tačku između T3 i T4, potrebno je vratiti dvije inkrementalne kopije, a vratiti na tačku nakon T4 samo jednu.
Očigledno je da je veličina jedne kumulativne kopije manja od veličine nekoliko različitih kopija, jer su se neke stranice mijenjale nekoliko puta, a svaka inkrementalna kopija sadrži različitu verziju stranice.
Postoje tri načina za kreiranje inkrementalne kopije:
- kreiranje pune kopije i izračunavanje razlike u odnosu na prethodnu potpunu kopiju;
- raščlanjivanje dnevnika, kreiranje liste promenjenih stranica i pravljenje rezervnih kopija stranica uključenih u listu;
- ispitivanje promijenjenih stranica u bazi podataka.
Prva metoda štedi prostor na disku, ali ne smanjuje opterećenje baze podataka. Štaviše, ako imamo potpunu sigurnosnu kopiju, njeno pretvaranje u inkrementalnu je besmisleno, jer je vraćanje potpune sigurnosne kopije brže od vraćanja prethodne potpune sigurnosne kopije i inkrementalne. Bolje je delegirati zadatak uštede prostora na disku ovim pristupom specijaliziranim komponentama s ugrađenim mehanizmima deduplikacije. To mogu biti ili namjenski sistemi za pohranu podataka (EMC DataDomain, HPE StorageWorks VLS, cijela NetApp linija) ili softverski proizvodi (ZFS, Veritas NetBackup PureFile, Windows Server Deduplikacija podataka).
Druga i treća metoda se razlikuju po mehanizmu za određivanje liste promijenjenih stranica. Parsiranje dnevnika zahtijeva više resursa, plus da biste ga implementirali morate znati strukturu datoteka dnevnika. Najlakši način je da pitate samu bazu podataka koje su stranice promijenjene, ali za to DBMS kernel mora imati funkciju praćenja promjena blokova.
Funkcionalnost inkrementalnog sigurnosnog kopiranja je prvi put predstavljena u softveru Oracle Recovery Manager (RMAN), predstavljenom u izdanju Oracle 8i. Oracle je odmah implementirao praćenje promijenjenih blokova, tako da nema potrebe za raščlanjivanjem dnevnika.
PostgreSQL ne prati modifikovane blokove, tako da pg_probackup uslužni program, koji je razvila ruska kompanija Postgres Professional, utvrđuje izmenjene stranice analizom dnevnika. Međutim, kompanija takođe isporučuje PostgresPro DBMS, koji uključuje ekstenziju ptrack koja prati promene stranica. Kada koristite pg_probackup sa PostgresPro DBMS-om, uslužni program traži promijenjene stranice iz same baze podataka - potpuno isto kao RMAN.
Microsoft SQL Server, poput Oraclea, prati promijenjene stranice, ali komanda BACKUP vam omogućava samo da napravite potpune i kumulativne sigurnosne kopije.
DB2 ima mogućnost praćenja promijenjenih stranica, ali je po defaultu onemogućena. Jednom omogućen, DB2 će dozvoliti pune, diferencijalne i kumulativne sigurnosne kopije.
Važna razlika između alata opisanih u ovom odeljku (osim pg_probackup) i alata za pravljenje rezervnih kopija datoteka je u tome što oni zahtevaju slike stranica iz baze podataka umesto da sami čitaju podatke sa diska. Nedostatak ovog pristupa je malo dodatno opterećenje baze. Međutim, ovaj nedostatak je više nego nadoknađen činjenicom da je stranica uvijek ispravna, tako da nema potrebe za omogućavanjem posebnog načina evidentiranja tokom izrade sigurnosne kopije.
Ponovo imajte na umu da prisustvo inkrementalnih kopija ne eliminiše zahtjev da evidencije budu dostupne za oporavak do proizvoljnog trenutka. Stoga se u industrijskim bazama podataka dnevnici stalno prepisuju na eksterne medije, a sigurnosne kopije, pune i/ili inkrementalne, kreiraju se prema rasporedu.
Najbolja implementacija ideje inkrementalnog sigurnosnog kopiranja danas je Zero Data Loss Recovery Appliance, hardverski i softverski sistem (u Oracle terminologiji, inženjerski sistem) – specijalizirano Oracle rješenje za sigurnosno kopiranje vlastite baze podataka. Sistem je klaster. serveri ZDLRA ima velike diskovne kapacitete i pokreće modificiranu verziju Recovery Manager softvera. Može raditi s drugim Oracle hardverskim i softverskim sistemima (Database Appliance, Exadata, SPARC Supercluster), kao i s Oracle bazama podataka koje rade na tradicionalnoj infrastrukturi. Za razliku od "običnog" RMAN-a, ZDLRA implementira koncept "inkrementalnog zauvijek". Sistem kreira punu kopiju baze podataka jednom, a zatim pravi samo inkrementalne kopije. Dodatni RMAN moduli vam omogućavaju spajanje kopija, kreirajući nove pune kopije od inkrementalnih.
Za čast ruskih programera, treba napomenuti da pg_probackup takođe može spojiti inkrementalne kopije.
Za razliku od mnogih sličnih pitanja, pitanje „koja je metoda sigurnosne kopije bolja“ ima jasan odgovor - najbolja opcija je uslužni program koji je izvoran za DBMS koji se koristi, a koji pruža mogućnost inkrementalnog pravljenja sigurnosnih kopija.
Za administratora baze podataka mnogo su važnija pitanja izbora strategije pravljenja rezervnih kopija i integracije alata za pravljenje rezervnih kopija baze podataka u korporativnu infrastrukturu. Ali ova pitanja su izvan okvira ovog članka.
izvor: www.habr.com
