…ó …ió …ció …Replikáció!

Irodalmi bevezető

A replikáció érdekes terület az SQL szerverben. Sokkal kevesebben használják, mint ahányan félnek tőle, és ez valahogy azt sugallja az embernek, hogy ő se akarja használni. Pedig a replikáció szép és jó, csak tudni kell, hogy hol a helye.

Először is próbáljuk meg tisztázni, mi is a replikáció, mire is való, és mire nem. A replikáció tulajdonképpen arról szól, hogy egy adatbázis tetszőlegesen kiválasztott részét többszörözzük. Boncolgatom egy kicsit az általam most kitalált meghatározást az érhetőség kedvéért:

egy adatbázis tetszőlegesen kiválasztott része: Alapvetően általában az adatokat (azaz a táblákat) szeretnénk többszörözni, de bármilyen objektumot replikálhatunk: view-t, sp-t, udf-et. Táblák esetében a tábla tartalma mind horizontálisan, mind vertikálisan filterezhető (ez a tudományos szöveg azt hivatott elmondani, hogy mind sorokat, mind oszlopokat kihagyhatunk a táblatartalmakból ).

többszörözzük: A replikáció segítségével tetszőlegesen sok helyre szétteríthetjük a kívánt adatot, akár ugyanarra a szerverre, csak egy másik adatbázisba, akár a világ másik végére (akár egy másik adatbáziskezelőbe is, némi korlátokkal), szintén egy másik adatbázisba.

Ebből már láthatjuk kicsit, mi is az a replikáció és mire való. Gyakorlati alkalmazása lehet neki például: referenciatáblák adatainak a terjesztése; riportolás; földrajzilag távoli adatok “közelebb hozása”; egymással nem mindig kapcsolatban álló adatbázisok szinkronban tartása. Mire nem való? Hát, szöget beverni vele – arra teljesen alkalmatlan. Szokták nagy rendelkezésreállási megoldásként is reklámozni, erről én azt gondolom, hogy lehet, persze, de azért a log shipping és mirroring létezése erősen rontja ezt a képet. Leginkább annál a résznél, amikor a rugalmassághoz meg a strapabíráshoz érünk. Természetesen el tudok képzelni olyan felállást, amikor ez egy nem rossz ötlet, csak most nem jut eszembe rá példa. A teljesség igénye nélkül két nem túl valószerűtlen történet arra, hogy én miért nem tartom jónak “tartalékadatbázis” készítésére: 1) Sémát változtatok az adatbázisban. SQL2000-nél (igen, még létezik) elég jó esélyem van arra, hogy a replikáció miatt nem tehetem meg csak úgy, illetve ha megteszem, nem megy át a replikációval a változtatás (2005-nél erre lényegesen kisebb az esély). 2) A “replikálódott” céladatbázis egy teljesen közönséges adatbázis, írható-olvasható, és (a mirroringhoz és log shippinghez képest) viszonylag nagy az esélye annak, hogy valaki valamit módosít az adatbázisban, és így elcsúszik a szinkron. 3) A replikáció erőforrásigénye nagyobb, mint a logshippingé vagy a mirroringé (melyek céleszközök nagyrendelkezésreállásos felállásban).

A replikáció alapjai

A bevezető után térjünk a szakmai részre. A replikációban három szerep van, és háromféle replikáció van. Mindhárom replikációban ugyanaz a három szerep. A szerepek előtt azért még a könnyebb feldolgozás kedvéért elmondom, hogy a terminológiában a lapterjesztéssel vontak párhuzamot a fejlesztők, mely párhuzam néha kicsit biceg, de azért nem dől el.

Szóval a három fő szerep a Publisher (kiadó), a Distributor (terjesztő) és a Subscriber (előfizető). Ezek inkább adatbázisokhoz kötődnek, mint szerverekhez, akár mindhárom szerep lehet ugyanazon a szerveren. A Publisher adatbázis az, amelyiknek a tartalmát szeretnénk terjeszteni, egy terjesztési egység a publication (publikáció), ami tartalmaz egy vagy több article-t (cikket). Egy article egy objektumnak felel meg, azaz lehet egy tábla, tárolt eljárás, UDF, stb.) Egy adatbázisban több publikációt is létrehozhatunk, és ugyanazt az objektumot több publikációba is betehetjük. A Distributor felelős azért, hogy a szükséges változások eljussanak a Subscriberekhez, akik pedig nem kell, hogy felelősek legyenek semmiért.

A replikációnak három típusa van, bonyolódó sorrendben: a snapshot, a transactional és a merge. A snapshot elég egyszerű, mint a neve is mutatja, egy pillanatfelvételt lehet vele terjeszteni. A Publisher adott időpontban fennálló állapotát osztja meg, a későbbi esetleges változások nem mennek át. A működési elv is egyszerű: a Publisherről készül egy séma-generáló script-csomag, plusz az érintett táblák (igény szerint filterezett) tartalma bcp-vel fájlokba ugrik. Ez a csomag a snapshot, ami hasonló logikával kerül a Subscriberre: a scriptek legenerálják a szükséges sémát, az adatokat pedig a bcp jól betölti. Tipikusan arra való, hogy ritkán változó, nem túl nagy méretű adatokat szinkronizáljunk, például referenciatáblákat (termékkatalógus, cikktörzs, irányítószámadatbázis, stb). Az adatfolyam itt mindig egyirányú: Publishertől a Subscribernek. A transactional replikáció egy picit komplexebb, itt már a változások (pontosabban a tranzakciók) is folyamatosan mennek a subsciberek felé, akik így naprakészek (vagyis percrekészek) egyfolytában. Ez használható olyan helyeken, ahol egy adatbázis egy részének olvasható elérésére van szükség, például riportozó/monitorozó alkalmazás. Az adafolyam itt általában egyirányú, de van lehetőség update-elhető publikációkat létrehozni, amikkel a Subscriber vissza tud írni az adatbázisba. Ezt akkor lehet használni, ha nagy ritkán valamiért a Subscribernek is írni kell, de általában (>99,5%) nem. Ezt ugyanis nem erre tervezték elsősorban. A merge replikációnak ellenben az a fő funkciója, hogy gyakorlatilag a különböző felek által végzett módosításokat szinkronban tartsa. Itt persze felléphetnek különböző érdekes helyzetek, de erről majd később. Persze vannak kötöttségek is: A transactional esetén csak olyan táblák replikálhatóak, amelyeken van primary key definiálva, hiszen ez lesz a későbbi update-ek esetén hivatott a rekordokat beazonosítani. A merge replikációnak pedig egy egész új oszlop kell: egy GUID, ami a rekordokat azonosítja, mivel itt már a primary key sem elég – mi történik, ha az egyik helyen pont a primary key módosul, a másikon pedig egy másik mező?

Egy fontos dolog a replikáció működéséről: tele van ágensekkel minden: a snapshotot a Snapshot Agent generálja, a tranzakciókat a tranzakciós naplóból a Log Reader Agent bányássza ki, a subscribereknek a szükséges adatokat a Distribution Agentek terjesztik, a merge replikációt pedig a Merge Agentek végzik. Ha pedig valaki a transactional replikációt update-elni akarja, hogy inzultáljam a magyar nyelvet, akkor még egy Queue Reader Agentre is számítson…

A replikáció kapcsán még egy dolog szokott előkerülni: a distribution adatbázis. Ez egy rendszer adatbázis, amiben a szerver által kezelt publikációk adatai találhatóak: a publikációk típusa, tartalma, a subscriberek, illetve maguk a terjesztendő adatok is ide kerülnek a transactional replikáció esetén.

Röviden ez a replikáció vázlatos és felületes áttekintése.

Leave a comment