COMPUTERWORLD
pod kapotou
Replikace

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.

Jak vypadá replika

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ě.

Formy replikace

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.

Replikační zpracování vs. dvoufázový potvrzovací protokol

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 a jejich řešení

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í.



<seznam dílů seriálu>   <COMPUTERWORLD>