- O, ni all unrhyw loches wrthsefyll trawiad meteoryn. Ond mae gennych chi, fel pawb arall, gronfa wrth gefn, felly does dim rhaid i chi boeni.
Stanislav Lem, “Star Diaries of Ijon the Quiet”
Mae copi wrth gefn yn cyfeirio at arbed copi o ddata rhywle y tu allan i'w brif leoliad storio.
Prif bwrpas y copi wrth gefn yw adfer data ar ôl iddo gael ei golli. Yn hyn o beth, rydych chi'n aml yn clywed, os oes gennych chi replica cronfa ddata, gallwch chi bob amser adfer data ohono, ac nid oes angen copi wrth gefn. Mewn gwirionedd, mae copi wrth gefn yn eich galluogi i ddatrys o leiaf tair problem na ellir eu datrys gan ddefnyddio replica, ac ni ellir cychwyn replica heb gopi wrth gefn.
Yn gyntaf, mae copi wrth gefn yn caniatáu ichi adennill data ar ôl gwall rhesymegol. Er enghraifft, fe wnaeth cyfrifydd ddileu grŵp o drafodion neu ddinistriodd gweinyddwr cronfa ddata ofod bwrdd. Mae'r ddau weithrediad yn gwbl gyfreithiol o safbwynt y gronfa ddata, a bydd y broses atgynhyrchu yn eu hatgynhyrchu yn y gronfa ddata replica.
Yn ail, mae DBMSs modern yn systemau meddalwedd dibynadwy iawn, ond o bryd i'w gilydd mae difrod i strwythurau mewnol y gronfa ddata, ac ar ôl hynny mae mynediad i'r data yn cael ei golli. Yr hyn sy'n arbennig o dramgwyddus yw bod y fath drosedd fel arfer yn digwydd o dan lwyth uchel neu wrth osod rhyw fath o ddiweddariad. Ond mae'r llwyth uchel a'r diweddariadau rheolaidd yn dangos nad yw'r gronfa ddata yn gronfa ddata brawf o bell ffordd, ac mae'r data a storir ynddi yn werthfawr.
Yn olaf, y drydedd dasg, y mae angen copi wrth gefn ar ei chyfer, yw clonio cronfa ddata, er enghraifft, at ddibenion profi.
Mae copi wrth gefn cronfa ddata un ffordd neu'r llall yn seiliedig ar un o ddwy egwyddor:
- Samplu data ac arbed dilynol mewn fformat arferol;
- Ciplun o ffeiliau cronfa ddata ac arbed logiau.
Gadewch i ni edrych yn agosach ar yr egwyddorion hyn a'r offer sy'n eu gweithredu.
Wrthi'n uwchlwytho data
Rhaid i'r set o gyfleustodau sydd wedi'u cynnwys gydag unrhyw DBMS gynnwys offer ar gyfer lanlwytho a llwytho data. Mae data'n cael ei storio naill ai ar ffurf testun neu mewn fformat deuaidd sy'n benodol i DBMS penodol. Mae'r tabl isod yn rhoi rhestr o offer o'r fath:
Fformat deuaidd
Fformat testun
Oracle
Allforio DataPump / Mewnforio DataPump
Allforio / Mewnforio
SQL* Plus/SQL* Loader
PostgreSQL
pg_dump, pg_dumpall/pg_restore
pg_dump, pg_dumpall/psql
Microsoft SQL Gweinyddwr
bcp
bcp
DB2
dadlwytho/llwytho
dadlwytho/llwytho
MySQL
mysqldump, mysqlpump/mysql, mysqlimport
MongoDB
mongodump/mongorestore
mongoallforio/mongoimport
Cassandra
ciplun nodetool/llwythwr stabl
cqlsh
Y peth da am fformat y testun yw y gellir ei olygu neu hyd yn oed ei greu gan raglenni allanol, ac mae'r fformat deuaidd, yn ei dro, yn dda oherwydd ei fod yn caniatáu ichi uwchlwytho a lawrlwytho data yn gyflymach trwy arbed adnoddau ar drosi fformat.
Er gwaethaf symlrwydd ac amlwgrwydd y syniad o lawrlwytho data, anaml y defnyddir y dull hwn i wneud copi wrth gefn o gronfeydd data diwydiannol wedi'u llwytho. Dyma'r rhesymau pam nad yw dadlwytho yn addas ar gyfer copi wrth gefn llawn:
- mae'r broses ddadlwytho yn creu llwyth sylweddol ar y system ffynhonnell;
- mae dadlwytho yn cymryd llawer o amser - erbyn i'r dadlwytho gael ei gwblhau ni fydd yn berthnasol mwyach;
- Mae bron yn amhosibl dadlwytho'r gronfa ddata gyfan mewn modd cydgysylltiedig o dan lwyth uchel, gan fod y DBMS yn cael ei orfodi i storio ciplun o'i gyflwr ar yr adeg y mae'r dadlwytho'n dechrau. Po fwyaf o drafodion sydd wedi'u cwblhau ers dechrau'r uwchlwytho, y mwyaf yw maint y ciplun (copïau amherthnasol o ddata yn PostgreSQL, dadwneud gofod yn Oracle, tempdb yn Microsoft SQL Server, ac ati);
- mae dadlwytho yn cadw strwythur rhesymegol y data, ond nid yw'n cadw ei strwythur ffisegol - paramedrau storio tablau, mynegeion, ac ati.
Fodd bynnag, mae gan uwchlwytho ei fanteision hefyd:
- detholusrwydd uchel: gallwch lawrlwytho tablau unigol, meysydd unigol a hyd yn oed rhesi unigol;
- gellir llwytho'r data a lawrlwythwyd i gronfa ddata o fersiwn arall, ac os gwneir y lawrlwythiad ar ffurf testun, yna i gronfa ddata arall.
Felly, defnyddir llwytho i fyny yn bennaf ar gyfer tasgau megis gwneud copïau wrth gefn o dablau bach (er enghraifft, cyfeiriaduron) neu ddosbarthu setiau data gyda'r datganiad cais nesaf.
Y dull mwyaf cyffredin o wneud copi wrth gefn o gronfa ddata yw copïo ffeiliau cronfa ddata.
Storio oer o ffeiliau cronfa ddata
Y syniad amlwg yw atal y gronfa ddata a chopïo ei holl ffeiliau. Gelwir y copi wrth gefn hwn yn gopi wrth gefn “oer”. Mae'r dull yn hynod ddibynadwy a syml, ond mae ganddo ddau anfantais amlwg:
- O gopi wrth gefn “oer”, ni allwch ond adfer cyflwr y gronfa ddata a oedd ar adeg cau; ni fydd trafodion a wneir ar ôl ailgychwyn y gronfa ddata yn cael eu cynnwys yn y copi wrth gefn “oer”;
- Nid oes gan bob cronfa ddata ffenestr dechnolegol pan ellir atal y gronfa ddata.
Os yw copi wrth gefn “oer” yn addas i chi, mae angen i chi gofio hynny
- Rhaid i gopi oer gynnwys logiau weithiau. Mae dulliau ar gyfer pennu'r logiau a ddylai fynd i mewn i'r copi “oer” yn unigol ar gyfer pob DBMS. Er enghraifft, yn Oracle mae angen copïo'r hyn a elwir yn ail-wneud ar-lein, hynny yw, nifer sefydlog o ffeiliau log mewn cyfeiriadur arbennig, hyd yn oed pan fydd y gronfa ddata yn cael ei stopio'n gywir. Yn PostgreSQL, rhaid i chi gadw'r holl logiau gan ddechrau gyda'r log sy'n cynnwys y pwynt gwirio olaf, y mae gwybodaeth amdano wedi'i chynnwys yn y ffeil reoli.
- Gall y cyfeiriadur cronfa ddata gynnwys ffeiliau gofod bwrdd dros dro sy'n ddigon mawr nad oes angen eu cynnwys yn y copi wrth gefn. Gyda llaw, mae'r sylw hwn hefyd yn wir ar gyfer copïau wrth gefn poeth.
Arbed ffeil poeth
Mae'r rhan fwyaf o'r copïau wrth gefn cronfa ddata modern yn cael eu perfformio trwy gopïo ffeiliau cronfa ddata heb atal y gronfa ddata. Mae yna sawl problem yma:
- Pan ddechreuir copïo, efallai na fydd cynnwys y gronfa ddata yn cyd-fynd â chynnwys y ffeiliau, gan fod rhywfaint o'r wybodaeth yn y storfa ac nad yw wedi'i hysgrifennu ar ddisg eto.
- Wrth gopïo, gall cynnwys y gronfa ddata newid. Os defnyddir strwythurau data mutable, mae cynnwys y ffeiliau'n newid, a phan ddefnyddir strwythurau na ellir eu cyfnewid, mae'r set o ffeiliau'n newid: mae ffeiliau newydd yn ymddangos a hen rai yn cael eu dileu.
- Gan nad yw ysgrifennu data i'r gronfa ddata a darllen ffeiliau cronfa ddata yn cael eu cysoni mewn unrhyw ffordd, gall y rhaglen wrth gefn ddarllen tudalen anghywir, lle bydd hanner o hen fersiwn y dudalen, a'r hanner arall o'r un newydd.
Er mwyn i'r copi wrth gefn fod yn gyson, mae gan bob DBMS orchymyn sy'n hysbysu bod y broses wrth gefn wedi dechrau. Yn syctactig, gall y gorchymyn hwn edrych yn wahanol:
- yn Oracle mae hwn yn orchymyn ar wahân NEWID CRONFA DDATA/GOFOD BWRDD WRTH GEFN;
- yn PostgreSQL - swyddogaeth pg_start_backup ();
- Yn Microsoft SQL Server a DB2, mae paratoi ar gyfer copi wrth gefn yn cael ei berfformio'n ymhlyg yn ystod gweithredu'r gorchymyn CRONFA DATA WRTH GEFN;
- yn MySQL Enterprise, Cassandra a MongoDB, mae paratoi yn cael ei berfformio'n ymhlyg gan gyfleustodau allanol - mysqlbackup, OpsCenter a Rheolwr Ops, yn y drefn honno.
Er gwaethaf y gwahaniaethau cystrawen, mae'r broses o baratoi ar gyfer copi wrth gefn yn edrych yr un peth.
Dyma sut olwg sydd ar baratoi ar gyfer copi wrth gefn mewn DBMS gyda strwythurau disg mutable, h.y. ym mhob system perthynol ddisg draddodiadol:
- Mae'r foment y dechreuodd y copi wrth gefn yn cael ei gofio; bydd angen i'r copi wrth gefn gynnwys logiau cronfa ddata o'r pwynt hwn ymlaen.
- Perfformir pwynt gwirio, hynny yw, mae'r holl newidiadau a ddigwyddodd yn y tudalennau data cyn yr eiliad a gofiwyd yn cael eu fflysio i ddisg. Mae hyn yn sicrhau nad oes angen unrhyw logiau cyn i'r copi wrth gefn ddechrau yn ystod adferiad.
- Mae modd logio arbennig wedi'i alluogi: os yw tudalen ddata wedi newid am y tro cyntaf ar ôl llwytho o ddisg, yna yn lle ysgrifennu newidiadau tudalen i'r log, bydd y gronfa ddata yn ysgrifennu'r dudalen gyfan yno. Wrth berfformio'r weithdrefn baratoi, mae pob tudalen yn cael ei fflysio i ddisg, felly y tro cyntaf y gwneir newid, bydd y bloc cyfan bob amser yn cael ei ysgrifennu i'r log. Ond os caiff y dudalen ei throi allan i ddisg eto yn ystod y broses wrth gefn, bydd y newid nesaf iddi hefyd yn arwain at gopi llawn o'r dudalen yn ymddangos yn y log. Mae hyn yn sicrhau os bydd y dudalen yn anghywir wrth gopïo ffeil ddata, bydd defnyddio log yn ei gwneud yn gywir eto.
- Mae newidiadau i benawdau ffeiliau data yn cael eu rhwystro, hynny yw, y rhan honno ohono nad yw ei newidiadau yn cael eu hadlewyrchu yn y logiau. Mae hyn yn sicrhau bod y pennawd yn cael ei gopïo'n gywir ac yna bod logiau'n cael eu cymhwyso'n gywir i'r ffeil ddata.
Ar ôl i'r holl weithdrefnau uchod gael eu cwblhau, gallwch gopïo ffeiliau data gan ddefnyddio offer system weithredu - cp, rsync ac eraill. Mae galluogi'r modd wrth gefn yn lleihau perfformiad y gronfa ddata: yn gyntaf, mae nifer y logiau'n cynyddu, ac yn ail, os bydd methiant sydyn yn digwydd yn y modd wrth gefn, bydd yr adferiad yn cymryd mwy o amser oherwydd nad yw penawdau'r ffeiliau data yn cael eu diweddaru. Po gyflymaf y cwblheir y copi wrth gefn, y gorau i'r gronfa ddata, felly mae'n briodol defnyddio offer o'r fath fel ciplun o'r system ffeiliau neu dorri'r drych (BCV) yn yr arae disg. Mae rhai DBMSs (Oracle, PostgreSQL) yn gadael y gweinyddwr y cyfle i ddewis y dull copïo yn annibynnol, mae eraill (Microsoft SQL Server) yn darparu rhyngwyneb ar gyfer integreiddio eu cyfleustodau wrth gefn eu hunain gyda system ffeiliau neu fecanweithiau storio.
Unwaith y bydd y copi wrth gefn wedi'i gwblhau, mae angen i chi ddychwelyd y gronfa ddata yn ôl i'w chyflwr arferol. Yn Oracle gwneir hyn gyda'r gorchymyn ALTER DATACASE/TABLESPACE END BACKUP , yn PostgreSQL trwy ffonio'r swyddogaeth pg_stop_backup(), ac mewn cronfeydd data eraill yn ôl arferion mewnol y gorchmynion cyfatebol neu'r gwasanaethau allanol.
Dyma sut olwg sydd ar linell amser y broses wrth gefn:
- Mae paratoi ar gyfer copi wrth gefn yn cymryd amser, weithiau cryn dipyn o amser. Hyd yn oed os defnyddir cyfeintiau wedi'u hadlewyrchu neu systemau ffeiliau sy'n gallu ciplun, ni fydd y broses wrth gefn yn digwydd ar unwaith.
- Ynghyd â'r ffeiliau data, mae angen arbed logiau o'r eiliad y byddwch chi'n dechrau paratoi ar gyfer gwneud copi wrth gefn hyd nes y bydd y gronfa ddata yn dychwelyd i'w chyflwr arferol.
- Gallwch chi adfer o'r copi wrth gefn hwn ar yr adeg y mae'r sylfaen yn dychwelyd i gyflwr arferol. Nid yw adfer i bwynt cynharach yn bosibl.
Gyda chronfeydd data sy'n defnyddio strwythurau data na ellir eu cyfnewid (cipluniau cof, coed LSM), mae'r sefyllfa'n symlach. Mae paratoi ar gyfer copi wrth gefn yn cynnwys y camau canlynol:
- Mae data o'r cof yn cael ei fflysio i ddisg.
- Mae'r rhestr o ffeiliau sydd wedi'u cynnwys yn y copi wrth gefn yn cael ei gofnodi. Hyd nes y bydd y broses wrth gefn wedi'i chwblhau, gwaherddir y gronfa ddata rhag dileu'r ffeiliau hyn, hyd yn oed os nad oes eu hangen mwyach.
Ar ôl cael arwydd bod y copi wrth gefn wedi'i gwblhau, gall y gronfa ddata gyda strwythurau na ellir ei chyfnewid ddileu ffeiliau diangen eto.
Adfer i bwynt
Mae copi wrth gefn yn eich galluogi i adfer cyflwr y gronfa ddata i'r eiliad pan fydd y gorchymyn dychwelyd o'r modd wrth gefn wedi'i gwblhau. Fodd bynnag, gall damwain sy'n gofyn am adferiad ddigwydd ar unrhyw adeg. Gelwir y dasg o adfer cyflwr cronfa ddata ar foment fympwyol yn “adferiad pwynt-mewn-amser”.
Er mwyn sicrhau bod hyn yn bosibl, dylech arbed logiau'r gronfa ddata gan ddechrau o ddiwedd y copi wrth gefn, ac yn ystod y broses adfer, parhewch i gymhwyso'r logiau i'r copi wedi'i adfer. Ar ôl i'r gronfa ddata gael ei hadfer o gopi wrth gefn ar yr adeg y cwblheir y copïo, mae cyflwr y gronfa ddata (ffeiliau a thudalennau wedi'u storio) yn sicr o fod yn gywir, felly nid oes angen dull logio arbennig. Trwy gymhwyso logiau i'r funud gywir, gallwch gael cyflwr y gronfa ddata ar unrhyw adeg.
Er bod y cyflymder y gellir adfer copi wrth gefn wedi'i gyfyngu gan led band disg yn unig, mae'r cyflymder y gellir defnyddio logiau fel arfer yn gyfyngedig gan berfformiad prosesydd. Os bydd newidiadau yn digwydd ochr yn ochr â'r brif gronfa ddata, yna yn ystod adferiad mae'r holl newidiadau yn cael eu perfformio yn ddilyniannol - yn y drefn y cânt eu darllen o'r log. Felly, mae'r amser adfer yn dibynnu'n llinol ar ba mor bell yw'r pwynt adfer o ddiwedd y copi wrth gefn. Oherwydd hyn, mae angen gwneud copïau wrth gefn llawn yn eithaf aml - o leiaf unwaith yr wythnos ar gyfer cronfeydd data gyda llwyth trafodion bach a hyd at gopïau dyddiol o gronfeydd data llawn llwyth.
copi wrth gefn cynyddrannol
Er mwyn cyflymu adferiad i bwynt, hoffwn allu perfformio copïau wrth gefn mor aml â phosibl, ond ar yr un pryd peidio â chymryd lle disg ychwanegol a pheidio â llwytho'r gronfa ddata gyda thasgau wrth gefn.
Yr ateb i'r broblem yw copi wrth gefn cynyddrannol, hynny yw, dim ond copïo'r tudalennau data hynny sydd wedi newid ers y copi wrth gefn blaenorol.
Mae copïau wrth gefn cynyddrannol yn gwneud synnwyr i DBMSs sy'n defnyddio strwythurau data mutable yn unig.
Gellir cyfrif y cynyddran naill ai o gopi wrth gefn llawn (copi cronnus) neu o unrhyw gopi blaenorol (copi gwahaniaethol).
Yn anffodus, nid oes terminoleg unffurf, ac mae gweithgynhyrchwyr gwahanol yn defnyddio termau gwahanol:
Gwahaniaethol
Cronnus
Oracle
Gwahaniaethol
Cronnus
PostgreSQL
Cynyddrannol
-
Microsoft SQL Gweinyddwr
-
Gwahaniaethol
IBM DB2
Delta
Cynyddrannol
Os oes copïau cynyddrannol, mae'r broses o adfer i bwynt fel a ganlyn:
- y copi wrth gefn llawn olaf a wnaed cyn i'r adferiad gael ei adfer;
- copďau cynyddrannol yn cael eu hadfer ar ben y copi llawn;
- caiff logiau eu rholio i fyny o'r man cychwyn wrth gefn i'r man adfer.
Mae cael copi cronnus yn cyflymu'r broses adfer. Felly, er enghraifft, i adfer cyflwr y gronfa ddata i bwynt rhwng T3 a T4, mae angen adfer dau gopi cynyddrannol, ac i adfer i bwynt ar ôl T4, dim ond un.
Yn amlwg, mae maint un copi cronnus yn llai na maint sawl copi gwahaniaethol, oherwydd mae rhai tudalennau wedi newid sawl gwaith, ac mae pob copi cynyddrannol yn cynnwys fersiwn wahanol o'r dudalen.
Mae tair ffordd o greu copi cynyddrannol:
- creu copi llawn a chyfrifo'r gwahaniaeth gyda'r copi llawn blaenorol;
- dosrannu logiau, creu rhestr o dudalennau wedi'u newid a gwneud copïau wrth gefn o dudalennau sydd wedi'u cynnwys yn y rhestr;
- yn cwestiynu tudalennau sydd wedi newid yn y gronfa ddata.
Mae'r dull cyntaf yn arbed lle ar y ddisg, ond nid yw'n lleihau'r llwyth ar y gronfa ddata. Ar ben hynny, os oes gennym gopi wrth gefn llawn, mae ei drosi i un cynyddrannol yn ddibwrpas, gan fod adfer copi wrth gefn llawn yn gyflymach nag adfer copi wrth gefn llawn blaenorol ac un cynyddrannol. Mae'n well dirprwyo'r dasg o arbed lle ar y ddisg gyda'r dull hwn i gydrannau arbenigol sydd â mecanweithiau dad-ddyblygu adeiledig. Gall y rhain fod naill ai'n systemau storio pwrpasol (EMC DataDomain, HPE StorageWorks VLS, y llinell NetApp gyfan) neu'n gynhyrchion meddalwedd (ZFS, Veritas NetBackup PureFile, Windows Server Dad-ddyblygu Data).
Mae'r ail a'r trydydd dull yn wahanol yn y mecanwaith ar gyfer pennu'r rhestr o dudalennau wedi'u newid. Mae dosrannu logiau yn fwy dwys o ran adnoddau, ac i'w gweithredu mae angen i chi wybod strwythur ffeiliau log. Y ffordd hawsaf yw gofyn i'r gronfa ddata ei hun pa dudalennau sydd wedi newid, ond ar gyfer hyn mae'n rhaid i'r cnewyllyn DBMS fod â swyddogaeth olrhain newid bloc.
Cyflwynwyd ymarferoldeb wrth gefn cynyddrannol gyntaf yn meddalwedd Oracle Recovery Manager (RMAN), a gyflwynwyd yn natganiad Oracle 8i. Gweithredodd Oracle olrhain blociau wedi'u newid ar unwaith, felly nid oes angen dosrannu logiau.
Nid yw PostgreSQL yn olrhain blociau wedi'u haddasu, felly mae'r cyfleustodau pg_probackup, a ddatblygwyd gan y cwmni Rwsiaidd Postgres Professional, yn pennu tudalennau wedi'u haddasu trwy ddadansoddi'r log. Fodd bynnag, mae'r cwmni hefyd yn cyflenwi'r PostgresPro DBMS, sy'n cynnwys yr estyniad ptrack sy'n olrhain newidiadau tudalen. Wrth ddefnyddio pg_probackup gyda'r PostgresPro DBMS, newidiodd y ceisiadau cyfleustodau dudalennau o'r gronfa ddata ei hun - yn union yr un fath â RMAN.
Mae Microsoft SQL Server, fel Oracle, yn olrhain tudalennau sydd wedi newid, ond mae'r gorchymyn BACKUP ond yn caniatáu ichi wneud copïau wrth gefn llawn a chronnus.
Mae gan DB2 y gallu i olrhain tudalennau sydd wedi newid, ond mae wedi'i analluogi yn ddiofyn. Unwaith y bydd wedi'i alluogi, bydd DB2 yn caniatáu copïau wrth gefn llawn, gwahaniaethol a chronnus.
Gwahaniaeth pwysig rhwng yr offer a ddisgrifir yn yr adran hon (ac eithrio pg_probackup) ac offer wrth gefn ffeiliau yw eu bod yn gofyn am ddelweddau tudalennau o'r gronfa ddata yn hytrach na darllen data o ddisg eu hunain. Anfantais y dull hwn yw llwyth ychwanegol bach ar y sylfaen. Fodd bynnag, mae'r anfantais hon yn fwy na digolledu am y ffaith bod y dudalen a ddarllenir bob amser yn gywir, felly nid oes angen galluogi modd logio arbennig yn ystod y copi wrth gefn.
Sylwch eto nad yw presenoldeb copïau cynyddrannol yn dileu'r gofyniad i gael boncyffion ar gael i'w hadfer hyd at gyfnod mympwyol. Felly, mewn cronfeydd data diwydiannol, mae logiau'n cael eu hailysgrifennu'n gyson i gyfryngau allanol, ac mae copïau wrth gefn, llawn a/neu gynyddrannol, yn cael eu creu ar amserlen.
Y gweithrediad gorau o'r syniad copi wrth gefn cynyddrannol heddiw yw'r Zero Data Loss Recovery Appliance, system caledwedd a meddalwedd (yn nherminoleg Oracle, system beirianyddol) – datrysiad Oracle arbenigol ar gyfer gwneud copi wrth gefn o'i gronfa ddata ei hun. Mae'r system yn glwstwr. gweinyddwyr Mae gan ZDLRA gapasiti disg mawr ac mae'n rhedeg fersiwn wedi'i haddasu o feddalwedd Recovery Manager. Gall weithio gyda systemau caledwedd a meddalwedd Oracle eraill (Database Appliance, Exadata, SPARC Supercluster) yn ogystal â chronfeydd data Oracle sy'n rhedeg ar seilwaith traddodiadol. Yn wahanol i RMAN "rheolaidd", mae ZDLRA yn gweithredu'r cysyniad "cynyddrannol am byth". Mae'r system yn creu copi cronfa ddata lawn unwaith, ac yna dim ond yn gwneud copïau cynyddrannol. Mae modiwlau RMAN ychwanegol yn caniatáu ichi uno copïau, gan greu copïau llawn newydd o rai cynyddrannol.
Er clod i ddatblygwyr Rwsia, dylid nodi y gall pg_probackup hefyd uno copïau cynyddrannol.
Yn wahanol i lawer o gwestiynau tebyg, mae gan y cwestiwn “pa ddull wrth gefn sy'n well” ateb clir - yr opsiwn gorau yw cyfleustodau sy'n gynhenid i'r DBMS sy'n cael ei ddefnyddio, sy'n darparu'r gallu ar gyfer copïau wrth gefn cynyddrannol.
I weinyddwr y gronfa ddata, mae'r mater o ddewis strategaeth wrth gefn ac integreiddio offer cronfa ddata wrth gefn i'r seilwaith corfforaethol yn bwysicach o lawer. Ond mae'r cwestiynau hyn y tu hwnt i gwmpas yr erthygl hon.
Ffynhonnell: hab.com
