Slony-1

Posledica širjenja trga, na katerem nastopa neki ponudnik, je vedno tudi stopnjevanje zahtev uporabnikov ponujenih izdelkov oz. storitev. Na trgu zbirk podatkov to pomeni vse večje zahteve po varnosti podatkov, enostavnem upravljanju in vzdrževanju, možnostih širjenja v skladu s potrebami naloge, ki jo zbirka opravlja, ipd. Tudi PostgreSQL se kot najnaprednejša odprtokodna zbirka podatkov sooča z vse večjim povpraševanjem po omenjenih odlikah in glede na ciljno skupino uporabnikov PostgreSQLa sta popolnoma legitimno na prvih mestih vprašanji replikacije in porazdelitve bremena.

PostgreSQL, replikacija, porazdelitev bremena

Za t. i. replikacijo in porazdelitev bremena med strežniki sta uporabnikom na voljo dva "resnejša" izdelka.

pgpool je namenjen predvsem porazdelitvi obremenitev strežnikov. Za uporabo je dokaj zapleten, saj se problema loteva na pomensko precej oddaljeni ravni delovanja. To mu onemogoča inteligentne odločitve. Predstavlja zgolj enotno vstopno točko za odjemalce, omogoča pa porazdelitev bremena med dvema strežnikoma. Vse poizvedbe, ki spreminjajo vsebino zbirke, pošlje najprej glavnemu strežniku, šele ko ta potrdi uspešno izvedbo, pa tudi podrejenemu. Ta čas je podrejeni strežnik na voljo za bralne poizvedbe in nasprotno, seveda pa pgpool le-te sam preusmerja.

Težave nastanejo pri bralnih stavkih, ki hkrati tudi spreminjajo vsebino zbirke, npr. ob branju zaporedja (sequence), ki ima za posledico povečanje njegove vrednosti. pgpool namreč več zaporednih stavkov SELECT pošilja izmenično enemu in drugemu strežniku, ne pa vseh obema, zato je v takih primerih nemogoče zagotoviti enovitost podatkov. Namen pgpoola pa ni ustrezati takim okoljem - namenjen je porazdelitvi obremenitev v zbirkah, ki so izpostavljene večinoma bralnim poizvedbam, in kratkim premostitvam izpadov enega od strežnikov. Replikacija podatkov ga načeloma ne zanima.

Drugi izdelek se imenuje Slony. To v slovenščini pomeni natanko to - veliko slonov. Logotip projekta PostgreSQL je namreč slon, Slony pa omogoča zgraditi slonjo farmo. Problem porazdelitve bremena prepušča upraviteljem zbirke; namenjen je predvsem vzdrževanju identičnih kopij podatkov v več strežnikih. Popolnoma ne ustreza nobenemu od dveh najbolj znanih pristopov k replikaciji podatkov: ni niti popolnoma vrste master/slave niti multi-master. Zasnovan je namreč tako, da je prenos pravice do pisanja v poljubnem trenutku mogoč na kateregakoli od slonov, to pravico pa si lahko hkrati lasti le en sam.

Zgolj kot zanimivost - tako Slony kot pgpool sta pred časom doživela popravke, ki omogočajo njuno sodelovanje in s tem še razširitev nabora možnosti, ki jih ima upravitelj zbirke za dosego zanesljivega in zmogljivostno sprejemljivega okolja. Težava s premikom izvora podatkov je namreč ta, da se mora programska oprema, ki komunicira z zbirko podatkov, tega zavedati, sicer se utegne znajti v zagati. pgpool kot enotna vhodna točka za skupino sečišč lahko po novem to težavo premosti, saj ga je moč nastaviti tako, da vedno ve, kateri od strežnikov je v danem trenutku "glavni", in pošilja stavke, ki podatke spreminjajo, v pravo smer.

Glede na to, da je replikacija podatkov težji problem, saj se je s težavo porazdelitve bremena mogoče soočiti na kar nekaj različnih načinov, od aplikacije do sistema, pa se omejimo zgolj na Slony-1.

Pristop

Za opis delovanja Slony-1 je v uporabi nekaj izrazov, ustreznejših od običajnih terminov v rabi za zbirke podatkov. Gruča strežnikov, med katerimi prenašamo podatke, se imenuje replikacijski grozd (cluster). Posamezen strežnik je v tem primeru priročneje predstaviti kot sečišče (node), ki ima opravka z nabori podatkov (set). Nabor podatkov je lahko tabela, celotna zbirka ali pa poljubna mešanica le-teh. Nabor podatkov ima izvor (origin) in ponor, v tem primeru enega ali več naročnikov (subscribers). Edino mesto, kjer je aplikacijam dovoljeno spreminjati podatke, je izvor.

Gledano za posamezen vir podatkov, je število naročnikov navadno za ena manjše od števila sečišč, posamezno sečišče pa je v poljubnem trenutku lahko za posamezen vir podatkov bodisi izvor bodisi eden od naročnikov. Grozd je na več načinov mogoče tudi preoblikovati in izvor prenesti drugam. Seveda so mogoče tudi izjeme, npr. primer, v katerem je naročnik nekega nabora podatkov hkrati tudi izvor istega nabora podatkov za druge naročnike (t. i. razslojena ureditev), in poljubne kombinacije večsmerne replikacije, v katerih sta npr. dva ločena nabora podatkov tabeli iz iste zbirke, eno sečišče pa je hkrati izvor za enega in naročnik za drugega.

To, da je mogoče izvor podatkov večinoma brez težav premeščati z enega sečišča na drugo, omogoča izdelavo najrazličnejših shem replikacije podatkov, tudi takih, ki npr. v določenem obdobju dneva zaradi potreb trgovine zahtevajo pravico do pisanja po zbirki v enem strežniku, popoldne v namene inventure v skladiščih v drugem, ponoči pa je zaradi statističnih obdelav podatkov treba to pravico omogočiti tretjemu strežniku, ki je, topološko gledano, na manj primerni lokaciji, zato (npr. zaradi prepočasnih povezav) pošiljanje ukazov "trgovinskemu" ali "skladiščnemu" strežniku ni optimalno.

Še več - če je aplikacijo mogoče prirediti tako, da vsako od sečišč podatke zapisuje v svojo tabelo, je konfiguracija, ki ni prav daleč od tiste v načinu multi-master, precej preprosta, saj je, kot že rečeno, eno sečišče lahko hkrati izvor in naročnik za različne tabele v eni sami zbirki podatkov, dedovanje tabel pa omogoča, da aplikacije podatke zapisujejo vsaka v svojo (fizično enako) tabelo, berejo pa jih iz skupne, starševske tabele, ki omogoča pregled nad vsemi sorodnimi podatki hkrati.

Zahteve

Kot vsak izdelek je tudi Slony-1 namenjen določeni ciljni publiki, posameznim slojem le-te pa ustreza bolj kot drugim. Gledano na splošno, je namenjen predvsem okoljem, ki jim koristi usklajevanje velikih zbirk podatkov med zmernim številom strežnikov, to pa v teh razmerah najverjetneje pomeni največ nekaj deset, saj način komunikacije v grozdu zaradi možnosti prenosa izvora zahteva natančen opis komunikacijske poti (path) med vsakim posameznim sečiščem in vsemi drugimi. Rast gruče je v kvadratnem razmerju s povečanjem količine komunikacije: usklajevanje namreč poteka ob pomoči t. i. uskladitvenih dogodkov (SYNC events), ki jih prožijo vsa sečišča v gruči med seboj, in morajo prepotovati vsaj polovico sečišč, da je gručo mogoče obravnavati kot stabilno.

Gledano vsebinsko, je Slony-1 moč uporabljati na dva načina. V prvem, načinu asinhronega usklajevanja, je namenjen predvsem podatkovnim centrom in varnostnim lokacijam, kjer so navadno vsa sečišča povečini na voljo in delujejo razmeroma zanesljivo. Drugi način, nov v različici 1.1.0, pa izkorišča prav tako novo PostgreSQLovo možnost izdelave varnostnih kopij PITR (point-in-time recovery) in omogoča vzdrževanje t. i. "offline" kopij strežnikov, ki so v normalnem načinu delovanja nedostopne za uporabnika, tako da je primernejši za okolja, v katerih izpad delovanja ni tako kritičen kot izguba podatkov in v katerih so zahteve po hitrih premostitvah manjše; ta način je tako glede zahtevnosti upravljanja kot tudi količine komunikacije precej nezahteven, a zanesljiv.

Občasno usklajevanje (npr. vsakih nekaj ur) je teoretično sicer mogoče vzpostaviti, a ker Slony-1 takim nalogam ni prvenstveno namenjen, verjetno vsaj z vidika upravljanja ne bo optimalno.

Slony-1 v trenutni različici za delovanje še zahteva operacijski sistem, soroden UNIXu, razvojna različica pa že kar nekaj časa poskusno deluje tudi v okolju Windows. To ne pomeni, da je zbirke, ki delujejo v tem operacijskem sistemu, nemogoče usklajevati; Slony-1zna namreč z zbirko komunicirati tudi prek omrežja, tako da program za nadzor lahko teče v enem strežniku, njegova "lastna" zbirko pa kjerkoli drugje.

Kar zadeva druge zahteve po sistemskih sredstvih, je Slony-1 precej nezahtevna čreda: vse, česar si sloni želijo, je nekaj MB prostora na disku vsakega sečišča (približno 6 MB z vključenimi navodili, 1 MB brez). Za delovanje potrebuje poleg para slonov seveda tudi najmanj en par namestitev PostgreSQL (najstarejša podprta različica je 7.3.3, priporočena pa 7.4.8 ali novejša, nikakor ni treba, da sečišča uporabljajo enake) z jezikom pl/pgsql v vseh zbirkah, ki naj bi jih sloni usklajevali, ter uporabniškim računom s pisnim dostopom do sistemskih tabel.

Za uspešno delovanje kakršnihkoli omrežnih gruč je usklajevanje sistemske ure članov gruče skoraj nujno; to velja tudi za Slony-1. Priporočljivo (ne pa nujno) je, da strežnik, v katerem je izvor (ali največ izvorov) podatkov, naročniki uporabljajo kot avtoritativni strežnik za usklajevanje ure. Prav tako je dobrodošlo nastaviti časovni pas sistemskega uporabniškega računa, v katerem delujeta PostgreSQL in Slony-1, na UTC, saj je ta edini, pri katerem ni razlike med zimskim in poletnim časom.

Zgradba in delovanje

Osnovno ogrodje Slony-1 predstavljata dve orodji: slon in slonik (slonček).

Prvi skrbi za usklajevalno dejavnost posameznega sečišča; deloval naj bi neprestano, zato sta v paketu dodatnega programja tudi dve skripti, ki bdita nad slonom in skrbita, da nikamor ne pobegne. Osnovni količini, s katerima ima opravka slon, so dogodki dveh vrst: nastavitveni in uskladitveni.

Nastavitvene dogodke proži slonik, ko obdela skripto, napisano v posebnem "malem jeziku", s katerim je moč dodajati in odstranjevati sečišča, naročnike in nabore podatkov, spreminjati komunikacijske poti in premikati izvore posameznih naborov. Z vidika upravljanja zbirke je slonik koristen tudi pri edini stvari, ki se zavoljo uporabe Slony-1 spremeni precej korenito; spremembe opisov tabel, gradnja kazal in podobna upraviteljska opravila namreč niso dovoljena neposredno na sečiščih. V ta namen slonik uporablja ukaz EXECUTE SCRIPT, ki opravilo kot nastavitveni dogodek pošlje vsem sečiščem v grozdu posameznega nabora podatkov.

Druge vrste dogodki so uskladitveni in jih prožijo sami sloni. Spremembe tabel v grozdu so namreč združene v skupine transakcij, ki se imenujejo dogodki SYNC. Po uspešno dodanem naboru podatkov in naročnikih je prvi uskladitveni dogodek prenos celotnega obstoječega nabora z izvora na naročnike (COPY_SET), temu pa sledijo vse druge spremembe, brž ko število uspešno opravljenih transakcij doseže nastavljeno vrednost, ki slonu na izvoru podatkov pove, kolikšna je želena povprečna velikost uskladitvenega paketa. Vsebino posameznega uskladitvenega dogodka izvor pošlje vsem znanim naročnikom (slonom), ti pa ga potem prenesejo svoji "domači" zbirki.

Posamezni nabori podatkov so sestavljeni iz tabel, ki jih upravitelj doda v nabor z uporabo slonikove skripte, zaporedij, ki jih te tabele uporabljajo, ter ključev za tabele, ki nimajo ustreznega glavnega ključa; te ključe slon po potrebi ustvari namesto upravitelja. Vsak zapis v posamezni tabeli namreč potrebuje edinstveno oznako, saj brez nje praktično ni mogoče preverjati integritete kopij izvora podatkov.

Prenos izvora

Mogoča sta dva načina prenosa izvora podatkov na drugo sečišče. Prvi, malce preprostejši, a precej manj zanesljiv, pride prav predvsem v primeru katastrofe: če na sečišču, kjer je izvor podatkov, nastanejo težave, ki onemogočajo njegovo vlogo v nadaljnje, je edina rešitev zasilni preklop ali failover. Le-ta se nepretrganemu delovanju v prid odpove vsem uskladitvenim dogodkom, ki z izvora še niso bili preneseni na naročnike, kot novi izvor določi izbrano sečišče, preveri, kateri neposredni naročnik izpadlega izvora ima najboljšo kopijo zbirke, ter počaka, da se vsi naročniki uskladijo do te točke. Nato na vseh popravi komunikacijske poti in ponastavi gručo tako, da vse nabore podatkov, ki izvirajo na sečišču v težavah, prenese na novi izvor.

Ker je zasilni prenos do enovitosti podatkov izredno nasilen, saj je kar nekaj starih odjemalcev od zbirke zelo verjetno že dobilo potrditev o uspešno končanih transakcijah, naročnikom pa se, če so le-te bile izvedene le malo pred zasilnim prenosom, verjetno še ni uspelo popolnoma uskladiti z izvorom, je ta možnost nezaželena in priporočljiva le takrat, ko ni druge možnosti, oziroma je potreba po nepretrganem delovanju večja od škode, ki bi jo utegnilo povzročiti nekaj izgubljenih transakcij. Z enakega vzroka je stari izvor podatkov nemogoče znova vključiti v replikacijo, saj tako to, da je na njem nekaj transakcij, o katerih preostala sečišča ne vedo nič, kot tudi čas, potreben za vnovično vzpostavitev njegovega delovanja (med tem časom novi izvor aktivno sprejema in izvaja transakcije), pomenita, da je podatke na tem sečišču bolje obravnavati kot popolnoma nekonsistentne in neuporabne za nadaljnje delo.

Če je le mogoče, se pri prenosu izvora podatkov priporoča nadzorovan preklop ali switchover, pri katerem se zgodi precej manj nasilnosti, še posebej gladko pa poteka, če je kandidat za novi izvor razmeroma dobro usklajen s starim. Praktično edini stranski učinek je ta, da uporabniki zbirke nekaj sekund ne morejo uporabljati, nato pa se je (zaenkrat še) treba znova prijaviti. V tem času se obe sečišči popolnoma uskladita med seboj, staro pa postane naročnik. Vsi preostali naročniki izvedo, kdo je novi šef, komunikacijske poti so prav tako osvežene, celoten proces pa redkokdaj traja dlje kot deset sekund. Popolnoma enako je npr. mogoče nadgraditi PostgreSQL na enem samem strežniku praktično brez prekinitev.

Organizacija naborov

Pravila za organizacijo tabel v nabore podatkov so precej preprosta: vse tabele, ki so med seboj povezane z uporabo tujih ključev ali so v kakršnemkoli drugačnem vsebinskem sorodstvu (npr. z omejitvami ali prožilci na eni tabeli, ki preverjajo vsebino druge in tako odločajo o uspehu posamezne spremembe) naj bi bile načeloma združene v isti nabor podatkov. Razlog za to je, da bodo dogodki znotraj enega nabora zagotovo preneseni v naročniške zbirke v popolnoma enakem vrstnem redu, kot so se zgodili na izvoru, tega pa ni mogoče trditi za podatke, ki se prenašajo v več naborih - ti utegnejo biti včasih med seboj iz različnih vzrokov neusklajeni (npr. velikost paketa transakcij) in tako povzročiti težave pri preverjanju referenčne enovitosti (integritete).

Utemeljeni razlogi, da kaka tabela vsaj na začetku uskladitve ni vključena v nabor, pa čeprav je vsebinsko povezana s preostankom podatkov v naboru, obstajajo. Prvi bi utegnil biti velikost tabele: če je velikanska (npr. nekaj desetin GB), bo začetni prenos tabele z izvora brez posebnih nastavitev zelo verjetno povzročil prekoračitev časovne omejitve za posamezno uskladitev. Tudi preveliko število tabel v naboru podatkov utegne motiti, saj izvajanje skript v sloniku zahteva zaklepanje vseh tabel v naboru in če jih je preveč, se precej poveča tudi možnost, da operacija ne uspe zaradi navzkrižne odvisnosti med tabelami (t. i. deadlock). Seveda pa je poleg prenosa izvora podatkov posameznega nabora na drugo sečišče mogoče prenašati tudi sestavne dele naborov iz enega v drugega, tako da omenjena priporočila sama po sebi ne bi smela biti večja težava za uspešno replikacijo.

Živalski vrt?

Slony-1 ima, čeprav je v trenutnem stanju že zelo zrel izdelek, pred seboj še dolgo pot. Namen skupine razvijalcev projekta je namreč ponuditi pravo replikacijo vrste multi-master v različici 2.0, njihov uspeh, predvsem pa oddaljenost dneva, ko bo Slony-2 nared, pa je odvisen od marsičesa, med drugim tudi od odločitve, naj Slony deluje neodvisno od različice zbirke podatkov na posameznem sečišču, neposredno pa naj ne posega v njeno programsko kodo. To se bo verjetno vsaj za nekaj časa spremenilo v prvih izdajah različice 2.0, dolgoročni načrti pa ostajajo enaki.

Čeprav je delo z aplikacijo, predvsem pa cela vrsta novih konceptov, ki jih Slony-1 vpeljuje, včasih rahlo zapleteno, in utegne preteči kar nekaj vode, preden bo lahko upravitelj popolnoma samozavestno uporabljal Slony v vseh okoljih, kjer je koristen, je nedvomno dovolj preprost za temeljne načine vzdrževanja zanesljivosti, nezahteven je do sistemov, v katerih deluje, in, kar je najpomembneje, dovolj je razširjen, da je zanj mogoče dobiti dobro in hitro podporo in da misel na njegovo prihodnost vzbuja dober občutek.