🥇 Տվյալների բազայի կրկնօրինակումների ուղեցույց

-Օ՜, ոչ մի ապաստան չի կարող դիմանալ երկնաքարի հարվածին։ Բայց դուք, ինչպես բոլորը, ունեք ռեզերվ, այնպես որ դուք չպետք է անհանգստանաք:
Ստանիսլավ Լեմ, «Իջոն Հանգիստի աստղային օրագրերը»

Պահուստավորումը վերաբերում է տվյալների կրկնօրինակը պահելուն իր հիմնական պահպանման վայրից դուրս ինչ-որ տեղ:

Կրկնօրինակման հիմնական նպատակը տվյալների կորստից հետո վերականգնելն է: Այս առումով հաճախ եք լսում, որ եթե դուք ունեք տվյալների բազայի կրկնօրինակ, ապա միշտ կարող եք վերականգնել տվյալները դրանից, և կրկնօրինակման կարիք չկա: Փաստորեն, կրկնօրինակը թույլ է տալիս լուծել առնվազն երեք խնդիր, որոնք հնարավոր չէ լուծել կրկնօրինակի միջոցով, և կրկնօրինակը չի կարող սկզբնավորվել առանց կրկնօրինակի:

Նախ, կրկնօրինակը թույլ է տալիս վերականգնել տվյալները տրամաբանական սխալից հետո: Օրինակ, հաշվապահը ջնջել է մի խումբ գործարքներ կամ տվյալների բազայի ադմինիստրատորը ոչնչացրել է սեղանի տարածքը: Երկու գործողություններն էլ ամբողջովին օրինական են տվյալների բազայի տեսանկյունից, և կրկնօրինակման գործընթացը կվերարտադրի դրանք կրկնօրինակների տվյալների բազայում:

Երկրորդ, ժամանակակից DBMS-ները շատ հուսալի ծրագրային համակարգեր են, բայց երբեմն տեղի է ունենում տվյալների բազայի ներքին կառուցվածքների վնասում, որից հետո տվյալների հասանելիությունը կորչում է: Հատկապես վիրավորականն այն է, որ նման խախտումը սովորաբար տեղի է ունենում մեծ ծանրաբեռնվածության դեպքում կամ ինչ-որ թարմացում տեղադրելիս: Բայց և՛ մեծ ծանրաբեռնվածությունը, և՛ կանոնավոր թարմացումները ցույց են տալիս, որ տվյալների բազան ամենևին էլ փորձնական տվյալների բազա չէ, և դրանում պահվող տվյալները արժեքավոր են:

Վերջապես, երրորդ խնդիրը, որի լուծումը պահանջում է պահեստային պատճեն, տվյալների բազայի կլոնավորումն է, օրինակ՝ թեստավորման նպատակով։

Տվյալների բազայի կրկնօրինակումն այս կամ այն կերպ հիմնված է երկու սկզբունքներից մեկի վրա.

Տվյալների նմուշառում և հետագա պահպանում մաքսային ձևաչափով.
Տվյալների բազայի ֆայլերի պատկերը և տեղեկամատյանների պահպանումը:

Եկեք ավելի սերտ նայենք այս սկզբունքներին և դրանք իրագործող գործիքներին:

Տվյալների վերբեռնում

Ցանկացած DBMS-ում ներառված կոմունալ ծառայությունների փաթեթը պետք է ներառի տվյալների վերբեռնման և բեռնման գործիքներ: Տվյալները պահվում են կամ տեքստային ձևաչափով կամ երկուական ձևաչափով, որը հատուկ է որոշակի DBMS-ին: Ստորև բերված աղյուսակը ներկայացնում է նման գործիքների ցանկը.

Երկուական ձևաչափ
Տեքստի ձևաչափ

Oracle
DataPump արտահանում/DataPump ներմուծում
Արտահանման / ներմուծման
SQL*Plus/SQL*Loader

PostgreSQL
pg_dump, pg_dumpall/pg_restore
pg_dump, pg_dumpall/psql

Microsoft SQL Server
bcp
bcp

DB2
բեռնաթափել/բեռնել
բեռնաթափել/բեռնել

MySQL

mysqldump, mysqlpump/mysql, mysqlimport

MongoDB- ը
mongodump/mongorestore
mongoexport/mongoimport

Cassandra
nodetool snapshot/sstableloader
cqlsh

Տեքստի ձևաչափի լավ բանն այն է, որ այն կարող է խմբագրվել կամ նույնիսկ ստեղծվել արտաքին ծրագրերի կողմից, իսկ երկուական ձևաչափը, իր հերթին, լավ է, քանի որ թույլ է տալիս ավելի արագ վերբեռնել և ներբեռնել տվյալներ՝ խնայելով ռեսուրսները ձևաչափի փոխակերպման վրա:

Չնայած տվյալների ներբեռնման գաղափարի պարզությանը և ակնհայտությանը, այս մեթոդը հազվադեպ է օգտագործվում բեռնված արդյունաբերական տվյալների բազաները պահուստավորելու համար: Ահա այն պատճառները, թե ինչու բեռնաթափումը հարմար չէ ամբողջական կրկնօրինակման համար.

բեռնաթափման գործընթացը զգալի բեռ է ստեղծում աղբյուրի համակարգի վրա.
բեռնաթափումը շատ ժամանակ է պահանջում - մինչև բեռնաթափումն ավարտվի, այն այլևս տեղին չի լինի.
Գրեթե անհնար է ամբողջ տվյալների բազայի համակարգված բեռնաթափում կատարել բարձր ծանրաբեռնվածության ներքո, քանի որ DBMS-ը ստիպված է պահել իր վիճակի պատկերը բեռնաթափման մեկնարկի պահին: Որքան շատ գործարքներ են կատարվել վերբեռնման սկզբից ի վեր, այնքան մեծ է նկարի չափը (Տվյալների անհամապատասխան պատճենները PostgreSQL-ում, հետարկել տարածքը Oracle-ում, tempdb Microsoft SQL Server-ում և այլն);
բեռնաթափումը պահպանում է տվյալների տրամաբանական կառուցվածքը, բայց չի պահպանում դրա ֆիզիկական կառուցվածքը՝ աղյուսակների, ինդեքսների և այլնի ֆիզիկական պահպանման պարամետրերը:

Այնուամենայնիվ, վերբեռնումն ունի նաև իր առավելությունները.

բարձր ընտրողականություն. կարող եք ներբեռնել առանձին աղյուսակներ, առանձին դաշտեր և նույնիսկ առանձին տողեր.
Ներբեռնված տվյալները կարող են բեռնվել մեկ այլ տարբերակի տվյալների բազայում, իսկ եթե ներբեռնումը կատարվում է տեքստային ձևաչափով, ապա մեկ այլ տվյալների բազա:

Այսպիսով, վերբեռնումն օգտագործվում է հիմնականում այնպիսի խնդիրների համար, ինչպիսիք են փոքր աղյուսակների (օրինակ՝ դիրեկտորիաների) պահուստավորումը կամ հավելվածի հաջորդ թողարկումով տվյալների հավաքածուների բաշխումը:

Տվյալների բազայի կրկնօրինակման ամենատարածված մեթոդը տվյալների բազայի ֆայլերի պատճենումն է:

Տվյալների բազայի ֆայլերի սառը պահպանում

Ակնհայտ գաղափարն է դադարեցնել տվյալների բազան և պատճենել դրա բոլոր ֆայլերը: Այս կրկնօրինակը կոչվում է «սառը» կրկնօրինակում: Մեթոդը չափազանց հուսալի և պարզ է, բայց այն ունի երկու ակնհայտ թերություն.

«Սառը» կրկնօրինակից դուք կարող եք վերականգնել միայն տվյալների բազայի վիճակը, որը եղել է անջատման պահին. Տվյալների բազայի վերագործարկումից հետո կատարված գործարքները չեն ներառվի «սառը» կրկնօրինակում.
Ոչ բոլոր տվյալների բազան ունի տեխնոլոգիական պատուհան, երբ տվյալների բազան կարող է դադարեցվել:

Եթե «սառը» պահուստավորումը ձեզ հարմար է, դուք պետք է հիշեք դա

Սառը պատճենը երբեմն պետք է ներառի տեղեկամատյաններ: Մատյանների որոշման մեթոդները, որոնք պետք է մտնեն «սառը» պատճենը, անհատական են յուրաքանչյուր DBMS-ի համար: Օրինակ, Oracle-ում անհրաժեշտ է պատճենել այսպես կոչված առցանց redo-ն, այսինքն՝ ֆիքսված թվով log ֆայլեր հատուկ գրացուցակում, նույնիսկ երբ տվյալների բազան ճիշտ է դադարեցված։ PostgreSQL-ում դուք պետք է պահպանեք բոլոր տեղեկամատյանները՝ սկսած վերջին անցակետը պարունակող մատյանից, որի մասին տեղեկատվությունը պարունակվում է կառավարման ֆայլում:
Տվյալների բազայի գրացուցակը կարող է պարունակել սեղանի տարածության ժամանակավոր ֆայլեր, որոնք բավականաչափ մեծ են, որպեսզի դրանք չներառվեն կրկնօրինակում: Ի դեպ, այս դիտողությունը ճիշտ է նաև տաք կրկնօրինակումների դեպքում։

Թեժ ֆայլի պահպանում

Շատ ժամանակակից տվյալների բազայի կրկնօրինակումներն իրականացվում են տվյալների բազայի ֆայլերը պատճենելով՝ առանց տվյալների բազան դադարեցնելու: Այստեղ մի քանի խնդիր կա.

Երբ սկսվում է պատճենումը, տվյալների բազայի բովանդակությունը կարող է չհամընկնել ֆայլերի բովանդակության հետ, քանի որ տեղեկատվության մի մասը գտնվում է քեշում և դեռ չի գրվել սկավառակի վրա:
Պատճենման ընթացքում տվյալների բազայի բովանդակությունը կարող է փոխվել: Եթե օգտագործվում են փոփոխվող տվյալների կառուցվածքներ, ֆայլերի բովանդակությունը փոխվում է, և երբ օգտագործվում են անփոփոխ կառուցվածքներ, փոխվում է ֆայլերի շարքը. հայտնվում են նոր ֆայլեր, իսկ հինները ջնջվում են:
Քանի որ տվյալների բազայում տվյալներ գրելը և տվյալների բազայի ֆայլերը կարդալը որևէ կերպ համաժամանակացված չեն, պահեստային ծրագիրը կարող է կարդալ սխալ էջ, որի կեսը կլինի էջի հին տարբերակից, իսկ մյուս կեսը նորից:

Որպեսզի կրկնօրինակը հետևողական լինի, յուրաքանչյուր DBMS-ն ունի հրաման, որը տեղեկացնում է, որ կրկնօրինակման գործընթացը սկսվել է: Սինտակտիկորեն այս հրամանը կարող է տարբեր տեսք ունենալ.

Oracle-ում սա առանձին հրաման է ALTER DATABASE/TABLESPACE BEGIN BACKUP;
PostgreSQL-ում – pg_start_backup ();
Microsoft SQL Server-ում և DB2-ում կրկնօրինակման պատրաստումը կատարվում է անուղղակիորեն BACKUP DATABASE հրամանի կատարման ժամանակ;
MySQL Enterprise-ում, Cassandra-ում և MongoDB-ում նախապատրաստումը անուղղակիորեն իրականացվում է արտաքին օգտակար ծրագրի կողմից՝ համապատասխանաբար mysqlbackup, OpsCenter և Ops Manager:

Չնայած շարահյուսական տարբերություններին, կրկնօրինակման պատրաստման գործընթացը նույնն է թվում:

Ահա թե ինչպիսին է կրկնօրինակման պատրաստումը փոփոխական սկավառակի կառուցվածքներով DBMS-ում, այսինքն՝ բոլոր ավանդական սկավառակի հարաբերական համակարգերում.

Պահուստավորման մեկնարկի պահը հիշվում է. Պահուստային պատճենը պետք է պարունակի տվյալների բազայի տեղեկամատյաններ այս պահից սկսած:
Կատարվում է անցակետ, այսինքն՝ բոլոր փոփոխությունները, որոնք տեղի են ունեցել տվյալների էջերում մինչև հիշվող պահը, լցվում են սկավառակի վրա: Սա ապահովում է, որ տեղեկամատյանների կարիք չկա, նախքան վերականգնման ընթացքում կրկնօրինակումը կսկսվի:
Միացված է հատուկ գրանցման ռեժիմ. եթե տվյալների էջը սկավառակից բեռնելուց հետո առաջին անգամ փոխվել է, ապա տեղեկամատյանում էջի փոփոխությունները գրելու փոխարեն տվյալների բազան այնտեղ կգրի ամբողջ էջը: Նախապատրաստման ընթացակարգն իրականացնելիս բոլոր էջերը լցվում են սկավառակի վրա, ուստի առաջին անգամ փոփոխություն կատարելիս ամբողջ բլոկը միշտ կգրվի մատյանում: Բայց եթե կրկնօրինակման գործընթացում էջը նորից հեռացվի սկավառակի վրա, դրա հաջորդ փոփոխությունը նույնպես կհանգեցնի այն բանին, որ էջի ամբողջական պատճենը կհայտնվի գրանցամատյանում: Սա ապահովում է, որ եթե տվյալների ֆայլը պատճենելիս պարզվի, որ էջը սխալ է, գրանցամատյանի կիրառմամբ այն նորից ճիշտ կդարձնի:
Տվյալների ֆայլերի վերնագրերի փոփոխություններն արգելափակված են, այսինքն՝ դրա այն մասը, որի փոփոխությունները չեն արտացոլվում տեղեկամատյաններում։ Սա ապահովում է վերնագրի ճիշտ պատճենումը, այնուհետև տեղեկամատյանները ճիշտ են կիրառվում տվյալների ֆայլի վրա:

Վերոնշյալ բոլոր ընթացակարգերն ավարտվելուց հետո կարող եք պատճենել տվյալների ֆայլերը՝ օգտագործելով օպերացիոն համակարգի գործիքները՝ cp, rsync և այլն: Պահուստավորման ռեժիմը միացնելը նվազեցնում է տվյալների բազայի աշխատանքը. նախ, գրանցամատյանների ծավալը մեծանում է, և երկրորդը, եթե հանկարծ պահուստավորման ռեժիմում ձախողվի, վերականգնումն ավելի երկար կպահանջի, քանի որ տվյալների ֆայլերի վերնագրերը չեն թարմացվում: Որքան արագ կրկնօրինակումն ավարտվի, այնքան լավ տվյալների բազայի համար, ուստի նպատակահարմար է օգտագործել այնպիսի գործիքներ, ինչպիսիք են ֆայլային համակարգի պատկերը կամ սկավառակի զանգվածում հայելին (BCV) կոտրելը: Որոշ DBMS-ներ (Oracle, PostgreSQL) ադմինիստրատորին հնարավորություն են տալիս ինքնուրույն ընտրել պատճենահանման եղանակը, մյուսները (Microsoft SQL Server) ապահովում են ինտերֆեյս՝ ֆայլային համակարգի կամ պահեստավորման մեխանիզմների հետ սեփական պահեստային ծրագրերը ինտեգրելու համար:

Կրկնօրինակումն ավարտվելուց հետո դուք պետք է վերադարձնեք տվյալների բազան իր բնականոն վիճակին: Oracle-ում դա արվում է ALTER DATABASE/TABLESPACE END BACKUP հրամանով, PostgreSQL-ում՝ կանչելով pg_stop_backup() ֆունկցիան, իսկ այլ տվյալների բազաներում՝ համապատասխան հրամանների կամ արտաքին ծառայությունների ներքին ռեժիմներով:

Ահա թե ինչ տեսք ունի պահուստավորման գործընթացի ժամանակացույցը.

Կրկնօրինակման պատրաստվելը ժամանակ է պահանջում, երբեմն՝ զգալի ժամանակ: Նույնիսկ եթե օգտագործվում են հայելային ծավալներ կամ ակնթարթային ֆայլային համակարգեր, կրկնօրինակման գործընթացը ակնթարթային չի լինի:
Տվյալների ֆայլերի հետ մեկտեղ անհրաժեշտ է պահպանել տեղեկամատյանները պահուստավորման համար նախապատրաստվելու պահից մինչև տվյալների բազան իր բնականոն վիճակին վերադառնալու պահը:
Դուք կարող եք վերականգնել այս կրկնօրինակից այն ժամանակ, երբ բազան վերադառնում է նորմալ վիճակի. Ավելի վաղ կետին վերականգնել հնարավոր չէ։

Տվյալների բազաների դեպքում, որոնք օգտագործում են տվյալների անփոփոխ կառուցվածքներ (հիշողության նկարներ, LSM ծառեր), իրավիճակն ավելի պարզ է: Կրկնօրինակման պատրաստումը բաղկացած է հետևյալ քայլերից.

Հիշողությունից ստացված տվյալները փոխանցվում են սկավառակի վրա:
Պահուստային պատճենում ներառված ֆայլերի ցանկը գրանցվում է: Քանի դեռ կրկնօրինակման գործընթացը չի ավարտվել, տվյալների բազան արգելվում է ջնջել այդ ֆայլերը, նույնիսկ եթե դրանք այլևս կարիք չունեն:

Ազդանշանով, որ կրկնօրինակումն ավարտված է, անփոփոխ կառուցվածքներով տվյալների բազան կարող է կրկին ջնջել ավելորդ ֆայլերը:

Վերականգնում մինչև կետ

Պահուստային պատճենը թույլ է տալիս վերականգնել տվյալների բազայի վիճակը մինչև պահուստային ռեժիմից վերադարձի հրամանի ավարտը: Այնուամենայնիվ, վթար, որը պահանջում է վերականգնում, կարող է տեղի ունենալ ցանկացած պահի: Տվյալների տվյալների բազայի վիճակը կամայական պահին վերականգնելու խնդիրը կոչվում է «կետ-ժամանակի վերականգնում»:

Որպեսզի դա հնարավոր լինի, դուք պետք է պահպանեք տվյալների բազայի տեղեկամատյանները՝ սկսած պահուստավորման ավարտից, և վերականգնման գործընթացում շարունակեք կիրառել տեղեկամատյանները վերականգնված պատճենի վրա: Այն բանից հետո, երբ տվյալների բազան վերականգնվում է կրկնօրինակից պատճենման ավարտի պահին, տվյալների բազայի վիճակը (ֆայլեր և քեշավորված էջեր) երաշխավորված է ճիշտ, ուստի հատուկ գրանցման ռեժիմի կարիք չկա: Կիրառելով տեղեկամատյանները ճիշտ պահին, դուք կարող եք ստանալ տվյալների բազայի վիճակը ցանկացած պահի:

Թեև կրկնօրինակի վերականգնման արագությունը սահմանափակվում է միայն սկավառակի թողունակությամբ, գրանցամատյանների կիրառման արագությունը սովորաբար սահմանափակվում է պրոցեսորի գործունակությամբ: Եթե փոփոխությունները տեղի են ունենում հիմնական տվյալների բազայում զուգահեռ, ապա վերականգնման ընթացքում բոլոր փոփոխությունները կատարվում են հաջորդաբար՝ մատյանից կարդալու հերթականությամբ: Այսպիսով, վերականգնման ժամանակը գծայինորեն կախված է նրանից, թե որքան հեռու է վերականգնման կետը պահուստավորման վերջնակետից: Դրա պատճառով անհրաժեշտ է բավականին հաճախ կատարել ամբողջական կրկնօրինակումներ՝ առնվազն շաբաթը մեկ անգամ փոքր գործարքների բեռնվածությամբ տվյալների բազաների և բարձր բեռնված տվյալների բազաների մինչև օրական կրկնօրինակների համար:

Աճող կրկնօրինակում

Վերականգնումը մինչև մի կետ արագացնելու համար ես կցանկանայի, որ կարողանայի հնարավորինս հաճախ կրկնօրինակումներ կատարել, բայց միևնույն ժամանակ սկավառակի լրացուցիչ տարածք չզբաղեցնել և տվյալների բազան չբեռնել պահեստային առաջադրանքներով:

Խնդրի լուծումը հավելյալ կրկնօրինակումն է, այսինքն՝ պատճենել միայն այն տվյալների էջերը, որոնք փոխվել են նախորդ կրկնօրինակումից հետո։
Ավելացվող կրկնօրինակումներն իմաստ ունեն միայն DBMS-ների համար, որոնք օգտագործում են փոփոխվող տվյալների կառուցվածքներ:

Աճը կարելի է հաշվել կամ ամբողջական կրկնօրինակից (կուտակային պատճենից) կամ ցանկացած նախորդ օրինակից (դիֆերենցիալ պատճենից):

Ցավոք, չկա միատեսակ տերմինաբանություն, և տարբեր արտադրողներ օգտագործում են տարբեր տերմիններ.

Դիֆերենցիալ
Կուտակային

Oracle
Դիֆերենցիալ
Կուտակային

PostgreSQL
Ավելացում
-

Microsoft SQL Server
-
Դիֆերենցիալ

IBM DB2
դելտա
Ավելացում

Եթե կան աստիճանական պատճեններ, ապա կետի վերականգնման գործընթացը հետևյալն է.

վերջին ամբողջական կրկնօրինակը, որը արվել է մինչև վերականգնումը վերականգնվելը.
աստիճանական պատճենները վերականգնվում են ամբողջական օրինակի վերևում.
տեղեկամատյանները պտտվում են պահուստային սկզբնական կետից մինչև վերականգնման կետ:

Կուտակային պատճեն ունենալը արագացնում է վերականգնման գործընթացը: Այսպիսով, օրինակ, տվյալների բազայի վիճակը T3-ի և T4-ի միջև ընկած կետում վերականգնելու համար անհրաժեշտ է վերականգնել երկու աստիճանական օրինակ, իսկ T4-ից հետո մի կետ՝ միայն մեկը:
Ակնհայտ է, որ մեկ կուտակային օրինակի չափը փոքր է, քան մի քանի դիֆերենցիալ պատճենների չափը, քանի որ որոշ էջեր մի քանի անգամ փոխվել են, և յուրաքանչյուր աճող պատճենը պարունակում է էջի տարբեր տարբերակ:

Աճող պատճեն ստեղծելու երեք եղանակ կա.

ստեղծելով ամբողջական պատճեն և հաշվարկելով տարբերությունը նախորդ ամբողջական օրինակի հետ.
տեղեկամատյանների վերլուծություն, փոփոխված էջերի ցուցակի ստեղծում և ցանկում ընդգրկված էջերի կրկնօրինակում;
տվյալների բազայի փոփոխված էջերի հարցում:

Առաջին մեթոդը խնայում է սկավառակի տարածությունը, բայց չի լուծում տվյալների բազայի բեռը նվազեցնելու խնդիրը: Ավելին, եթե մենք ունենք ամբողջական կրկնօրինակում, ապա այն լրացուցիչի վերածելն անիմաստ է, քանի որ ամբողջական պատճենը վերականգնելն ավելի արագ է, քան նախորդ ամբողջական պատճենը և ավելացումը: Ավելի լավ է այս մոտեցմամբ սկավառակի տարածություն խնայելու խնդիրը տեղափոխել ներկառուցված կրկնօրինակման մեխանիզմներով հատուկ բաղադրիչներ: Դրանք կարող են լինել կամ հատուկ պահպանման համակարգեր (EMC DataDomain, HPE StorageWorks VLS, ամբողջ NetApp գիծը) կամ ծրագրային արտադրանք (ZFS, Veritas NetBackup PureFile, Windows Server Data Deduplication):

Երկրորդ և երրորդ մեթոդները տարբերվում են փոփոխված էջերի ցանկի որոշման մեխանիզմով։ Մատյանների վերլուծությունն ավելի շատ ռեսուրսներ է պահանջում, գումարած այն իրականացնելու համար դուք պետք է իմանաք տեղեկամատյանների կառուցվածքը: Ամենահեշտ ձևը տվյալների բազային հարցնելն է, թե որ էջերն են փոխվել, բայց դրա համար DBMS միջուկը պետք է ունենա բլոկի փոփոխության հետևման գործառույթ:

Կրկնօրինակման լրացուցիչ գործառույթն առաջին անգամ ներդրվել է Oracle Recovery Manager (RMAN) ծրագրաշարում, որը ներկայացվել է Oracle 8i թողարկումում: Oracle-ն անմիջապես իրականացրեց փոփոխված բլոկների հետագծումը, ուստի տեղեկամատյանները վերլուծելու կարիք չկա:

PostgreSQL-ը չի հետևում փոփոխված բլոկներին, ուստի ռուսական Postgres Professional ընկերության կողմից մշակված pg_probackup կոմունալ ծրագիրը որոշում է փոփոխված էջերը՝ վերլուծելով գրանցամատյանը: Այնուամենայնիվ, ընկերությունը տրամադրում է նաև PostgresPro DBMS-ը, որը ներառում է ptrack ընդլայնումը, որը հետևում է էջի փոփոխություններին: PostgresPro DBMS-ի հետ pg_probackup-ն օգտագործելիս կոմունալ ծառայության հարցումները փոխել են էջերը հենց տվյալների բազայից՝ ճիշտ նույնը, ինչ RMAN-ը:

Microsoft SQL Server-ը, Oracle-ի նման, հետևում է փոփոխված էջերին, սակայն BACKUP հրամանը թույլ է տալիս կատարել միայն ամբողջական և կուտակային կրկնօրինակումներ:

DB2-ն ունի փոփոխված էջերին հետևելու հնարավորություն, սակայն այն անջատված է լռելյայնորեն: Միացնելուց հետո DB2-ը թույլ կտա ամբողջական, դիֆերենցիալ և կուտակային կրկնօրինակումներ:

Այս բաժնում նկարագրված գործիքների (բացառությամբ pg_probackup) և ֆայլերի կրկնօրինակման գործիքների միջև կարևոր տարբերությունն այն է, որ նրանք տվյալների բազայից պահանջում են էջի պատկերներ, քան իրենք՝ սկավառակից տվյալներ կարդալու: Այս մոտեցման թերությունը բազայի վրա փոքր լրացուցիչ բեռ է: Այնուամենայնիվ, այս թերությունն ավելի քան փոխհատուցվում է նրանով, որ ընթերցված էջը միշտ ճիշտ է, ուստի կարիք չկա հատուկ գրանցման ռեժիմ միացնել կրկնօրինակման ընթացքում:

Խնդրում ենք ևս մեկ անգամ նկատի ունենալ, որ լրացուցիչ պատճենների առկայությունը չի վերացնում վերականգնման համար հասանելի տեղեկամատյանների պահանջը կամայական ժամանակի համար: Հետևաբար, արդյունաբերական տվյալների բազաներում տեղեկամատյաններն անընդհատ վերագրվում են արտաքին կրիչներին, իսկ կրկնօրինակները՝ ամբողջական և/կամ աստիճանաբար, ստեղծվում են ժամանակացույցով:

Աճման աստիճանական պահուստավորման գաղափարի լավագույն իրականացումն այսօր Zero Data Loss Recovery Appliance-ն է, որը ապարատային և ծրագրային համակարգ է (Oracle-ի տերմինաբանությամբ՝ ինժեներական համակարգ)՝ Oracle-ի մասնագիտացված լուծում՝ սեփական տվյալների բազայի պահուստավորման համար։ Համակարգը կլաստեր է։ սերվերներ ZDLRA-ն ունի մեծ սկավառակի տարողունակություն և գործարկում է Recovery Manager ծրագրի փոփոխված տարբերակը: Այն կարող է աշխատել Oracle-ի այլ ապարատային և ծրագրային համակարգերի (Database Appliance, Exadata, SPARC Supercluster), ինչպես նաև ավանդական ենթակառուցվածքների վրա աշխատող Oracle տվյալների բազաների հետ: Ի տարբերություն «սովորական» RMAN-ի, ZDLRA-ն իրականացնում է «incremental forever» հայեցակարգը: Համակարգը մեկ անգամ ստեղծում է տվյալների բազայի ամբողջական պատճենը, ապա միայն incremental պատճեններ է անում: Լրացուցիչ RMAN մոդուլները թույլ են տալիս միավորել պատճենները՝ ստեղծելով նոր ամբողջական պատճեններ incremental պատճեններից:

Ի պատիվ ռուս մշակողների, հարկ է նշել, որ pg_probackup-ը կարող է նաև միաձուլել աստիճանական պատճենները:

Ի տարբերություն շատ նմանատիպ հարցերի, «որ պահուստավորման մեթոդն է ավելի լավ» հարցը ունի հստակ պատասխան. լավագույն տարբերակը օգտագործվող DBMS-ի բնիկ օգտակար ծրագիրն է, որն ապահովում է լրացուցիչ կրկնօրինակումների հնարավորություն:

Տվյալների բազայի ադմինիստրատորի համար շատ ավելի կարևոր են պահուստային ռազմավարության ընտրության և կորպորատիվ ենթակառուցվածքում տվյալների բազայի պահուստավորման գործիքների ինտեգրման խնդիրները: Բայց այս հարցերը դուրս են այս հոդվածի շրջանակներից:

Source: www.habr.com