Replikace jako Φinnost znamenß kopφrovßnφ dat z databßze do vφce (geograficky vzdßlen²ch) mφst za ·Φelem podpory distribuovan²ch aplikacφ. Kopie dat, resp. odpovφdajφcφ datovΘ struktury v t∞chto mφstech, se naz²vajφ repliky. Mary Loomis z HP definuje replikovan² objekt jako ôobjekt s vφce ne₧ jednou implementacφö. P°esto₧e jde z hlediska pouhΘ distribuce o starou ideu, vyskytujφcφ se ji₧ v starÜφch koncepcφch distribuovan²ch databßzov²ch systΘm∙ (DDBS), z hlediska °φzenφ replikovan²ch dat znamenß p°φstup novou, efektivn∞jÜφ variantu.

Replikace poskytuje u₧ivatel∙m lokßlnφ aktualizovatelnΘ kopie dat, kterΘ mohou b²t p°idßny k vlastnφm dat∙m, a umo₧≥uje tak informativn∞jÜφ lokßlnφ zpracovanφ, omezen∞jÜφ provoz sφt∞, jednoduÜÜφ Ükßlovßnφ a levn∞jÜφ p°φstup k distribuovanΘmu nep°etr₧itΘmu zpracovßnφ dat. Jednoduchou intuicφ se p°esv∞dΦφme, ₧e ne₧ provßd∞t spojenφ tabulek rozmφst∞n²ch v n∞kolika mφstech sφt∞, je efektivn∞jÜφ mφt pot°ebnß data replikovanß v mφst∞ zpracovßnφ dotazu. Jinou vhodnou aplikacφ replikacφ je zßlohovßnφ v reßlnΘm Φase, tj. na jinΘm, event. vzdßlenΘm mφst∞, je udr₧ovßna kopie Φßsti Φi celΘ databßze.

N∞kdy se rozvoj replikaΦnφ technologie dßvß do souvislosti s rozÜi°ovßnφm architektury klient-server do prost°edφ podniku rozmφst∞nΘho geograficky tak, ₧e klasickß technologie klient-server ji₧ nenφ p°φliÜ efektivnφ. Samoz°ejm∞, zajiÜt∞na by m∞la b²t globßlnφ integrita dat, tak jak byla tato idea propagovßna v technologii obecn∞jÜφch DDBS. Existujφ-li dv∞ kopie °ßdku relace na dvou r∙zn²ch mφstech, pak zm∞na jednΘ kopie by m∞la b²t propagovßna do druhΘ kopie.

Koncem r. 1995 se objevily u znßm²ch v²robc∙ S╪BD tzv. replikaΦnφ servery, kterΘ se staly zatφm nejefektivn∞jÜφm p°φstupem k implementaci distribuovan²ch databßzφ. Firma Sybase nap°. charakterizuje sv∙j replikaΦnφ server z rodiny SYBASE System 10 jako novou technologii, kterß optimalizuje sdφlenφ dat na ·rovni rozlehlΘho podniku. Jde o software, kter² zajiÜ¥uje °φzenφ aktualizace kopiφ pro jistou Φßst sφt∞ v jejich₧ mφstech existujφ replikovanß data. Obecn∞ji, v sφti m∙₧e (nap°. podle Sybase) existovat vφce replikaΦnφch server∙, s rozd∞len²mi pravomocemi, kterΘ o sob∞ navzßjem v∞dφ a dovedou spolu komunikovat. ReplikaΦnφ server Sybase m∙₧e b²t p°edsazen server∙m zalo₧en²m na jin²ch relaΦnφch i nerelaΦnφch S╪BD, tj. jeho uplatn∞nφ je i v heterogennφm DDBS.

Heterogennost prost°edφ pro replikace je specißlnφ problΘm, kter² komplikuje vlastnφ replikaΦnφ mechanismy. P°id∞lßvß dalÜφ Φasovou re₧ii pro pot°ebnΘ transformace dat apod. Na druhΘ stran∞ o nutnost. Firma Praxis International uvßdφ, ₧e typick² velk² podnik vyu₧φvß 8-9 r∙zn²ch databßzov²ch produkt∙ na r∙znΘm hardware pod r∙zn²mi operaΦnφmi systΘmy.

Databßzovß architektura zalo₧enß na replikaci musφ:

• spolehliv∞ dopravit replikovanß dat tam, kde je to pot°eba a kdy₧ je to pot°eba,
• automaticky synchronizovat vÜechny kopie po chyb∞,
• co nejrychleji propagovat zm∞ny,
• chrßnit transakΦnφ a logickou integritu dat
• replikovat data z (do) heterogennφch transakΦnφch server∙, kterΘ b∞₧φ na platformßch od r∙zn²ch v²robc∙,
• podporovat nßvrh aplikace, kter² je v souladu s pravidly podniku (organizaΦnφ struktury, schΘma dat, integritnφ omezenφ).

Technologii replikacφ na ·rovni transakΦnφho zpracovßnφ je takΘ mo₧nΘ chßpat jako reakci na rigidnost dvoufßzovΘho potvrzovacφho protokolu (2PC), kter² v DDBS p°i 50 a vφce mφstech s distribuovan²mi daty vede k velmi nepraktick²m aktualizacφm. Jde hlavn∞ o problΘmy s dostupnostφ zdroj∙ (°eÜφ se, co d∞lat, je-li jedinß kopie dat na nedostupnΘm mφst∞, nebo Φekß-li na ni dlouhß fronta po₧adavk∙). Nedostupnost zdroje m∙₧e b²t dßna nejen p°eruÜenφm spojenφ, ale i neexistenci spojenφ, jak je dnes mφn∞no v architekturßch s mobilnφmi poΦφtaΦi. DalÜφm problΘmem je pomalost provozu, kterß m∙₧e nastat p°i nepredikovateln∞ rozsßhl²ch p°enosech dat v sφti p°i jist²ch distribuovan²ch dotazech. T°etφm problΘmem je r∙znorodost ·loh v distribuovanΘm prost°edφ, kde vylad∞nφ jednoho typu ·loh nep°eje druhΘmu a naopak (viz dßle). Uvidφme, ₧e replikaΦnφ p°φstup uvol≥uje t∞snß spojenφ mφst tak typickß pro klasick² DDBS. Aplikace bude vφce odd∞lena od kopiφ dat, ne₧ tak jak to vy₧aduje logika 2PC.

ReplikaΦnφ p°φstup pokr²vß v nejhrubÜφm d∞lenφ dv∞ t°φdy aplikacφ. Prvnφ z nich jsou dnes tzv. velkosklady dat (data warehouses) Φi systΘmy podporujφcφ rozhodovßnφ (decision support systems - DSS), kdy v mφst∞ u₧ivatele jsou pot°eba data konsistentnφ v jistΘm minulΘm ΦasovΘm okam₧iku nebo vφce okam₧icφch (historickß data). P°φpadn∞ jsou pot°eba data z nedßvnΘ minulosti (ne p°φliÜ starß kopie). Tento p°φstup vystaΦφ nejspφÜe s kopiemi pro uspokojenφ po₧adavk∙ typu read-only, na kter²ch lze provßd∞t dalÜφ operace. P°φkladem software, kter² je zalo₧en tomto p°φstupu, je nap°. Information Warehouse firmy IBM.

Naopak, replikace dat vhodnß pro operativu, tj. k on-line transakΦnφmu zpracovßnφ (OLTP), sm∞°ujφ bu∩ k extremßlnφmu p°φstupu DDBS (globßlnφ schΘma + 2PC, tj. synchronn∞ aktualizovan∞ repliky dat) nebo k mφrn∞jÜφ variant∞ s asynchronn∞ aktualizovan²mi replikami dat. Asynchronnost zde znamenß, ₧e zm∞ny dat jsou propagovßny do kopiφ v r∙zn²ch mφstech ne nutn∞ v rßmci aplikaΦnφ transakce, i kdy₧ tak, aby vÜe prob∞hlo co nejblφ₧e reßlnΘmu Φasu. Nejde tedy o ₧ßdnΘ nap°. periodickΘ Φi odklßdanΘ aktualizace, jak tomu bylo v n∞kter²ch d°φv∞jÜφch souborov²ch systΘmech. SouΦasn² provoz DSS a OLTP v DDBS vede k Φinnostem, kterΘ jdou proti sob∞, a replikace tak tvo°φ rozumn² kompromis.

Pou₧itelnost jednotliv²ch p°φstup∙ zßvisφ na globßlnφ situaci v sφti a po₧adavcφch na provoz. Synchronnφ p°φstup je nutn² tam, kde vy₧adujeme co nejaktußln∞jÜφ data (·plnß konzistence), k dispozici vÜak musφ b²t rychlß sφ¥, vysokß dostupnost server∙. U asynchronnφch zm∞n dat by aplikace nem∞la na t∞chto faktorech b²t p°φliÜ zßvislß (volnß konzistence). Zam∞°φme se hlavn∞ na replikaΦnφ slu₧by tohoto typu.

Replikovat lze celΘ tabulky nebo Φßst databßze, kterß vznikne jako v²sledek dotazu. Ve druhΘm p°φpad∞ se obvykle rozliÜuje read-only kopie, resp. momentka (snapshot). Momentky jsou v²sledky dotazu nad zßkladnφmi relacemi z jednoho (n∞kolika) mφst, do kter²ch se periodicky promφtajφ aktualizace °φzenΘ z jednoho mφsta. Mφsta mohou momentku, kterou nemajφ prßvo aktualizovat, pouze Φφst. Uvidφme vÜak, ₧e existujφ varianty, kdy aktualizace je v t∞chto p°φpadech mo₧nß p°φmo v mφstech, kde vznikß.

Dotaz, kter² definuje momentku, obvykle nenφ zcela obecn². Z hlediska terminologie DDBS je mo₧nß vertikßlnφ i horizontßlnφ fragmentace. NejΦast∞ji jsou povoleny momentky pouze nad jednou relacφ, i kdy₧ z hlediska zpracovßnφ by bylo neju₧iteΦn∞jÜφ p°ipustit spojenφ tabulek (viz nap°. p°φstup ORACLE 7) a umo₧nit tak p°edp°ipravit pro u₧ivatele data tak, aby byly umo₧n∞ny nap°. preferovanΘ dotazy.

Replikace se m∙₧e nachßzet na tomtΘ₧ severu, kde se nachßzφ primßrnφ kopie, nebo je umφst∞na na jinΘm serveru v lokßlnφ sφti, nachßzet se vÜak m∙₧e i na vzdßlenΘm serveru sφt∞.

Replikace lze provßd∞t r∙zn²mi zp∙soby. V jednΘ klasifikaci lze replikace chßpat vzhledem k dan²m mo₧nostem aktualizace. RozliÜujφ se systΘmy nßsledujφcφch dvou typ∙ (obrßzek 1):

• jeden aktualizuje (jednosm∞rnΘ systΘmy)

Prßvo aktualizovat mß jeden u₧ivatel nebo skupina u₧ivatel∙ nad jednφm zdrojem. Provoz m∙₧e vΘst k b∞₧nΘmu zpracovßnφ paralelnφch transakcφ, kde hraje roli pojem uspo°ßdatelnosti. Replikace je podporovßna distribucφ pouze read-only kopiφ nebo momentek. V tomto p°φpad∞ nenastßvajφ ₧ßdnΘ problΘmy s konflikty, kterΘ mohou zap°φΦinit nezßvislΘ aktualizace kopiφ t²ch₧ dat. Mohou ale nastat problΘmy s v²konem, jsou-li pro aktualizace kopiφ nutnΘ n∞jakΘ transformace dat, nebo jsou-li mφsta obsahujφcφ kopie heterogennφ.

• n∞kolik jich aktualizuje (obousm∞rnΘ, symetrickΘ systΘmy)

Pak je situace podobnß b∞₧nΘmu on-line zpracovßnφ transakcφ, pouze s tφm rozdφlem, ₧e u asynchronnφho replikaΦnφho systΘmu nenφ k dispozici ₧ßdn² blokovacφ (uzamykacφ) mechanismus. Vznikajφ tedy kolize.

Implementace aktualizacφ m∙₧e takΘ zahrnovat aktualizaci vφce momentek dohromady. V p°φstupu Oracle se hovo°φ o skupinovΘ aktualizaci. Aktualizace momentek m∙₧e b²t rychlß, kdy se do repliky promφtajφ pouze skuteΦnΘ zm∞ny dat, nebo ·plnß, kdy se jednoduÜe nahradφ celß replikace nov∞jÜφ verzφ. Tento p°φstup je mo₧n² nap°. v ORACLE 7.

Uve∩me jeÜt∞ dva pojmy, kterΘ se vyskytujφ v souvislosti s °φzenφm aktualizace replik. Mφsto, odkud je iniciovßna zm∞na, se naz²vß vydavatel (publisher), mφsto, kterΘ p°ijφmß zm∞nu replikovanΘ databßze, je p°edplatitel (subscriber). U obousm∞rn²ch systΘm∙ m∙₧e b²t vydavatel takΘ p°edplatitelem a naopak. Vydavatel nap°. odpovφdß za aktualizaci momentky. Z hlediska organizace aktualizacφ kopiφ se rozliÜuje p°φstup peer-to-peer, kdy aktualizace kopie m∙₧e b²t provedena v libovolnΘm mφst∞ a je propagovßna do ostatnφch mφst. V p°φstupu master-slave je nutnΘ aktualizovat nejprve primßrnφ kopii na mφst∞ oznaΦenΘm jako master a tu pak propagovat do dalÜφch mφst. Je patrnΘ, ₧e slabΘ mφsto tΘto architektury je mo₧nost chyby nebo nedostupnost serveru s primßrnφ kopiφ dat. To m∙₧e vadit tehdy, kdy₧ je t°eba provßd∞t aktualizace v lokßlnφch mφstech, ovÜem p°es primßrnφ sever, kter² nereaguje.

mφsto 1 mφsto 2 mφsto 1 mφsto 2

primßrnφ

kopie replika replika replika

replika replika replika replika

mφsto 3 mφsto 4 mφsto 3 mφsto 4

Obr. 1 Jednosm∞rn² a obousm∞rn² replikaΦnφ systΘm

P°edstaviteli obou p°φstup∙ byl hlavn∞ CA-Ingres a Sybase (v danΘm po°adφ). Je jistΘ, ₧e master-slave p°φstup je jednoduÜÜφ k implementaci, vede k rychlejÜφmu provozu, dßvß lepÜφ p°edpoklady pro zotavenφ z chyb. Jde ale o mΘn∞ obecnΘ °eÜenφ. Jde o °eÜenφ, kter²m zaΦφnala v∞tÜina v²robc∙ relaΦnφch S╪BD. Dnes jak replikaΦnφ server Sybase, tak Enterprise server Oracle, ale i SQL Sever 6.5 umo₧≥ujφ obousm∞rnou replikaci. Informix pou₧φvß pro obousm∞rnou replikaci produkt Praxis International - OmniReplicator. Informix ovÜem dnes pou₧φvß pokroΦilejÜφ techniku k replikaci - tzv. kontinußlnφ replikaci dat [ In96] , kterß je integrßlnφ souΦßstφ S╪BD a nikoliv externφho replikaΦnφho serveru.

Stojφ za zmφnku, ₧e obousm∞rnß replikace se stala znßmou v pojetφ Lotus Notes na zßklad∞ idejφ, kterΘ se objevily ji₧ v r. 1985, kdy firma Iris Associates vyvφjela Notes. Lotus Notes je ovÜem (kdy₧ u₧) spφÜe hierarchickß databßze, kde problΘmy s kolizemi nejsou stejnΘ jako u pou₧itφ relaΦnφch S╪BD.

Vedle urΦenφ, kdo bude aktualizovat, je takΘ d∙le₧itΘ urΦit jak. Aktualizace lze provßd∞t propagovßnφm zm∞n °ßdk∙ relacφ do mφst s replikami (tzv. datovß replikace), nebo propagacφ volßnφ procedur (spolu s hodnotami parametr∙) do lokßlnφch mφst (transakΦnφ replikace). V prvnφm p°φpad∞ se p°enßÜφ starß a novß hodnota atribut∙ pro eventußlnφ °eÜenφ konflikt∙. Ve druhΘm p°φpad∞ °eÜφ konflikty sama lokßlnφ transakce. Pro asynchronnφ °φzenφ aktualizace replik je vhodnΘ uva₧ovat po₧adavky ve front∞. Ta se naz²vß distribuΦnφ (v p°φstupu ORACLE se mluvφ o front∞ odlo₧en²ch volßnφ procedur). Nenφ-li po₧adovanΘ mφsto dostupnΘ, po₧adavek z∙stßvß dßle ve front∞, v opaΦnΘm p°φpad∞ se ôprotlaΦφö na danΘ mφsto. V architektu°e Sybase jde vesm∞s o Φinnosti vykonßvanΘ replikaΦnΘm serverem.

V DDBS je aktualizace dat synchronnφ, tj. jsou-li data replikovßna ve vφce mφstech, provßdφ se jako jedna transakce. V replikaΦnφch systΘmech je aktualizace rozlo₧ena do vφce transakcφ. Mφsto jedinΘho dvoufßzovΘho potvrzenφ (jak je tomu v DDBS) je v systΘmu s n replikami jednoho datovΘho objektu po₧adovßno n samostatn²ch pou₧itφ 2PC. Riskujφ se ovÜem kolize mezi jednotliv²mi mφsty, kde se kopie nachßzejφ. Kolize nastane v okam₧iku, kdy jsou dv∞ kopie aktualizovßny dv∞ma r∙zn²mi aplikacemi ve stejnΘm ΦasovΘm intervalu. ┌kolem replikaΦnφho software je °φdit °eÜenφ t∞chto kolizφ.

ReplikaΦnφ p°φstup je mnohem vφce tolerantnφ k chybßm, ne₧ je tomu DDBS, jakßkoliv chyba v sφti zap°φΦinφ ROLLBACK transakcφ, kter²ch se dot²kß. Vedle toho transakce u₧φvajφcφ replikace je ·sp∞Ünß, jestli₧e je potvrzena ji₧ v jednom mφst∞ (v peer-to-peer p°φstupu) nebo v mφst∞ s primßrnφmi kopiemi dat (master-slave p°φstup).

Kolize p°i provßd∞nφ odlo₧en²ch aktualizacφ na vzdßlen²ch mφstech v peer-to-peer p°φstupu se mohou objevit u ka₧dΘho typu aktualizaΦnφ operace. P°i vklßdßnφ °ßdku (INSERT) do tabulky m∙₧e dojφt ke konfliktu s primßrnφm klφΦem (°ßdek s dan²m klφΦem ji₧ existuje). P°i odstra≥ovßnφ °ßdku (DELETE) se m∙₧e stßt, ₧e °ßdek ji₧ byl p°ed tφm odstran∞n, nebo byl zm∞n∞n, po tom, co byl odstran∞n z mφsta vydavatele. P°i modifikaci °ßdku se m∙₧e objevit, ₧e °ßdek ji₧ byl odstran∞n nebo byl zm∞n∞n, nebo novΘ hodnoty naruÜujφ omezenφ primßrnφho klφΦe.

Obecn∞ platφ, ₧e nelze zkonstruovat univerzßlnφ °eÜenφ pro vÜechny databßze nezßvisle na aplikacφch. ReplikaΦnφ server by m∞l ale podporovat °eÜenφ kolizφ. Prvnφ podstatn² krok je oznßmenφ kolize v okam₧iku jejφho v²skytu. Pro °eÜenφ kolizφ musφ replikaΦnφ server udr₧ovat pro ka₧dou potvrzenou transakci ₧urnßl pro vÜechny procesy, kterΘ se dostanou p°i propagaci tΘto transakce do dalÜφch mφst.

K °eÜenφ kolizφ by m∞ly b²t k dispozici r∙znΘ strategie. Pat°φ mezi n∞ nap°.:

• Prioritu mß poΦßteΦnφ aktualizace. Na konfliktnφ (pozd∞jÜφ) transakce se uplatnφ ROLLBACK.
• Prioritu mß poslednφ aktualizace. Dojde k p°episu konfliktnφch aktualizacφ.
• Kolize se °eÜφ aktivacφ u₧ivatelem napsanΘho triggeru.
• ReplikaΦnφ proces se pozdr₧φ a zaÜle se zprßva sprßvci distribuovanΘ databßze.

╪ada t∞chto strategiφ vyu₧φvß slu₧by v poskytovßnφ Φasu, kter² je synchronizovßn v distribuovanΘm prost°edφ. To nemusφ b²t v₧dy reßln² p°edpoklad a v²sledkem je chybnΘ °eÜenφ.