Mi lesz az extra a tranzakcionális replikáció elemzésében? Hát, például az olyanok, hogy central subscriber berhelése, adat inkonzisztencia kezelése is leíródik, amiket eredetileg nem terveztem. A central subscriber kevés embert hoz lázba, mert homályos. Arról van pedig csak szó, hogy van egy szerver, ami több hasonló és/vagy kapcsolódó adatbázis publikációira iratkozott fel, és összefésüli az adatot. Például több régióba telepített ugyanolyan alkalmazások adatbázisait rántja össze. Ebben az első kihívás az inicializálás: a második subscription már békén kell, hogy hagyja a létező adatokat. És az igazi öröm az, amikor ez eltörik, és újra kell gyártani. Ami egyébként nem nehéz, ne hintsük itt a port :) Majd részletezem, ahogy haladok.

Viszont azt előre megmondom, hogy a konferenciáig az Availability Groupokról egy betűt nem fogok írni. Inkább gyertek el ;) Amúgy tényleg.

(a történeti hűség és politikai korrektség jegyében meg kell mondanom, hogy ez a szerver egy muzeális darab, még SQL 2000-et futtat)

1. Az adatbázis recovery modellje simple vagy (full és bulk-logged esetén) az adott naplórész le lett backupolva.
2. A tranzakciós log szóban forgó része nem tartalmaz aktív tranzakciót, azaz minden olyan tranzakció, ami a log írásakor aktív volt, már véget ért (ha rollback lett ,akkor a rollback is véget ért).
3. Az adatbázis nincs replikálva vagy ha igen, akkor a Log Reader Agent már elolvasta az adott részt

Ezeknek a feltételeknek egyszerre teljesülniük kell. Azaz ha leállítom a Log Reader Agentet, akkor elkezd nőni a tranlog az égig, hogy ne rontsa el a replikációt. Hasonlóan elkezd nőni a log, ha sikerült egy tranzakicónak nyitva maradnia az adatbázisban, és lassan az egész tranlog aktívvá válik miatta.
Tehát ha megnő a log, érdemes a fenti pontokat ellenőrizni, körülbelül ebben a sorrendben (recovery model/utolsó log backup; legrégebbi nyitott tranzakció; replikáció esetén LRA).
Ja, még egy utolsó: a TRUNCATE LOG parancsok margójára: ha valaki rendszeresen kiadja a truncate log parancsot, akkor gondolkozzon el azon, hogy miért van full recovery model beállítva, és gyorsan állítsa át simple-re. Köszi.

Replication supports restoring replicated databases to the same server and database from which the backup was created. If you restore a backup of a replicated database to another server or database, replication settings cannot be preserved. In this case, you must re-create all publications and subscriptions after backups are restored.

Azaz nem állíthatod vissza másik szerverre a replikáció megőrzésével az adatbázist. Ez is kiesett.
Végül legvadabb ötletem nyerte a tendert, mely a következő lépéseket foglalja magában:

1. Iratkozzunk fel BB-ről A megfelelő publikációira, és hozzuk létre a B-n is létező publikációkat, azaz készítsük elő BB-t az éles üzemre.
2. Állítsuk le a Log Reader Agentet A-n. Várjuk meg, amíg végimegy minden már kiolvasott módosítás B-re és onnan C-re.
3. Irassuk le C-t B publikációiról, és irassuk fel BB ekvivalens publikációira, méghozzá NOSYNC módon, azaz NE INICIALIZÁLJUK A SUBSCRIPTIONT. Hiszen pont ugyanazokat az adatokat hozná át, mivel B és BB számára A nem változik (mert leállítottuk a Log Reader Agentet, és nincs, aki a forrásadatbázisban történő változásokat kiolvassa).
4. Hozzuk létre a replikációhoz szükséges tárolt eljárásokat C-n. Most páran benéznek: tessék? hát azt megcsinálja az SQL… Persze, megcsinálja, amikor inicializáljuk a subscriptiont. Ha nem, akkor úgy gondolja, hogy biztos valami nagyon érdekeset tervezünk, és inkább nem szól bele. Ha mégis szeretnénk a tárolt eljárásainkat megkapni, akkor a publisher adatbázisban kell lefuttatni a frappáns sp_scriptpublicationcustomprocs nevű tárolt eljárást, mely egyetlen paraméterként a publication nevét várja, kimenete pedig sok sor, amelyeket le kell futtatni a subscriber adatbázisban, és így megkapjuk a szükséges tárolt eljárásokat.
5. Ellenőrizzük, hogy működik-e a dolog: egy előre kiválasztott és leegyeztetett rekordot módosítsunk BB-n, és nézzük meg, hogy átment-e C-re a módosítás. Muszáj neki.
6. Indítsuk el a Log Reader Agentet A-n, és ellenőrizzünk.
7. Írjuk meg mindenkinek, hogy menniyre jók voltunk megint, és kb. 30 perc késleltetéssel megoldottuk a dolgot.

Nem azért, mert én találtam ki, de szerintem gyönyörű terv, abszolút kihasználja a replikáció működési mechanizmusát, és mégis egyszerű és átlátható (sőt, kipróbáltam, és működött is). Ezt mindenki elismerte. Kivéve a madzag végén lakókat, akik sok pénzt fizettek egy cégnek, hogy SQL-t szakértsen nekik, szerintem alaptalanul. A cég közölte minden részletezés és indoklás nélkül, hogy ez veszélyes, inkább a három nap kiesést javasolják. Nem kérdeztem vissza, mert ez a cég mondta azt korábban, hogy nem tudják, hogy mi fog történni az SQL 2000 szerverrel, ha egy Management Studiót telepítenek az alatta futó Windows 2003-ra, meg hogy ezt támogatja-e egyáltalán a Microsoft. Szóval nem éreztem úgy, hogy vannak szakmai indokaik, éppen ezért mélységesen csalódott voltam, hogy elrontották a gyönyörű játékomat, amit így élesben nem is láthattam működni, csak kicsit tesztben, de az meg nem az igazi. Ha esetleg valaki megvalósítaná ezt a tervet, vagy már megvalósította, mesélje el, hogy mennyire váltotta be a hozzá fűzött reményeimet. Köszönöm.

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.