ProHoster > Blog > Administrim > Udhëzuesi për kopjimin rezervë të bazave të të dhënave

Udhëzuesi për kopjimin rezervë të 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.

Udhëzuesi për kopjimin rezervë të bazave të të dhënave

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:

  1. 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.
  2. 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.
  3. 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.
  4. 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:

Udhëzuesi për kopjimin rezervë të bazave të të dhënave

  • 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:

  1. Të dhënat nga memoria shkarkohen në disk.
  2. 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).

Udhëzuesi për kopjimin rezervë të bazave të të dhënave

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:

  1. krijimi i një kopje të plotë dhe llogaritja e diferencës me kopjen e mëparshme të plotë;
  2. analiza e regjistrave, krijimi i një liste të faqeve të ndryshuara dhe rezervimi i faqeve të përfshira në listë;
  3. 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.

Udhëzuesi për kopjimin rezervë të bazave të të dhënave

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

Blini hosting tĂ« besueshĂ«m pĂ«r faqe interneti me mbrojtje nga DDoS, serverĂ« VPS VDS đŸ”„ Blini hosting tĂ« besueshĂ«m pĂ«r faqe interneti me mbrojtje nga DDoS, serverĂ« VPS VDS | ProHoster