🥇Udhëzuesi për kopjimin e bazave të të dhënave

– O, asnjë strehim nuk do të përballonte një meteor. Por gjithsesi, ju si të gjithë të tjerët keni një rezervë, kështu që mund të qetësoheni.
Stanislav Lem, «Diarët e Yjeve të Ion Tikhit»

Kopjimi rezervë nënkupton ruajtjen e një kopjeje të të dhënave diku jashtë vendndodhjes kryesore të ruajtjes së tyre.

Qëllimi kryesor i kopjimit rezervë është rindërtimi i të dhënave pas humbjes së tyre. Për këtë arsye, shpesh dëgjohet se në prani të një replike të bazës së të dhënave, gjithmonë mund të rikuperoni të dhënat, prandaj kopjimi rezervë nuk është i nevojshëm. Në të vërtetë, kopjimi rezervë lejon zgjidhjen e të paktën tri detyrave, të cilat nuk mund të zgjidhen përmes një replike, dhe gjithashtu nuk mund të inicializohet një replikë pa një kopje rezervë.

Së pari, një kopje rezervë lejon rikuperimin e të dhënave pas një gabimi logjik. Për shembull, një kontabilist fshin një grup transaksionesh, ose një administrator i bazës së të dhënave shkatërron një hapësirë tabelar. Të dyja operacionet janë krejt legjitime nga perspektiva e bazës së të dhënave, dhe procesi i replikimit do t'i riprodhojë ato në bazën e replikës.

Së dyti, sistemet moderne të menaxhimit të bazave të të dhënave janë komplekse mjaft të besueshme, megjithatë ndonjëherë ndodhin dëmtime të strukturave të brendshme të bazës së të dhënave, pas të cilave humbet qasja në të dhëna. Çka është veçanërisht e keqe, një shkelje e tillë ndodh zakonisht gjatë ngarkesës së lartë ose gjatë instalimit të ndonjë azhurnimi. Por si ngarkesa e lartë ashtu edhe azhurnimet e rregullta tregojnë se baza e të dhënave nuk është thjesht një testim dhe të dhënat e ruajtura aty janë të rëndësishme.

Së fundmi, detyra e tretë, zgjidhja e së cilës kërkon një kopje rezervë, është klonimi i bazës, për shembull, për qëllime testimi.

Kopjimi rezervë i bazave të të dhënave në një farë mënyre mbështetet në një nga dy parimet:

Përzgjedhja e të dhënave me ruajtjen e mëpasme në një format të rastësishëm;
Fotografia e gjendjes së skedarëve të bazës së të dhënave dhe ruajtja e regjistrave.

Le të shikojmë këto principe dhe mjetet që i realizojnë ato më në detaje.

Eksportimi i të dhënave

Në grupin e mjeteve që i bashkëngjiten çdo sistemi të menaxhimit të bazave të të dhënave, gjithmonë ka mjete për eksportimin dhe importimin e të dhënave. Të dhënat ruhen ose në format tekst, ose në një format binar që është specifik për sistemin e menaxhimit të bazave të të dhënave përkatës. Në tabelën më poshtë, është përgatitur një listë e tillë instrumentesh:

Formati binar
Formati tekstual

Oracle
Export/DataPump Import
Eksport/Import
SQL*Plus/SQL*Loader

PostgreSQL
pg_dump, pg_dumpall/pg_restore
pg_dump, pg_dumpall/psql

Microsoft SQL Server
bcp
bcp

DB2
shkarkim/ngarkim
shkarkim/ngarkim

MySQL

mysqldump, mysqlpump/mysql, mysqlimport

MongoDB
mongodump/mongorestore
mongoexport/mongoimport

Cassandra
nodetool snapshot/sstableloader
cqlsh

Formati tekstual është i mirë për shkak se mund të editohet ose madje edhe krijohet nga programe të jashtme, ndërsa formati binar është i mirë sepse lejon ngarkimin dhe shkarkimin më të shpejtë të të dhënave duke kursyer burimet në transformimin e formateve.

Pavarësisht thjeshtësisë dhe qartësisë së ideës së shkarkimit të të dhënave, ky metod përdoret rrallë për rezervimin e bazave të dhënash industriale të ngarkuara. Ja disa arsye pse shkarkimi nuk është i përshtatshëm për një rezervë të plotë:

procesi i shkarkimit krijon një ngarkesë të konsiderueshme në sistemin burim;
shkarkimi merr shumë kohë - në momentin që përfundon, ai do të jetë tashmë i papërshtatshëm;
të bësh një shkarkim të qëndruar të tërë bazës së të dhënave nën ngarkesë të lartë është praktikisht e pamundur, për shkak se DBMS është e detyruar të ruajë një pamje të gjendjes së saj në momentin e fillimit të shkarkimit. Sa më shumë transaksione të jenë kryer që nga fillimi i shkarkimit, aq më i madh është volumi i pamjes (kopjeve të papërshtatshme të të dhënave në PostgreSQL, hapësira undo në Oracle, tempdb në Microsoft SQL Server, etj.);
shkarkimi ruan strukturën logjike të të dhënave, por nuk ruan strukturën e tyre fizike - parametrat e ruajtjes fizike të tavolinave, indekset etj.

Megjithatë, shkarkimi ka gjithashtu avantazhe:

zgjedhshmëria e lartë: mund të shkarkosh tavolina të veçanta, fusha të veçanta dhe madje edhe rreshta të veçanta;
të dhënat e shkarkuara mund të ngarkohen në një bazë të dhënash të versionit tjetër, dhe nëse shkarkimi është bërë në format tekstual, edhe në një bazë të dhënash tjetër.

Kështu, shkarkimi përdoret kryesisht për detyra si rezervimi i tavolinave të vogla (p.sh., dyshime) ose shpërndarja e grupeve të të dhënave me një lëshim të ri të aplikacionit.

Metoda më e zakonshme e rezervimit të bazave të dhënash është kopjimi i skedarëve të bazës.

Kopjimi "i ftohtë" i skedarëve të bazës së të dhënash

Ideja e qartë - ndaloni bazën e të dhënash dhe kopjoni të gjithë skedarët e saj. Kjo lloj rezervë quhet "e ftohtë". Ky metod është jashtëzakonisht i besueshëm dhe i thjeshtë, por ka dy disavantazhe të qarta:

nga një kopje rezervë "të ftohtë" mund të rikuperohet vetëm gjendja e bazës së të dhënave që ishte në momentin e ndalimit; transaksionet e kryera pas rinisjes së bazës, nuk do të përfshihen në kopjen rezervë "të ftohtë";
nuk ka shumë baza të të dhënave që kanë një dritare teknologjike, kur baza mund të ndalojë.

Nëse kopjimi "i ftohtë" ju përshtatet, duhet të mbani mend se

kopja "e ftohtë" ndonjëherë duhet të përfshijë edhe regjistrat. Metodat për të përcaktuar regjistrat që duhet të përfshihen në kopjen "e ftohtë" janë të veçanta për çdo DBMS. Për shembull, në Oracle është e nevojshme të kopjohen regjistrat online redo, që do të thotë një numër të caktuar skedarësh regjistrash në një katalog të posaçëm, madje edhe atëherë kur baza është ndaluar saktësisht. Në PostgreSQL duhet të ruhet të gjithë regjistrat që fillojnë nga regjistri, që përmban pikën e fundit të kontrollit, informacioni për të cilin është në skedarin menaxhues.
katalogu i bazës së të dhënave mund të përmbajë skedarë mjaft të mëdhenj të hapësirave të përkohshme të tabelave, të cilat nuk janë domosdoshmërisht të përfshihen në kopjen rezervë. Nga ana tjetër, kjo vërejtje është e vërtetë edhe për kopjimin "e nxehtë".

"Kopjimi i nxehtë" i skedarëve

Shumica e kopjeve rezervë të bazave të të dhënave moderne kryhen duke kopjuar skedarët e bazës së të dhënave pa ndalur bazën. Këtu shihen disa probleme:

Në momentin e fillimit të kopjimit, përmbajtja e bazës së të dhënave mund të mos përputhet me përmbajtjen e skedarëve, pasi një pjesë e informacionit është në memorie dhe ende nuk është shkruar në disk.
Gjatë kopjimit, përmbajtja e bazës mund të ndryshojë. Nëse përdoren struktura të dhënash të ndryshueshme, përmbajtja e skedarëve ndryshon, dhe kur përdoren struktura të pandryshueshme, seti i skedarëve ndryshon: skedarë të rinj shfaqen, ndërsa skedarët e vjetër fshihen.
Për shkak se shkrimi i të dhënave në bazën e të dhënave dhe leximi i skedarëve të DB-së nuk janë fshehtëzisht të sinkronizuara, programi i kopjimit mund të lexojë një faqe të pavlefshme, në të cilën një pjesë do të jetë nga versioni i vjetër i faqes, ndërsa një pjesë tjetër nga versioni i ri.

Për të siguruar që kopja rezervë të jetë e koherente, çdo DBMS ka një komandë që njofton se procesi i kopjimit ka filluar. Sintaksikisht, kjo komandë mund të duket ndryshe:

në Oracle, kjo është një komandë e veçantë ALTER DATABASE/TABLESPACE BEGIN BACKUP;
në PostgreSQL – funksioni pg_start_backup();
Në Microsoft SQL Server dhe DB2, përgatitja për kopjen rezervë kryhet në mënyrë të heshtur gjatë ekzekutimit të komandës BACKUP DATABASE;
Në MySQL Enterprise, Cassandra dhe MongoDB, përgatitja kryhet në heshtje nga një utilitar të jashtëm – mysqlbackup, OpsCenter dhe Ops Manager përkatësisht.

Pavarësisht ndryshimeve sintaksore, procesi i përgatitjes për kopjen rezervë duket i njëjtë.

Këtu është si duket përgatitja për kopjen rezervë në DBMS me struktura disku të ndryshueshme, dmth. në të gjitha sistemet tradicionale diskore relacional:

Regjistrohet momenti i fillimit të kopjimit rezervë; kopja rezervë duhet të përmbajë regjistrat e bazës së të dhënave që nga ky moment.
Kryhet një pikë kontrolli, domethënë të gjitha ndryshimet që kanë ndodhur në faqet e të dhënave deri në momentin e regjistruar, shkarkohen në disk. Kjo garanton që regjistrat deri në momentin e fillimit të kopjes rezervë nuk do të nevojiten gjatë rikuperimit.
Aktivizohet një modalitet i veçantë regjistrimi: nëse një faqe të dhënash është ndryshuar për herë të parë pas shkarkimit nga disku, në vend që të regjistrohet ndryshimi i faqes në regjistër, baza do të regjistrojë faqen në tërësi. Gjatë procesit përgatitor, të gjitha faqet shkarkohen në disk, dhe prandaj, me ndryshimin e parë, blloku gjithmonë do të regjistrohet në regjistër në tërësi. Por, nëse gjatë kopjimit të faqes, faqa përsëri do të shkarkohet në disk, atëherë ndryshimi i saj i ardhshëm gjithashtu do të sjellë një kopje të plotë të faqes në regjistër. Kjo garanton që, nëse ndodhi që gjatë kopjimit të skedarit të dhënave faqa të rezultojë e pavlefshme, aplikimi i regjistrit do ta bëjë atë sërish të vlefshme.
Ndalohet ndryshimi i titujve të skedave të të dhënave, domethënë të asaj pjese të saj, ndryshimet e të cilës nuk reflektohen në regjistra. Kjo garanton që titulli do të kopjohet saktë dhe më pas regjistrat do të aplikohen saktë në skedarin e të dhënave.

Pas pas, pasi të gjitha procedurat e përmendura më sipër janë kryer, mund të kopjoni skedarët e të dhënave duke përdorur mjete të sistemit operativ – cp, rsync dhe të tjera. Aktivizimi i modalitetit të kopjimit të rezervës zvogëlon performancën e bazës së të dhënave: së pari, rrit volumin e regjistrave, dhe së dyti, nëse ndodh një dështim gjatë modalitetit të kopjimit të rezervës, rikthimi do të jetë më i gjatë, sepse titujt e skedarëve të të dhënave nuk përditësohen. Sa më shpejt të përfundojë kopjimi i rezervës, aq më mirë për bazën e të dhënave, prandaj është e përshtatshme të përdoren mjete si snapshot e sistemit të skedarëve ose ndarja e pasqyrës (BCV) në diskun e grumbullimit. Disa DBMS (Oracle, PostgreSQL) i lejojnë administratorit të zgjedhë mënyrën e kopjimit, ndërsa të tjera (Microsoft SQL Server) ofrojnë një ndërfaqe për integrimin e mjeteve të tyre të kopjimit të rezervës me mekanizmat e sistemeve të skedarëve ose të ruajtjes së të dhënave.

Pas përfundimit të kopjimit të rezervës, duhet ta rikthejmë bazën e të dhënave në gjendjen normale. Në Oracle, kjo bëhet me komandën ALTER DATABASE/TABLESPACE END BACKUP, në PostgreSQL – duke thirrur funksionin pg_stop_backup(), ndërsa në bazat e tjera – përmes nënprogramave të brendshëm të komandave përkatëse ose shërbimeve të jashtme.

Këtu është si duket diagrami temporal i procesit të kopjimit të rezervës:

Përgatitja për kopjimin e rezervës (begin backup) merr kohë, ndonjëherë të konsiderueshme. Edhe nëse përdoren volumenet e pasqyrimit ose sistemet e skedarëve me mundësinë e krijimit të snapshoteve, procesi i kopjimit të rezervës nuk do të jetë momental.
Së bashku me skedarët e të dhënave, është e nevojshme të ruhet regjistri nga momenti që fillon përgatitja për kopjimin e rezervës dhe deri në momentin kur baza kthehet në gjendjen normale.
Mund të riktheheni nga ky kopjim të rezervës në momentin që baza kthehet në gjendjen normale. Rikthimi në një moment më të hershëm nuk është i mundur.

Me bazat e të dhënave që përdorin struktura të pandryshueshme të të dhënave (snapshote të memories, pemë LSM), situata është më e thjeshtë. Përgatitja për kopjimin e rezervës përbëhet nga hapat e mëposhtëm:

Të dhënat nga memoria shkarkohen në disk.
Regjistrohet lista e skedarëve që do të përfshihen në kopjimin e rezervës. Për aq kohë sa procesi i kopjimit të rezervës nuk është përfunduar, bazës i ndalohet të fshijë këta skedarë, edhe nëse ata bëhen të panevojshëm.

Pas sinjalit për përfundimin e kopjimit, baza me struktura të pandryshueshme mund të fshijë përsëri skedarët e panevojshëm.

Rindërtimi në pikën

Kopja rezervë lejon rikthimin e gjendjes së bazës së të dhënave në momentin kur përfundoi urdhri i kthimit nga moda e kopjimit. Megjithatë, një aksident, pas të cilit kërkohet rikuperimi, mund të ndodhi në çdo moment. Detyra e rikthimit të gjendjes së DB në një moment të rastësishëm quhet "rikthim në pikë" (point-in-time recovery).

Për të siguruar këtë mundësi, duhet ruajtur journalet e DB që nga momenti i përfundimit të kopjimit, dhe gjatë procesit të rikuperimit duhet të vazhdohet aplikimi i journalit në kopjen e rikuperuar. Pasi DB të jetë rikuperuar nga kopja rezervë në momentin e përfundimit të kopjimit, gjendja e bazës (skedaret dhe faqet e kešuara) është me siguri e saktë, prandaj një modalitet i veçantë i regjistrimit nuk është i nevojshëm. Duke aplikuar journalet deri në momentin e kërkuar, mund të merret gjendja e bazës së të dhënave në çdo pikë në kohë.

Nëse shpejtësia e rikuperimit të kopjës rezervë është e kufizuar vetëm nga kapaciteti i disqeve, shpejtësia e aplikimit të journalëve zakonisht është e kufizuar nga performanca e procesorit. Nëse në bazën kryesore të të dhënave ndryshimet ndodhin paralelisht, atëherë gjatë rikuperimit të gjitha ndryshimet realizohen në mënyrë sekondare – në rendin e leximit nga journali. Pra, koha e rikuperimit varet linearisht nga sa larg është pika e rikuperimit nga pika e përfundimit të kopjimit. Për këtë arsye, zakonisht duhet të bëheni kopje rezervë të plota mjaft shpesh – minimalisht një herë në javë për bazat me ngarkesë të vogël transaksionesh dhe deri në kopjimin e përditshëm për bazat me ngarkesë të lartë.

Kopjimi incremental

Për të accél lesimi rikuperimin në pikë, do të ishte e dëshirueshme të ishim në gjendje të bënim kopjim sa më shpesh të jetë e mundur, por pa zënë hapësirë të panevojshme në disqe dhe pa ngarkuar bazën me detyrat e kopjimit.

Zgjidhja e problemit - kopjimi incremental, domethënë kopjimi vetëm i atyre faqeve të dhënash që janë ndryshuar që nga kopjimi i mëparshëm.
Kopjimi inkremental ka kuptim vetëm për DBM-të që përdorin struktura të dhënash të ndryshueshme.

Inkrementi mund të llogaritet si nga një kopje e plotë rezervë (kopje kumulative), ashtu edhe nga çdo kopje të mëparshme (kopje diferenciale).

Fatkeqësisht, nuk ekziston një terminologji unike, dhe prodhues të ndryshëm përdorin terma të ndryshme:

Diferenciale
Kumulative

Oracle
Differential
Cumulative

PostgresPro
Incremental
—

Microsoft SQL Server
—
Differential

IBM DB2
Delta
Incremental

Kur ekzistojnë kopje inkrementale, procesi i rikthimit në një pikë duket si më poshtë:

rikthehet kopja e fundit e plotë rezervë, e bërë para momentit të rikthimit;
përmbi kopjen e plotë rikthehen kopjet inkrementale;
riaplikohen regjistrat nga pikë fillimi e rezervës deri në pikën e rikthimit.

Prania e një kopjeje kumulative e përshpejton procesin e rikthimit. Kështu, për shembull, për të rikthyer gjendjen e bazës në një pikë midis T3 dhe T4 duhet të rikthehen dy kopje inkrementale, ndërsa për të rikthyer në një pikë pas T4 – vetëm një.
Qartazi, volumi i një kopjeje kumulative është më i vogël se volumi i disa kopjeve diferenciale, sepse disa faqe janë ndryshuar disa herë dhe çdo kopje inkrementale përmban versionin e saj të faqes.

Ka tri mënyra për të krijuar një kopje inkrementale:

krijimi i një kopje të plotë dhe llogaritja e diferencës me kopjen e mëparshme të plotë;
analiza e regjistrave, krijimi i një liste të faqeve të ndryshuara dhe rezervimi i faqeve të përfshira në listë;
kërkimi i faqeve të ndryshuara në bazën e të dhënave.

Mënyra e parë kursen hapësirën diskore, por nuk zgjidh ngarkesën mbi bazën e të dhënave. Për më tepër, nëse kemi një kopje të plotë rezervë, të transformosh atë në një inkrementale është pa kuptim, pasi rikthimi i kopjes së plotë është më i shpejtë se rikthimi i kopjes së plotë të mëparshme dhe inkrementit. Çështjen e kursimit të hapësirës diskore në një qasje të tillë është më mirë ta kalosh te komponentët e veçantë me mekanizma të integruar deduplication. Këto mund të jenë si sistemet e veçanta të ruajtjes (EMC DataDomain, HPE StorageWorks VLS, e gjithë linja e NetApp), ashtu edhe produktet software (ZFS, Veritas NetBackup PureFile, Windows Server Data Deduplication).

Metodat e dyta dhe të treta dallojnë në mekanizmin e përcaktimit të listës së faqeve të ndryshuara. Analiza e regjistrave është më e kërkuar për burime, plus që për zbatimin e saj është e nevojshme të dihet struktura e skedarëve të regjistrave. Të pyesësh vetë bazën për cilet faqe janë ndryshuar është më e lehtë, por për këtë, bërthama e DBMS-së duhet të ketë funksionalitetin e gjurmimit të bllokave të ndryshuar (block change tracking).

Funksionaliteti i kopjimit incremental u krijua për herë të parë në softuerin Oracle Recovery Manager (RMAN), i cili u shfaq në versionin Oracle 8i. Oracle menjëherë implementoi gjurmimin e bllokave të ndryshuar, kështu që nuk ka nevojë për analizimin e regjistrave.

PostgreSQL nuk gjurmon bllokat e ndryshuar, kështu që utilitari pg_probackup, i zhvilluar nga kompania ruse Postgres Professional, përcakton faqet e ndryshuara duke analizuar regjistrin. Sidoqoftë, kompania ofron gjithashtu DBMS-në PostgresPro, e cila përfshin shtesën ptrack, e cila gjurmone ndryshimet e faqeve. Kur përdoret pg_probackup me DBMS-në PostgresPro, utilitari kërkon faqet e ndryshuara direkt nga baza – ashtu si RMAN.

Microsoft SQL Server gjithashtu, si Oracle, gjurmon faqet e ndryshuara, por ekipi BACKUP lejon të bëhen vetëm kopje të plota dhe kumulative.

Në DB2 ka mundësi për gjurmimin e faqeve të ndryshuara, por nga e pemrësit, ajo është e çaktivizuar. Pas aktivizimit, DB2 do të lejojë të bëhen kopje të plota, diferenciale dhe kumulative.

Një dallim i rëndësishëm midis mjeteve të përshkruara në këtë kapitull (përveç pg_probackup) dhe mjeteve për kopjimin e skedarëve është se ato kërkojnë imazhet e faqeve nga baza e të dhënave, dhe jo që lexojnë të dhënat nga disku vetë. Disavantazhi i këtij qasje është një ngarkesë e vogël shtesë për bazën. Megjithatë, ky disavantazh kompensohet me faktin se faqja e lexuar është gjithmonë korrekte, kështu që nuk ka nevojë për aktivizimin e një mënyre të veçantë regjistrimi në kohën e kopjimit.

Një herë tjetër vini re se prania e kopjimeve incremental nuk e heq kërkesën për regjistra për rikuperim në një pikë të caktuar të kohës. Prandaj, në bazat e të dhënave industriale, regjistrat vazhdimisht shkruhen në një medium të jashtëm, dhe kopjet, të plota dhe/ose incremental, krijohen sipas një programi.

Krijimi më i mirë deri më sot i idesë së kopjimit incremental është kompleksi softueror-hardware (në terminologjinë Oracle – sistemi i krijuar) Zero Data Loss Recovery Appliance – një zgjidhje e specializuar e Oracle për kopjimin e bazës së të dhënave të saj. Kompleksi përbën një klaster serverësh me një kapacitet të madh disku, ku është instaluar një version i modifikuar i softuerit Recovery Manager dhe mund të punojë si me komplekse të tjera softuerike-hardware të Oracle (Database Appliance, Exadata, SPARC Supercluster), ashtu edhe me bazat Oracle në infrastrukturën tradicionale. Në ndryshim nga RMAN “i zakonshëm”, në ZDLRA realizohet koncepti i “incementit të përjetshëm” (incremental forever). Sistemi krijon një herë një kopje të plotë të bazës së të dhënave, dhe pastaj bën vetëm kopje incrementale. Modulet shtesë RMAN lejojnë të bashkohen kopjet, duke krijuar kopje të reja të plota nga ato incrementale.

Për meritat e zhvilluesve rusë, duhet të përmendet se dhe pg_probackup di të bashkojë kopje incrementale.

Në ndryshim nga shumë pyetje të ngjashme, pyetja "cilat është metoda më e mirë e kopjimit" ka një përgjigje të qartë – më e mira është utilita e natyrshme për DBMS-në e përdorur që ofron mundësinë e kopjimit incremental.

Për administratorin e bazës së dhënave, pyetjet e zgjedhjes së strategjisë së kopjimit dhe integrimi i mjeteve të rezervimit të bazave të të dhënave në infrastrukturën e korporatës janë shumë më të rëndësishme. Por këto pyetje del në përjashtim të këtij artikulli.

Burimi: habr.com