Mint említettem, mostanság éppen próbálok egy aktív/aktív SQL clustert építeni, de mivel sokaknak ismeretlen a téma cégen belül is, kicsit úgy érzem magam, mint Gallilei: hol szép, hol kevésbé szép szóval próbálnak jobb belátásra bírni. Úgyhogy gondoltam, hogy ahelyett, hogy engedek, inkább leírom, hogy hogyan is működik a Microsoft eme remek találmánya.

Kezdjük az elején, a cluster fogalmánál. A Microsoft cluster egy failover cluster, azaz hibatűrésre van kitalálva. Nem várhatunk tőle nagyobb teljesítményt, párhuzamosítást, satöbbit. Egy adott feladatot (tipikusan valamilyen hálózati szolgáltatás nyújtása) egy adott pillanatban csak egy gép végez. Az SQL Server külön fel van okosítva arra, hogy ő hogyan is fusson egy clusteren, úgyhogy már egy “sima” aktív-passzív cluster is okozhat zavart arra fel nem készített fejekben. Ahhoz, hogy SQL clustert építsünk, először is kell telepítenünk két Windows 2003 Enterprise Editiont (a 2008-as clusteringhez még hülye vagyok egyelőre, elég sokat változott) két azonos hardverre (izé, működik különböző vasakkal is, csak problémáink lesznek a supporttal, meg esetleg a clusterrel is). Kell továbbá plusz egy IP cím és egy hozzá tartozó hálózati név, valamint egy megosztott diszk (a quorum, mely általában a Q: betűt szokja kapni), melyet mindkét gép (avagy node) lát lokális diszkként (SAN, DAS, vagy csak egyszerűen iSCSI). Nem kötelező, de ajánlott még egy heartbeat hálózati kapcsolat a gépek között, ez két node-os clustereknél gyakran egy keresztkábellel megoldható (ha a távolság elég kicsi a fizikai gépek között). Ha ezek mind megvannak, akkor az első node-on (CLNODE1) elindítjuk a cluadmin.exe nevű kütyüt, és építünk egy új clustert, megadva a cluster nevét (MYCLUSTER), IP-jét (172.18.1.104). Majd a második node-on is elindítjuk ezt, és hozzáadjuk őt az új clusterhez. Ezzel elértük az alsó, szürke keretben látható állapotot: van egy Microsoft failover clusterünk, mely ebben a pillanatban még semmilyen gyakorlati hasznot nem hajt. (Több, mint két node-os clustert is lehet építeni, a második node-on végrehajtott lépések ismételgetésével.) Amikor módosítunk a resource-okon vagy a node-okon, érdemes mindig kipróbálni, hogy mindegyik node át tudja-e venni azt, amit át kell tudnia venni, azaz működik-e a failover funkció.

Építsünk rá egy SQL clustert is. Ehhez hasonló dolgok kellenek, mint az előbb: diszk, IP cím + hálózati név. Plusz SQL telepítő. SQL 2005-től apró, de a pénztárnál jelentősnek tűnő öröm, hogy nemcsak az Enterprise Edition clusterezhető, hanem a Standard Edition is, igaz utóbbi csak két node-ra, de úgyis ez a leggyakoribb. A telepítés megkezdése előtt hozzunk létre egy új resource groupot a cluadminban, és tegyük bele az SQL-nek szánt diszkeket. Teszteljük le, hogy mindkét node tudja-e birtokolni a diszkeket (erről Andor tudna mesélni). Fontos tudni, hogy az SQL Server csak ezekre a diszkekre enged majd adatbázis fájlokat tenni. A telepítő elvárja azt is, hogy fel tudjunk mutatni egy domain csoportot, amit felruházhat minden node-on az SQL Server futtatásához szükséges jogokkal. Ezt érdemes előre megcsinál(tat)ni és beletenni az SQL service-eket futtató technikai accountot.

És már kezdhetjük is a telepítést. A telepítés során láthatjuk, hogy a virtual server nevére kíváncsi a telepítő – ez az a hálózati név, amit előre beregisztráltunk a DNS-be az SQL Server részére (SQLCLUSTER1). Emellett pedig még az instance nevére is kíváncsi lesz: default vagy named, és ha named instance, akkor mi a neve. Az első SQL clusterünk minden további nélkül lehet default, vagy amit akarunk. Egyébként a szokásos kérdések jönnek, majd feltelepíti az installer az SQL Server failover clusterünket, és megkapjuk a középső téglaszínű téglalapot, melyben a nyilak jelzik a függőséget: az SQL Servernek kell az összes diszk plusz a network name (ami pedig az IP címtől függ értelemszerűen) ahhoz, hogy el tudjon indulni, az SQL Agentnek meg az SQL Server, de ebben nincs semmi meglepő. És íme, az SQLCLUSTER1 nevű SQL szerverhez már lehet is csatlakozni.

Van viszont néhány dolog, amire jó gondolni:

• Az Integration Services és az SQL Browser nincsenek clusterezve, ők ugyanolyan mezei service-ek, mint máskor.
• Az adatfájlok egy példányban találhatóak a shared diszkeken, melyekhez egyszerre csak egy node férhet hozzá. (És ezzel meg is találtunk a single point of failure-t a failover clusterben – megfelelő diszk alrendszerrel jelentősen csökkenthető a kockázat.)
• Az alkalmazás binárisai két példányban találhatóak meg, mindkét node-nak a saját, lokális diszkjén, tehát mindkét gépen van külön C:\Program Files\Microsoft SQL Server\… könyvtár.
• Az SQL Server a cluster IP megadott portján figyel, tehát a node-okon kiadott kapcsolódások a . vagy (local) szerverekhez csúnya véget érnek (hacsak nem installáltunk fel lokálisan is egy nem-clusterezett SQL Servert, ami nem lehetetlen, csak perverz). A mellékelt ábrán pl. akármelyik gépen fut éppen a SQLCLUSTER1, csak a 172.18.1.115 IP 1433-as TCP portján figyel a szerver, a 172.18.1.101 és 102 1433 portja be van csukva, senki nincs ott.
• Az SQL Server igazából magasról fütyül a cluster groupra, tehát nem érdekli, hogy hol van (ha egyáltalán fut) a cluster név és IP.
• Ha szeretnénk elosztott tranzakciókat, akkor az MSDTC-t is clusterezni kell.

Mostanra tehát van egy failover clusterünk. Mitől lesz aktív/aktív a cluster, ha egyszer ez egy failover cluster, ahol egyszerre csak az egyik node lehet aktív? Az elnevezés pongyolasága sokakat megtéveszt, hivatalosan ezt multiple-instance cluster néven találtam meg az MSDN-en. Szóval annyi történik, hogy installálunk még egy SQL Server instance-ot, külön resource-okkal, és innentől kezdve az egyik node-on fut az egyik instance, a másikon a másik, tehát mindkét node aktív, vagyis a clusterem aktív/aktív. A második instance telepítéséhez megint mindent be kell szereznünk: diszket, DNS-be regisztrált hálózati nevet és IP címet, egyedül a domaincsoportot tudjuk újrahasznosítani. Telepítéskor a virtual server neve az új hálózati név lesz (SQLCLUSTER2), és itt már muszáj lesz instance nevet megadnunk. De miért is? Mert különben nem tud egy node-on futni a két SQL Server, két default instance nem fér meg egy csárdában, ezen a clusterezés sem segít. Mindkét node-on ott vannak a service-ek felinstallálva, és a default instance MSSQLSERVER nevű service-e már foglalt. Nevezzük el TEST-nek ezt az instance-ot. Így létrejönnek mindkét node-on a MSSQL$TEST és SQLAgent$TEST servicek a named instance-hoz. És íme, megcsináltuk a felső téglaszínű téglalapot is a képről, készen van a török basa aktív/aktív SQL cluster. Az új darab SQLCLUSTER2\TEST névre hallgat.

A dologban van néhány finomság: az instance-ok egymástól teljesen függetlenek, leszámítva azt az apróságot, hogy ha véletlenül egy node-on futnak, akkor kegyetlenül fogják ölni egymást erőforrásokért. Ebből következik, hogy a dizájnban kell hagyni tartalékot, azaz a két instance-nak elfogadható szinten kell futnia egy fizikai gépen (bármelyiken a clusterből). Kedvencem, hogy az összes instance figyelhet a 1433-as porton, hiszen mindegyik a saját IP-jének a 1433-as portján figyel. Ezt a beállítást azért konzervatívabb helyeken istenkísértésnek hívják, én is örülök neki, és eszem ágában sincs használni. Mivel az instance-ok függetlenek, ezért függetlenül lehet patchelni is őket. SQL 2000/2005-nél az aktív node-on kell elindítani a patch installert, ami sajnos ugyanúgy szolgáltatáskiesést fog okozni, mint a nem-clusterezett esetben, amíg fut.

A koncepció fő előnye az, hogy megszűnik az 50%-os hardverpazarlás, ami az aktív/passzív cluster velejárója, gyakorlatilag a plusz memória a node-okba a többletköltség. Hátránya pedig az (az egy lábra billenéskor bekövetkező teljesítményesés mellett), hogy ha meghal mindkét node, akkor egy ideig műsorszünet van két failover clusternél. Ez persze így van a/p clusternél is, de ha két a/p cluster van, amik egymásra teszik a mirrorozott/logshippelt adatbázisaikat, akkor a rendszer három gép halálát éli túl, cserébe két gép soha nem csinál semmit. Ebben a kérdésben mindenki döntsön maga tapasztalatai alapján. Aki már több gépét látta elfüstölni, az persze kicsit visszafogottabb, és meg is értem őt. Én szerencsére már hat éve használom ugyanazon, általam nagyon szeretett hardvergyártó szervereit (de nem csinálok ingyenreklámot egy cégnek, amelyik rettenetes felügyeleti rendszert és egyéb szoftvereket gyárt :P), és annak az esélyét, hogy 24 órán belül meghal mindkét node, nagyon alacsonynak látom, úgyhogy én simán belevágok.

/* elofeltetel1:
create table tabla1 (a int identity(1,1), b int, c int)
create table tabla2 (a int, b int, c int)
*/
/* elofeltetel2:
create procedure spTablaolvaso
as select a,b,c from tabla1
*/

select a, b, c from tabla1
select a, b, c from tabla2
spTablaolvaso

Ez a script látványosan el fog bukni, mondván, hogy a spTablaolvaso egy ismeretlen dolog számára. Írjuk át a scriptet:

select a, b, c from tabla1
GO
select a, b, c from tabla2
GO
spTablaolvaso

Ez már le fog futni (feltéve, hogy léteznek az objektumok). Mi a különbség? A GO-nak köszönhetően az SQL Server a második scriptet három részben dolgozza fel, gyakorlatilag úgy, mintha az SSMS-ben soronként kijelölve futtatnánk le az első scriptet (ami abban az esetben szintén működik). Mivel a spTablaolvaso egy tárolt eljárás, vagy az első utasításnak kell lennie a batchben, vagy meg kell, hogy előzze az exec(ute) utasítás. Azaz az első script GO nélkül is kiválóan futna így:

select a, b, c from tabla1
select a, b, c from tabla2
exec spTablaolvaso

Ez eddig leginkább kultúrtörténeti érdekességnek tűnik, amivel lehet villantani a kockakocsmában, de van némi gyakorlati folyománya is. Vegyünk egy másik scriptet:

update tabla1
set azonosito = NULL
delete from tabla where a = 1
insert into tabla2 values(1, 2, 3)

Az update el fog bukni, mert az azonosito oszlop egy identity mező, ami nem nullázható. A delete és insert így meg sem történik, hiszen az első hibánknál megáll a végrehajtás. Tegyünk ide is egy GO-t:

update tabla1
set azonosito = NULL
delete from tabla where a = 1
GO
insert into tabla2 values(1, 2, 3)

Ebben az esetben az update pont ugyanakkora hátast fog dobni, el sem jutunk a delete-ig megint, de az insert megtörténik, mivel az első hibánál megállt a végrehajtás – az adott batchen belül. És aztán fogta a következő batchet, amiben egy insert volt, és azt lefuttatta. Így lehet nagy scriptekben sok hibát generálni, amiket utána nehéz helyrerakni, mert minden batchet külön kell ellenőrizni. Az efféle problémákat egyébként általában ki tudjuk védeni explicit tranzakció használatával.
A másik érdekes eredmény, hogy nem lehet változókat használni GO-kon át:

declare @a int
select @a = 1
GO
print @a

Ez is pirosat ír. De ezen nem lepődtünk meg. Ez pont az a történet, mintha az utolsó sort magában lefuttatnánk: nem ismeri a batch a @a változót, mert nem benne lett deklarálva.
Vannak olyan helyzetek tehát, ahol lehet használni GO-t, és vannak, ahol nem. És vannak, ahol muszáj. Vannak olyan utasítások például, amelyeknek elsőként kell szerepelniük a batchben. Ekkor hasznos elé tenni egy GO-t, hiszen így azt a kulimunkát, hogy kijelöljünk és üssük az F5-öt, megteszi helyettünk a szerver. Ilyen például a CREATE TRIGGER.
Legközelebb talán írok a japán stratégiai játékról is.

1. Ping esetén negatív round-trip time.
2. SQL Servernél tonna hiba az errorlogba
3. A legfrissebb: find használatakor az mtime 0-val nem találja meg a még friss fájlokat (ez mondjuk egy RedHat-on ütött be, bocs az offtopicért, de ez szebb, mint a másik kettő).

Engem az SQL Serveres érdekelt leginkább. Ez konkrétan így néz ki az errorlogban:

Date 11/25/2008 9:57:47 AM
Log SQL Server (Current – 11/25/2008 12:49:00 PM)

Source Server

Message The time stamp counter of CPU on scheduler id 3 is not synchronized with other CPUs.

Az AMD csinált egy hotfixet a bugra, de alapvetően ők nem szervert, hanem desktopot akartak javítani. Miért kell egy desktopba dual-core? Leginkább játszani (bár a GTA4 már quad-core-t akar, két magon szaggat :). Ennek megfelelően a csoda hotfixben, melynek neve AMD Dual-Core Optimizer Version 1.1.4 a clock driftinget a Gaming Mode bekapcsolásával lehet minimalizálni. Sajnos teljesen nem javította meg a problémát, de harmincad részére csökkentette az előfordulását.
Az ötlet amúgy elég hülyén hangzik, hogy gamer patch-csel javítsak élesüzemű SQL-t, de ha a spanyol MSFT SQL support team megtehette, akkor én is :)

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.