Synchronizace a replikace geodat v prostˇ red´ı Esri platformy Mark´eta Solansk´a Katedra geoinformatiky, Pˇr´ırodovˇedeck´ a fakulta, Univerzita Palack´eho v Olomouci, ˇ 17. listopadu 50, 779 00 Olomouc, Cesk´ a republika,
[email protected]
Abstrakt Tato pr´ ace hodnot´ı moˇznosti dostupn´ ych replikaˇcn´ıch ˇreˇsen´ı a na z´ akladˇe toho navrhuje datab´ azov´e ˇreˇsen´ı s ohledem na moˇznosti a poˇzadavky katedry. V reˇserˇs´ı ˇc´ asti byly vymezeny pojmy synchronizace, replikace a souvisej´ıc´ı pojem verzov´ an´ı a pops´ ana replikace vˇcetnˇe variant synchronn´ı, asynchronn´ı, jednosmˇern´e, obousmˇern´e, kask´ adov´e, logick´e i fyzick´e. Byly rozebr´ any poˇzadavky na datab´ azov´e ukl´ ad´ an´ı dat jednotliv´ ych produkt˚ u ArcGIS a byla podrobnˇe pops´ ana technologie ArcSDE, kter´ a se v ArcGIS produktech pouˇz´ıv´ a pro pˇripojen´ı k datab´ azi. Na z´ akladˇe reˇserˇse byl vybr´ an datab´ azov´ y syst´em PostgreSQL, kter´ y je moˇzno pouˇz´ıt v kombinaci s produkty ArcGIS, coˇz bylo jedn´ım z hlavn´ıch poˇzadavk˚ u pro v´ ybˇer datab´ azov´eho syst´emu. Byl sestaven n´ avrh datab´ azov´eho ˇreˇsen´ı, kter´ y zohledˇ nuje vˇsechny poˇzadavky katedry a moˇznosti dan´ ych technologi´ı. Bylo vytvoˇreno testovac´ı prostˇred´ı na serveru poskytnut´em katedrou, na nˇemˇz byly dan´e procesy otestov´ any. Na z´ akladˇe toho byl pak seps´ an podrobn´ y popis toho, jak nastavit replikaci ve variantˇe streaming a Slony-I. N´ avrh zahrnuje tak´e moˇznost pouˇzit´ı n´ astroje pgpool pro rozloˇzen´ı z´ atˇeˇze mezi servery v datab´ azov´em clusteru.
Klov slova: replikace, synchronizace, verzov´ an´ı, datab´ azov´ y syst´em, PostgreSQL, ArcSDE, ArcGIS
Abstract. The main goal of this thesis is to evaluate options of replication solutions which are available and based on this research design a database solution which considers possibilities and requirements of the Department of Geoinformatics. In the theoretical part terms replication, synchronization and versioning are defined including description of synchronous, asynchronous, master-slave, multimaster, cascade, logical and physical replication. The requirements of ArcGIS products for storage of data in database were considered and ArcSDE Technology which is used by ArcGIS products for database storage of spatial data was described. Based on the research database management system PostgreSQL was chosen because it is supported by ArcGIS products. The design of the database solution was created based on all requirements and the main processes were tested. Based on that a manual of the proposed replication solution setup was written. Two replication options were tested
- PostgreSQL native streaming replication and replication using PostgreSQL extension Slony-I. The design includes a description of usage of pgpool utility used for load-balancing. Keywords: replication, synchronization, versioning, database management system, PostgreSQL, ArcSDE, ArcGIS
1
´ Uvod
Dneˇsn´ı trend je ukl´ adat a ponech´avat st´ale v´ıce dat pouze v digit´aln´ı podobˇe. Mnoho dokument˚ u uˇz se v˚ ubec netiskne do pap´ırov´e podoby, coˇz podporuje i trend elektronick´ ych schr´ anek a podpis˚ u. S pˇrib´ yvaj´ıc´ım mnoˇzstv´ım dat je vˇsak tˇreba ˇreˇsit komplikace, kter´e informace uloˇzen´e pouze v elektronick´e podobˇe pˇrin´ aˇsej´ı. Poˇc´ıtaˇcov´ı experti ˇreˇs´ı napˇr´ıklad ot´azky, kam ukl´adat tak velk´e mnoˇzstv´ı dat, jak data efektivnˇe aktualizovat, jak zabr´anit poˇskozen´ı dat at’ uˇz zp˚ usoben´ ych lidsk´ ym faktorem ˇci chybou hardware. V pˇr´ıpadˇe, ˇze se poˇskod´ı disk, m˚ uˇzeme ˇcasto bˇehem okamˇziku pˇrij´ıt o vˇsechna data, nˇekdy vˇsak pro ztr´atu dat staˇc´ı pouze stisknout tlaˇc´ıtko na kl´avesnici. Vhodn´ ym zp˚ usobem uchov´av´an´ı dat je ukl´adan´ı do datab´aze s n´aslednou replikac´ı. Replikac´ı je myˇslena pokroˇcil´a funkcionalita, kter´a zajiˇst’uje kopii dat na v´ıce server˚ u. Nab´ız´ı ji vˇetˇsina dneˇsn´ıch datab´azov´ ych server˚ u, zajiˇst’uje vˇetˇs´ı robustnost datab´ aze a vysokou dostupnost dat. Replikaci lze vyuˇz´ıt ve vˇsech odvˇetv´ıch, kter´ a pracuj´ı s daty. V´ yjimkou nen´ı ani geoinformatika, kter´a ˇcasto pracuje s velk´ ymi objemy dat, kter´e nesou informaci o geografick´e poloze. Pr´avˇe reprezentace geografick´e polohy, skrze textov´ y z´apis souˇradnic dan´ ych bod˚ u, m˚ uˇze zp˚ usobit razantn´ı zv´ yˇsen´ı objemu dat. U webov´ ych map se mus´ı ˇreˇsit velk´ y poˇcet dotaz˚ u do datab´aze, protoˇze napˇr´ıklad kaˇzd´e posunut´ı v´ yˇrezu ˇci pˇribl´ıˇzen´ı, resp. odd´alen´ı v´ yˇrezu mapy, je samostatn´ ym dotazem, kter´ y mus´ı kapacita serveru zvl´adat. Napˇr´ıklad pokud bude uˇzivatel proch´ azet pl´ anovanou 100km trasu posouv´an´ım v´ yˇrezu mapy po 10 km, m˚ uˇze to serveru zp˚ usobit velkou z´atˇeˇz. Replikaci ocen´ı uˇzivatel´e pracuj´ıc´ı na spoleˇcn´em projektu, distribuovan´a pracoviˇstˇe i spoleˇcnosti s velk´ ym mnoˇzstv´ım d˚ uleˇzit´ ych dat, jejichˇz dostupnost je rozhoduj´ıc´ı pro jejich fungov´an´ı.
2
Pouˇ zit´ e metody a programov´ e komponenty
Konfigurace replikace zahrnovala studium n´avod˚ u jednotliv´ ych n´astroj˚ u pro replikaci, v´ ybˇer vhodn´ ych programov´ ych komponent a jejich n´asledn´e praktick´e nastaven´ı. To bylo testov´ ano pr˚ ubˇeˇznˇe na nˇekolika poˇc´ıtaˇc´ıch. Jako datab´ azov´ y server byl zvolen PostgreSQL s plnou podporou pro spr´avu prostorov´ ych dat, kter´ a je zajiˇstˇena n´adstavbou PostGIS. Pro replikaci byla zvolena nativn´ı PostgreSQL streaming replikace a extern´ı n´astroj Slony-I. Pro efektivn´ı vyuˇz´ıv´ an´ı datab´ aze byl d´ale vybr´an extern´ı n´astroj pgpool, kter´ y zajiˇst’uje sn´ıˇzen´ı z´ atˇeˇze jednotliv´ ych server˚ u rovnomˇern´ ym rozkl´ad´an´ım dotaz˚ u od klient˚ u mezi jednotliv´e datab´ aze.
N´ astroj pro replikaci Slony-I byl testov´an na operaˇcn´ım syst´emu Ubuntu GNU/Linux 12.4 a z´ aroveˇ n na operaˇcn´ım syst´emu Windows XP. Nativn´ı PostgreSQL streaming replikace byla testov´ana pouze na operaˇcn´ım syst´emu Linux. Server geohydro.upol.cz byl poskytnut jako testovan´ı server pro tuto pr´ aci. Na server byl nainstalov´an 32bitov´ y operaˇcn´ı syst´em Debian GNU/Linux 7.3, kter´ y byl vybr´ an kv˚ uli jeho stabilitˇe a jevil se tedy pro server jako vhodn´ y. Tato verze ovˇsem umoˇznila instalaci pouze program˚ u verz´ı PostgreSQL 9.1, PostGIS 1.5 a pgpool 3.1. Vzhledem k tomu, ˇze se nejedn´a o nejnovˇejˇs´ı verze zm´ınˇen´ ych produkt˚ u, byla replikace testov´ana tak´e na osobn´ım poˇc´ıtaˇci ve verz´ıch PostgreSQL 9.3, PostGIS 2.1 a pgpool 3.3. To umoˇznilo nastudov´an´ı dalˇs´ıch moˇznost´ı, kter´e nov´e verze pˇrin´aˇs´ı a kter´e byly zohlednˇeny v n´avrhu replikaˇcn´ıho ˇreˇsen´ı. Pro testov´ an´ı byla pouˇz´ıv´ana uk´azkov´a prostorov´a data vytvoˇren´a pro u ´ˇcel ˇ ve verzi 3.0. t´eto pr´ ace a d´ ale byla na server uloˇzena datov´a sada ArcCR
3
Vymezen´ı pojm˚ u
Datab´ aze je strukturovan´ a kolekce dat, kter´a slouˇz´ı pro efektivn´ı ukl´ad´an´ı dat a jejich zpˇetnˇe ˇcten´ı [1]. V relaˇcn´ı datab´azi jsou data ukl´ad´ana ve formˇe tabulek, tedy entit a atribut˚ u, kter´e jsou vz´ajemnˇe propojeny vazbami mezi entitami [2]. Toto logick´e uloˇzen´ı vazeb mezi tabulkami umoˇzn ˇuje efektivn´ı manipulaci s daty, rychl´e vyhled´ av´ an´ı i komplexn´ı anal´ yzu [3]. Obvykle se rozliˇsuj´ı pojem datab´aze, kter´ y odkazuje na obecn´ y koncept, a pojem datab´ azov´ y syst´em nebo pˇresnˇeji syst´em ˇr´ızen´ı b´ aze dat 1 , coˇz je konkr´etn´ım ˇ poˇc´ıtaˇcov´ ym program, kter´ y zajiˇst’uje fyzick´e uloˇzen´ı dat. Modern´ı SRBD jsou navrˇzeny na principu klient/server, kdy datab´aze bˇeˇz´ı jako sluˇzba na pozad´ı a ˇcek´ a na dotazy od klient˚ u. Server uˇzivatel˚ um umoˇzn ˇuje skrze jazyk SQL pˇr´ıstupovat k datab´ azi, vytv´aˇret a aktualizovat data, stejnˇe jak jako vyhled´avat ˇci analyzovat [2]. Prostorov´ a datab´ aze, nˇekdy tak´e zvan´a geodatab´ aze, nen´ı nic jin´eho neˇz datab´ aze obohacen´ a o datov´ y typ urˇcen´ y pro ukl´ad´an´ı prostorov´e informace o prvku, prostorov´e indexy a sadu funkc´ı vhodn´ ych pro spr´avu prostorov´ ych dat. Dnes umoˇzn ˇuj´ı ukl´ adat prostorov´a data napˇr´ıklad datab´azov´e syst´emy PostgreSQL 9.x, Microsoft SQL Server, Oracle Database, MySQL nebo SQLite. Pojmy replikace a synchronizace nˇekter´e zdroje rozliˇsuj´ı, jin´e je naopak povaˇzuj´ı za synonyma. Vˇsechny zm´ınˇen´e pojmy souvis´ı se z´alohov´an´ım dat, tedy kop´ırovan´ım dat mezi dvˇemi a v´ıce uloˇziˇsti, a se liˇs´ı konkr´etn´ım d˚ uvodem pro pouˇzit´ı dan´eho procesu. O synchronizaci soubor˚ u ˇci datov´ ych sloˇzek je moˇzno mluvit v pˇr´ıpadˇe, ˇze existuj´ı dva datov´e zdroje, kter´e je potˇreba v dan´ y okamˇzik sjednotit. Jde tedy o proces, kter´ y prob´ıh´ a jednor´azovˇe a to vˇetˇsinou z d˚ uvod˚ u potˇreby porovn´an´ı dvou a v´ıce datov´ ych uloˇziˇst’, kter´e je potˇreba dostat do totoˇzn´eho stavu. To m˚ uˇze napˇr´ıklad pˇrispˇet snazˇs´ı spolupr´aci v´ıce uˇzivatel˚ u nad stejn´ ymi daty nebo pomoct 1
angl. Database Management System (DBMS)
uˇzivateli, kter´ y pracuje na v´ıce poˇc´ıtaˇc´ıch. Proces m˚ uˇze probˇehnout jednou nebo opakovanˇe, at’ uˇz pravidelnˇe ˇci nepravidelnˇe. U soubor˚ u se shodn´ ym n´azvem se porovn´ av´ a ˇcas posledn´ıho z´ apisu, velikost nebo obsah souboru, naopak soubory, u kter´ ych nen´ı nalezena shoda, jsou jednoduˇse zkop´ırov´any. Replikace je proces pr˚ ubˇeˇzn´ y, kter´ y soustavnˇe hl´ıd´a, zda ve zdrojov´ ych datech nedoˇslo ke zmˇenˇe, a pokud ano, dan´e zmˇeny zkop´ıruje na jin´e datov´e uloˇziˇstˇe. ˇ Casto je tento proces pouˇz´ıv´an pr´avˇe ve spojitosti s datab´azemi, kdy jsou data kop´ırov´ ana z d˚ uvodu sn´ıˇzen´ı z´atˇeˇze serveru, ˇci zv´ yˇsen´ı ochrany dat. Replikace je tedy ˇcasto vyˇzadov´ ana z jin´ ych d˚ uvod˚ u neˇz synchronizace, zaˇc´ın´a s daty existuj´ıc´ımi pouze na jednom uloˇziˇsti a pro zajiˇstˇen´ı konzistence dat pouˇz´ıv´a jin´ ych technologi´ı. V´ıce se replikac´ı zab´ yv´a kapitola 3.1. Oba procesy je moˇzno pouˇz´ıt jednostrannˇe, tedy kop´ırovat data pouze z jednoho uloˇziˇstˇe na druh´e a nikoliv opaˇcnˇe, nebo oboustranˇe, kdy se data kop´ıruj´ı navz´ ajem mezi sebou. 3.1
Replikace
Replikace je proces, u kter´eho jsou data a datab´azov´e objekty kop´ırov´any z jednoho datab´ azov´eho serveru na druh´ y a pot´e synchronizov´any pro zachov´an´ı identity obou datab´ az´ı. Synchronizac´ı je v tomto pˇr´ıpadˇe myˇsleno kop´ırov´an´ı vˇsech zmˇen, kter´e v datab´ azi nastanou. Pouˇzit´ım replikace je moˇzno data distribuovat na r˚ uznˇe vzd´ alen´ a m´ısta nebo mezi mobiln´ı uˇzivatele v r´amci poˇc´ıtaˇcov´e s´ıtˇe a internetu [4]. V´ yvoj´ aˇri mnoh´ ych modern´ıch aplikac´ı se mus´ı zab´ yvat pˇret´ıˇzen´ım serveru zp˚ usoben´ ych velk´ ym poˇctem souˇcasn´ ych pˇr´ıstup˚ u do datab´aze. V pˇr´ıpadˇe pˇret´ıˇzen´ı se prodlouˇz´ı odezva serveru, data tedy pˇrich´azej´ı k uˇzivateli pomalu, nebo server dokonce u ´plnˇe spadne. Mezi ˇcast´e d˚ uvody pouˇzit´ı datab´azov´e replikace tedy patˇr´ı zajiˇstˇen´ı dostupnosti dat2 , resp. sn´ıˇzen´ı pravdˇepodobnosti, ˇze data nebudou dostupn´a [5]. Dalˇs´ı d˚ uvodem je rozloˇzen´ı pˇr´ıstup˚ u do datab´aze mezi v´ıce server˚ u, takˇze nebude doch´ azet ke zpomalen´ı v´ ykonu hlavn´ıho serveru [6]. Ke zpomalen´ı serveru doch´az´ı tak´e pˇri z´ alohov´ an´ı, coˇz lze ˇreˇsit replikac´ı dat na jin´ y server, na kter´em je pak proces z´ alohov´ an´ı spuˇstˇen. Vˇsechny datab´ azov´e servery zapojen´e do procesu replikace jsou v odborn´e literatuˇre naz´ yv´ any uzly, angl. node. Tyto uzly dohromady tvoˇr´ı replikaˇcn´ı cluster 3 . Pˇri spr´ avnˇe nastaven´e replikaci, jej´ımˇz c´ılem je zajiˇstˇen´ı vysok´e dostupnosti dat (HA), by v clusteru nikdy nemˇely b´ yt m´enˇe neˇz tˇri uzly. M˚ uˇze se totiˇz st´at, ˇze vypadne jeden ze dvou uzl˚ u, ˇc´ımˇz dojde k situaci, ˇze data v dan´ y okamˇzik nebudou z´ alohovan´ a. Uzly v replikaˇcn´ım clusteru mohou m´ıt jednu ze dvou z´akladn´ıch rol´ı, nejˇcastˇeji naz´ yvan´ ych master a slave. Master server nebo pouze master je server, kter´ y poskytuje data k replikaci, m´a pr´ava na ˇcten´ı i z´apis a prob´ıhaj´ı tedy na nˇem veˇsker´e aktualizace. Je moˇzno se setkat tak´e s pojmenov´an´ım primary server, 2 3
angl. High Availability volnˇe pˇreloˇzeno jako skupina server˚ u zapojen´ ych do replikace
provider, sender, parent nebo source server. Naprosto jin´ y pojem zav´ad´ı MS SQL Server, kter´ y tento zdrojov´ y server naz´ yv´a publisher (ˇcesky vydavatel). Druh´ y datab´ azov´ y server je nejˇcastˇeji naz´ yv´an slave, standby, reciever, child nebo subsciber (ˇcesky odbˇeratel). Posledn´ı pojem je tak´e pouˇz´ıv´an MS SQL Serverem. Na tento server, kter´ y je dostupn´ y vˇzdy jen pro ˇcten´ı dat, se data kop´ıruj´ı, nen´ı vˇsak moˇzn´e na nˇej zmˇeny zapisovat pˇr´ımo [7]. Podle poˇctu master a slave server˚ u v replikaˇcn´ım clusteru se rozliˇsuje, zda se jedn´ a o jednosmˇernou nebo obousmˇernou replikaci. U tzv. multimaster replikace existuje v replikaˇcn´ım clusteru nˇekolik master server˚ u, tedy tˇech na kter´e se zmˇeny zapisuj´ı pˇr´ımo. To je praktick´e napˇr´ıklad ve chv´ıli, kdy je i samotn´ ych z´ apis˚ u tolik, ˇze jeden server tuto z´atˇeˇz neunese. Z´apisy z jednotliv´ ych master server˚ u se tedy nereplikuj´ı pouze na slave servery, ale tak´e na vˇsechny ostatn´ı mastery. Tento zp˚ usob s sebou vˇsak nese znaˇcn´e komplikace, je potˇreba ˇreˇsit konflikty zmˇen v r´ amci stejn´ ych z´aznam˚ u, a je tud´ıˇz relativnˇe n´aroˇcn´ y na u ´drˇzbu. Tato pr´ ace se zab´ yv´ a pouˇzit´ım druh´e zp˚ usobu, tzv. master-slave replikace. Tato replikace pouˇz´ıv´ a vˇzdy jen jeden master server v clusteru a dva a v´ıce slave servery. Kopie dat tedy prob´ıh´ a jednosmˇernˇe, vˇzdy z master na slave servery. Podle Bella a kol. (2010) maj´ı modern´ı aplikace ˇcasto v´ıce ˇcten´aˇr˚ u neˇz zapisovatel˚ u, proto je zbyteˇcn´e, aby se vˇsichni ˇcten´aˇri pˇripojovali na stejnou datab´azi jako zapisovatel´e a zpomalovali t´ım jejich pr´aci [6].
Srovn´ an´ı multimaster a master-slave replikace Pˇri n´ avrhu replikace je potˇreba se zamyslet tak´e nad t´ım, zda bude synchronn´ı ˇci asynchronn´ı. Synchronn´ı replikace neumoˇzn´ı potvrzen´ı transakce modifikuj´ıc´ı data, dokud vˇsechny zmˇeny nejsou pˇreneseny alespoˇ n na jeden slave server [8]. Tento pˇr´ıstup zajist´ı, ˇze ˇz´adn´a data nebudou v pr˚ ubˇehu z´apisu ztracena. V nˇekter´ ych pˇr´ıpadech tento zp˚ usob m˚ uˇze zbyteˇcnˇe zpomalit rychlost z´apisu do datab´ aze, protoˇze je nutno ˇcekat na dokonˇcen´ı z´apisu na slave server. Z´aroveˇ n m˚ uˇze zp˚ usobit nemoˇznost z´ apisu do datab´aze v pˇr´ıpadˇe, ˇze se pˇreruˇs´ı spojen´ı se slave serverem nastaven´ ym pro synchronn´ı replikaci. Tento zp˚ usob je vyuˇz´ıv´an napˇr´ıklad pˇri bankovn´ıch transakc´ıch, kde je potˇreba zajistit, aby vˇsechny operace probˇehly na obou stran´ach. V tomto pˇr´ıpadˇe je uˇzit´ı tohoto zp˚ usobu zcela nezbytn´e.
Druh´ ym zp˚ usobem je asynchronn´ı replikace, pˇri kter´e se nov´a data mohou zapisovat na master server, pˇrestoˇze jeˇstˇe nedoˇslo k replikaci st´avaj´ıc´ıch dat na slave server [5]. To je sice za bˇeˇzn´eho provozu rychlejˇs´ı, v nˇekter´ y pˇr´ıpadech vˇsak m˚ uˇze zp˚ usobit nekonzistenci dat, napˇr´ıklad kdyˇz probˇehne transakce na master serveru, kter´ y vˇsak spadne dˇr´ıv, neˇz se zmˇena zap´ıˇse na slave. V takov´em pˇr´ıpadˇe se slave zmˇen´ı na master server, ale z´aroveˇ n se nikdy nedozv´ı o transakci, o kter´e m´ a uˇzivatel informace, ˇze probˇehla v poˇr´adku.
Rozd´ıl mezi synchronn´ı a asynchronn´ı replikac´ı D´ ale je moˇzno rozliˇsovat replikaci pole toho, zda je logick´ a nebo fyzick´ a. Pˇri fyzick´e replikaci se kop´ıruj´ı na druh´ y server bloky bin´arn´ıch datov´ ych soubor˚ u bez znalosti jejich struktury (sloupce, ˇr´adky, . . . ). Pro tento zp˚ usob kop´ırov´an´ı dat je potˇreba m´ıt na obou serverech stejnou platformu a architekturu. Tento zp˚ usob je velice efektivn´ı a ˇcasto snazˇs´ı na konfiguraci. Naopak pˇri logick´e replikaci se v pˇren´aˇsen´ ych datech pˇren´aˇs´ı samotn´ y SQL pˇr´ıkaz, kter´ y se na slave serveru provede stejnˇe jako na master serveru, nebo informace o tom, na kter´ ych ˇr´adc´ıch zmˇeny probˇehly a jak´e. Tento zp˚ usob je v´ıce flexibiln´ı, umoˇzn ˇuje v´ ybˇer jen nˇekolika datab´az´ı nebo tabulek a nen´ı z´avisl´ y na architektuˇre ani operaˇcn´ım syst´emu [8].
Uk´azka kask´adov´e replikace
Posledn´ım diskutovan´ ym pojmem je kask´ adov´ a replikace, kter´a umoˇzn ˇuje pˇripojit dalˇs´ı slave k jin´emu slave serveru m´ısto k hlavn´ımu master serveru. Kask´adovou replikaci lze vyuˇz´ıt v pˇr´ıpadˇe, ˇze je tˇreba replikovat data na vˇetˇs´ı poˇcet slave server˚ u v clusteru. V pˇr´ıpadˇe, ˇze by se vˇsechny slave servery pˇripojovaly k hlavn´ımu serveru, doˇslo by u nˇej k razantn´ımu sn´ıˇzen´ı jeho v´ ykonu. Kask´adov´a replikace m˚ uˇze b´ yt praktick´ a tak´e v okamˇziku, kdy se data pˇren´aˇs´ı na velkou vzd´alenost. V pˇr´ıpadˇe, kdy je tˇreba m´ıt nˇekolik replik ve velk´e vzd´alenosti od master serveru, je zbyteˇcn´e, aby se obˇe kopie pˇren´aˇsely na tak velkou vzd´alenost, kdyˇz druh´ y slave server lze pˇripoji k prvn´ımu. Kask´adovou replikace lze vyuˇz´ıt tak´e pˇri p´adu master serveru, kdy jeden slave pov´ yˇs´ı na master a druh´ y je na nˇej jiˇz pˇripojen, aby pˇrij´ımal repliky. ˇ Kaˇzd´ y datab´ azov´ y syst´em (myˇsleno SRDB) si vol´ı terminologii a konkr´etn´ı nastaven´ı m´ırnˇe odliˇsnˇe. Tato kapitola se snaˇz´ı popsat ch´ap´an´ı replikace v co nejvˇetˇs´ı m´ıˇre obecnˇe s ohledem na pouˇzit´ı tohoto pojmu v PostgreSQL. Zcela jinou terminologii, i kdyˇz zaloˇzenou na stejn´ ych principech, zav´ad´ı MS SQL Server, kter´ y pro export datab´aze do souboru pouˇz´ıv´a pojem sn´ımkov´a replikace, pro master-slave replikaci pojem transakˇcn´ı replikace a pro multimaster replikaci sluˇcovac´ı replikace.
4
Aktu´ aln´ı stav a poˇ zadavky
Katedra geoinformatiky (UPOL) aktu´alnˇe provozuje servery virtus.upol.cz, atlas.upol.cz a geohydro.upol.cz. Posledn´ı z jmenovan´ ych byl poskytnut jako testovac´ı server pro tuto pr´aci a v budoucnu se s n´ım poˇc´ıt´a jako s master serverem pro zde popisovan´e datab´azov´e ˇreˇsen´ı. Prvn´ı dva zm´ınˇen´e servery jsou aktivnˇe pouˇz´ıv´ any, hostuj´ı napˇr´ıklad geoport´al publikovan´ y skrze ArcGIS Server, kter´ y je d˚ uleˇzit´ ym prostˇredkem pro prezentaci projekt˚ u a dat, kter´a na katedˇre vznikaj´ı. Data ke geoport´ alu i dalˇs´ım aplikac´ım bˇeˇz´ıc´ım na tˇechto serverech jsou ukl´ ad´ ana do MS SQL Serveru, pˇriˇcemˇz kaˇzd´ y ze server˚ u obsahuje jin´e datov´e sady, kter´e nejsou pravidelnˇe z´alohov´any, protoˇze jejich aktualizace nen´ı pˇr´ıliˇs ˇcast´ a. Aktu´ aln´ı ˇreˇsen´ı nepouˇz´ıv´a replikaci dat, data tedy mohou b´ yt nedostupn´a z d˚ uvodu v´ ypadku serveru. Datab´ aze aktu´ alnˇe obsahuj´ı data napˇr´ıklad z projekt˚ u BotanGIS4 , Virtu´aln´ı 5 studovna CHKO Litovelsk´e Pomorav´ı , d´ale data metadatov´eho syst´emu Micka6 , data ze senzorov´e s´ıtˇe KGI, data ke studentsk´ ym prac´ım a tak´e uk´azkov´a data urˇcen´ a pro v´ yuku. Je zaloˇzeno pˇribliˇznˇe 10 u ´ˇct˚ u, kter´e maj´ı pˇr´ıstup pro z´apis, a ˇr´ adovˇe v des´ıtk´ ach u ´ˇct˚ u s pr´avem ˇcten´ı, do datab´az´ı aktu´alnˇe nen´ı pˇr´ıliˇs ˇcasto zapisov´ ano. Velk´e mnoˇzstv´ı dat, kter´e m´a katedra k dispozici, je vˇsak st´ale uloˇzeno ve form´ atech Shapefile nebo File Geodatabase. Kaˇzd´ y kdo m´a z´ajem tato data pouˇz´ıt, mus´ı je pˇren´est pˇres r˚ uzn´a hardwarov´a zaˇr´ızen´ı nebo je zkop´ırovat po s´ıti. Studenti si musej´ı dˇelat kopie dat pˇri kaˇzd´em cviˇcen´ı, coˇz velice zdrˇzuje 4 5 6
http://botangis.upol.cz/botangis/mapa http://virtus.upol.cz/ gislib.upol.cz/metadata
ˇ v´ yuku. Casto se totiˇz jedn´ a o velk´e objemy dat, jejichˇz kopie m˚ uˇze trvat ˇr´adovˇe v jednotk´ ach aˇz des´ıtk´ ach minut. Data jsou pot´e fyzicky uloˇzena na poˇc´ıtaˇc´ıch v uˇcebn´ ach, coˇz mimo jin´e dovoluje, aby se k dat˚ um dostal kdokoliv, kdo m´a na uˇcebnu pˇr´ıstup. Nen´ı tedy pˇrehled o tom, kdo data vyuˇz´ıv´a. Studenti nav´ıc netuˇs´ı, s jak´ ymi daty pracuj´ı a nab´ yvaj´ı nespr´avn´ ych pˇredstav o tom, ˇze vˇsechna data jsou vˇzdy uloˇzen´ a ve form´atu Shapefile. Z´aroveˇ n se ˇspatnˇe zajiˇst’uje aktualizace dat, pˇri kter´e, nen´ı-li spravov´ana centralizovanˇe, m˚ uˇze doch´azet k nekonzistenci dat. Pˇri kop´ırov´ an´ım dat na r˚ uzn´a datov´a uloˇziˇstˇe je nav´ıc tˇeˇzk´e dodrˇzet licenˇcn´ı podm´ınky, se kter´ ymi jsou data poˇrizov´ana. Z´ akladn´ım poˇzadavkem byl v´ ybˇer takov´eho datab´azov´eho syst´emu, kter´ y je ˇsiroce pouˇz´ıv´ an v oblasti geoinformatiky a z´aroveˇ n je podporov´an produkty ArcGIS. Poˇzadavem bylo tak´e zhodnocen´ı finanˇcn´ı str´anky, replikace je totiˇz v mnoh´ ych komerˇcn´ıch syst´emech zaˇrazena aˇz mezi nejpokroˇcilejˇs´ı funkcionalitu a tedy je dostupn´ a aˇz s draˇzˇs´ımi licencemi. Katedra m´ a v z´ ajmu ukl´adat do datab´aze mnohem v´ıce datov´ ych sad, kter´e m´ a k dispozici a kter´e jsou moment´alnˇe dostupn´e pouze ve form´atech Shapefile ˇ nebo File Geodatabase. Jedn´a se napˇr´ıklad o datov´e sady ArcCR500 verze 2.0 ˇ ˇ a 3.0, Data200 (CUZK), CEDA CR 150, data, kter´a byla uvolnˇena jako podpora ˇ nebo data dostupn´a k produkt˚ pro Krajinotvorn´ y program MZP, um ArcGIS a Idrisi. Datab´ azov´e ˇreˇsen´ı by tedy mˇelo b´ yt navrˇzeno tak, aby uneslo mnohem vˇetˇs´ı poˇcet pˇripojen´ı a dotaz˚ u neˇz v souˇcasn´e dobˇe, protoˇze datov´eho sady, kter´e budou novˇe dostupn´e skrze datab´azi, budou pouˇz´ıv´any v ˇradˇe cviˇcen´ı. Pl´anem je v r´ amci cviˇcen´ı student˚ um umoˇzn ˇit plnohodnotnou pr´aci s daty, tedy povolit jim jak ˇcten´ı dat, tak z´ apis do datab´aze.
5
N´ avrh replikaˇ cn´ıho ˇ reˇ sen´ı
Po proveden´ı reˇserˇse a zohlednˇen´ı vˇsech podm´ınek, poˇzadavk˚ u a moˇznost´ı katedry, byl sestaven n´ avrh kompletn´ıho datab´azov´eho ˇreˇsen´ı zaloˇzen´eho na procesu replikace. Z datab´ azov´ ych server˚ u byl vybr´an server PostgreSQL hned z nˇekolika d˚ uvod˚ u. Jedn´ a se o plnohodnotn´ y datab´azov´ y syst´em dostupn´ y zdarma se vˇsemi n´ astroji, je ˇsiroce pouˇz´ıvan´ y v oblasti geoinformaˇcn´ıch technologi´ı, je multiplatfomn´ı a od verze ArcGIS 9.3 plnˇe podporov´an´ y produkty ArcGIS. N´ avrh poˇc´ıt´ a s pouˇzit´ım ArcSDE pro propojen´ı datab´aze s ArcGIS produkty. Pˇri v´ ybˇeru verz´ı je nutn´e zajistit kompatibilitu verz´ı jednotliv´ ych software, a pot´e ArcSDE nainstalovat spoleˇcnˇe s PostrgreSQL. Byl navrˇzen replikaˇcn´ı cluster s nejm´enˇe tˇremi servery z d˚ uvod˚ u, kter´e jiˇz byly diskutov´ any v kapitole 3.1. Cel´ y cluster pobˇeˇz´ı na stejn´e platformˇe a proto bude moˇzno pouˇz´ıt streaming replikaci se vˇsemi v´ yhodami zm´ınˇen´ ymi v kapitole 3.1. Byla zvolena jednosmˇern´a master-slave replikace, cluster tedy bude obsahovat jeden master a dva (popˇr. v´ıce) slave server˚ u. Aby nedoˇslo ke ztr´atˇe dat v pˇr´ıpadˇe, ˇze by master server spadl dˇr´ıv, neˇz se data zkop´ıruj´ı na slave server, pro prvn´ı slave (slave1) byla zvolena varianta synchronn´ı replikace. Je vhodn´e, aby servery bˇeˇzely v lok´ aln´ı s´ıti z d˚ uvodu rychlosti a spolehlivosti spojen´ı mezi master a slave serverem.
Druh´ y server (slave2) bude replikovat asynchronnˇe a z´aroveˇ n, aby nedoch´azelo k pˇret´ıˇzen´ı master serveru, bude replikace prob´ıhat ze slave1 na slave2, tedy kask´ adovˇe. T´ım bude ˇreˇsen´ı z´aroveˇ n pˇr´ıpraveno na v´ ypadek master serveru, protoˇze v pˇr´ıpadˇe, ˇze master vypadne, slave1 bude pov´ yˇsen na master a slave2 bude ihned moci replikovat. Ze slave2 lze d´ale tvoˇrit pravidelnou, napˇr´ıklad denn´ı nebo t´ ydenn´ı, z´ alohu pomoc´ı ulitily pg dump. Z´aloha pomoc´ı pg dump tak nebude zatˇeˇzovat master server a sama o sobˇe bude prob´ıhat rychleji, neˇz by tomu bylo na master serveru, kter´ y je jiˇz tak velmi vyt´ıˇzen dalˇs´ımi procesy.
Srovn´ an´ı multimaster a master-slave replikace Uˇzivatel´e se budou pˇripojovat skrze n´astroj pgpool, kter´ y se bude tv´aˇrit jako jedin´ y datab´ azov´ y server, ke kter´emu se klienti pˇrihl´as´ı bez ohledu na typ jejich dotazu a on s´ am pak rozhodne, ke kter´emu ze server˚ u klienta pˇrihl´as´ı. T´ım bude m´ıt z´ aroveˇ n moˇznost rozloˇzit z´atˇeˇz na dostupn´e uzly v clusteru. Pro jeˇstˇe vˇetˇs´ı efektivitu provozu datab´ aze bude pgpool uchov´avat datab´azov´a spojen´ı a pˇri nov´em dotazu vyuˇzije st´ avaj´ıc´ıho spojen´ı, m´ısto aby vytv´aˇrel spojen´ı nov´e.
Vzhledem k tomu, ˇze klienti budou k datab´azov´emu serveru pˇristupovat skrze pgpool, nen´ı potˇreba aby jednotliv´e uzly v clusteru mˇely veˇrejnou IP adresu. Plnˇe dostaˇcuje, ˇze servery pobˇeˇz´ı na lok´aln´ı s´ıti a pouze pgpool bude na serveru s veˇrejnou IP, ˇc´ımˇz se zajist´ı, ˇze data budou pˇr´ıstupn´a z internetu. N´ avrh poˇc´ıt´ a tak´e s extern´ımi pracoviˇsti, kter´a budou ˇcasto ˇc´ıst z datab´aze a budou m´ıt z´ ajem o zrychlen´ı pˇr´ıstupu k dat˚ um t´ım, ˇze se slave server pˇresune na jejich pracoviˇstˇe. Typ replikace se zvol´ı podle jejich operaˇcn´ıho syst´emu a jeho architektury. Pokud se bude jednat o shodn´ y syst´em, jak´ y bude pouˇzit ve v´ yˇse popsan´em clusteru, pak bude moˇzno pouˇz´ıt asynchronn´ı streaming replikaci, naopak pokud se bude jednat o syst´em jin´ y, bude pouˇzita Slony-I replikace.
Reference 1. OPPEL, A. J. Databases: A Beginner’s Guide. New York: McGraw-Hill, 2009, 164 s. ISBN 00-716-0846-X. 2. CONNOLLY, T. Database Systems: A Practical Approach to Design, Implementation, and Management. Vyd. 4. Harlow: Addison-Wesley, 2005, 1374 s. ISBN 03-212-1025-5. 3. MOMJIAN, B. PostgreSQL: Introduction and Concepts. Boston, MA: AddisonWesley, 2001, xxviii, 461 s. ISBN 02-017-0331-9. 4. MICROSOFT. SQL Server - Replication. Microsoft [online], 2013 [cit. 2013-08-27]. Dostupn´e z: http://technet.microsoft.com/enus/library/ms151198(v=sql.100).aspx. 5. OBE, R., HSU, L. Postgresql: Up and Running. Sebastopol, CA: O’Reilly, 2012, 164 s. ISBN 978-144-9326-333. 6. BELL, C., KINDAHL, M., THALMANN, L. MySQL High Availability. Vyd. 1. Sebastopol, CA: O’Reilly Media, Inc, 2010. ISBN 978-059-6807-306. 7. RIGGS, S., KROSING, H. PostgreSQL 9 Administration Cookbook: Solve realworld PostgreSQL problems with over 100 simple, yet incredibly effective recipes. Birmingham: Packt Publishing, 2010, 345 s. ISBN 978-1-849510-28-8. ¨ ORMENYI, ¨ ¨ 8. BOSZ Z., SCHONIG, H.-J. PostgreSQL Replication: Understand basic replication concepts and efficiently replicate PostgreSQL using high-end techniques to protect your data and run your server without interruptions. Vyd. 1. Birmingham: Packt Publishing, 2013, vii, 230 s. ISBN 978-1-84951-672-3.