(my|pg|ora)sql cluster

Adatbázis: SQL, XML DB

Sziasztok,

Felmerült itt nálunk egy olyan igény, h. hajj de jó lenne nekünk valami magas rendelkezésre állású, load balanced sql megoldás.
Én az Oracle RAC-ot ismerem ilyen szinten, a többi lehetőség elég ködös. Olyan szinten ismerem az alternatívákat, hogy míg a RAC az "everything shared", addig a többiek leginkább a "nothing shared" architektúrát valósítják meg.
A fő gondom, hogy hw szinten nekünk inkább az Oracle megoldása lenne kényelmes, de ugyanakkor szeretnék egy esélyt adni az alternatív megoldásoknak is, mert valahogy mostanában nagyon nem húz a szívem a jósda felé :)
A kérdés tehát az lenne, hogy kinek milyen tapasztalata van ebben az Sql clustering témakörben? Érdemes belevágni, vagy jobb az active/passive megoldás? SAN-ról ha ki tudok tolni 2-3 szerver meghajtására képes IOPS-t és adatmennyiséget, akkor érdemes-e szórakozni a mysql féle replikációs megoldással h. minden van mindenhol, de semmi sincs egy helyen? Hiretlen ennyi hülye kérdés jutott eszemebe, köszi a válaszokat!

Üdv,
Zoli

  • 2168 megtekintés

( bambano | 2010. 11. 10., sze – 15:15 )

én még nem láttam tisztességesen működő, supportált clustert postgreshez. A 9-esben már van valami, de azt még nem láttam.

hm, akkor annak utána fogok nézni, köszi.
Az a legnagyobb kínom h. meg tudom oldani a SAN-t alá, akár egy ocfs2-vel pl., és a lun-t tudom még tükrözni is másik storage-ra is hwesen, de erre a kócerájra sajnos pont az ora féle rac a leginkább "ajánlott", erre szeretnék valami alternatívát, de még én sem láttam semmit ami tuti lett volna :(

egy komoly ellenérvet tudok a rac ellen: azt a kis számocskát a számla végén (a total sum sorban) :))
ha ez neked nem gond, akkor maradj a rac mellett.

postgres téren nem túl rég végignéztem mindent, amit találni lehetett és egyik sem volt jó. ebbe beleértendő a pénzes supportos verzió is. akkor még volt raidelhető sql frontend is, azóta nem tudom, mit csináltak vele.

Nézd, azt, amit azért a sok-sok pénzért tud a RAC, senki mástól nem kapod meg.
Egyszerűen _nincs_ konkurens termék.

Ha engedsz az igényekből, akkor más megoldások is szóbajöhetnek, de ezen a ponton vagy fájdalmas lesz a kompromisszum, vagy az alkalmazásod nem tud architektúrafüggetlen lenni. Azaz be kell építened az alkalmazásba a replikáció valamilyen szintű ismeretét/kezelését - ettől már csak egy lépés, hogy magát a replikációt (elosztott adatbázist) is az alkalmazásod csinálja, és akkor viszont a határ a csillagos ég tudásban és funkcionalitásban.

Nézd, azt, amit azért a sok-sok pénzért tud a RAC, senki mástól nem kapod meg.

A kérdés mindig az, hogy valóban kell-e az a sok-sok minden sok-sok pénzért, amit a RAC adni tud. Előszeretettel tolják a RAC-ot a sales emberek, csak azt felejtik el sokszor, hogy a RAC akkor ad sok-sok előnyt, ha sok-sok PLSQL futkos az adatbázis felett, de simán eladnak RAC-ot olyan helyre is, ahol egy tábla van ezer bejegyzéssel, csak vegye meg az ügyfél, mert jól jön majd, ha lesz kétszer ekkora adatbázisa.

Ha felmerült a váltás lehetősége, akkor igen esélyes, hogy nincs sok-sok PLSQL, hanem az üzleti logikát az alkalmazás rétegben oldják meg, onnan pedig INSERT/SELECT/UPDATE/DELETE utasításokon kívül nem használnak más SQL parancsot. Ebben az esetben tökéletes megoldás lehet a MySQL és a PgSQL cluster is...
--
http://wiki.javaforum.hu/display/~auth.gabor/Home

Pont az ilyen jellegű alternatív megoldások érdekelnek, csak valahogy mindegyik más filozófiával fogja meg ugyanazt a kérdést.
Tehát egzakt shared storage, több node, load-balanced megoldást nem nagyon találtam sem a mysql, sem a pgsql háza táján. Mindenki mindenkivel replikál össze-vissza, de nekem meg pont nem erre lenne szükségem, mert ezt storage szinten elintézem + elég megbízható a storage-em ahhoz h. rá merjem bízni a cuccot mindenféle sw replikáció és stb. nélkül, jah és elég lenne az IOPS / Mbps páros is a dolog alá, tehát azt nem nagyon akarom disztibutálni (szép magyar szó :) )

Btw. igen, leginkább alkalmazás rétegben lenne megoldva a kényes rész. Nem mondom h. nem használnánk triggert, joint, tranzakciót, de ez már csak ilyen business.

Osztott storage fölé nagyteljesítményű SQL szervert nehéz csinálni, eleve arra kell tervezni. Nem hiszem, hogy a közeljövőben bármilyen SQL szerver csak úgy hiphop adjon egy ilyen fícsört, nem érdemes várni se. (Úgy érzem a világ is inkább a shared-nothing clusterek felé megy.)

A Mysql 5.5 -el jön a félszinkron replikáció ami tovább bővíti a replikációban rejlő lehetőségeket, de ez még nem RAC. A Mysql clusternek semmi köze az osztott storage -hoz, bár szinkron a replikáció, más téren erőteljesen kompromisszumos a dolog, a képességeihez kell tervezni az applikációt, nem lehet csak úgy bedobni a meglévő adatbázisokat.

Ha neked RAC kell, akkor neked RAC kell. :) Ahogy más is írta, nincs párja. Ha ragaszkodsz az osztott storage-hoz akkor nem is lesz.

Az MSSQL/DB2 és a többi zárt nemtom hogy áll ezen a fronton.

( f0xhu v | 2010. 11. 10., sze – 16:55 )

nálunk is lesz/készül elvileg valami mysql cluster, aminek társadminja leszek. ha lesz kézzel fogható eredményünk meg kapok engedélyt rá, akkor firkálok róla valamit.

--
A gyors gondolat többet ér, mint a gyors mozdulat.

A mysql nem tud shared storage-ot kezelni párhuzamosan két gépről, mert nincs benne distributed lock manager. És nem tudok róla, hogy készülne ilyen, ergó egyhamar nem is lesz (az Oracle meg ugye minek akarna ilyet? akinek ez kell, az vegyen tőle szépen RAC-ot - na ezért nem hiszem, hogy ilyet akarnának írni)

( Jason v | 2010. 11. 10., sze – 18:21 )

mysql-cluster
orákel szerint carrier-grade

--
"SzAM-7 -es, tudjátok amivel a Mirage-okat szokták lelőni" - Robi.

kicsit felreertheto szerintem a megfogalmazas.
arrol van szo, hogy 5.0-s mysql clusterben minden in-memory volt, es az adatvesztes elkerulese miatt ebben a felallasban minden adat legalabb 2 node-on meg kell hogy legyen.
(SizeofDatabase × NumberOfReplicas × 1.1 ) / NumberOfDataNodes
5.1-ben mar lehet lemezen tarolni a nem indexelt oszlopokat:
http://dev.mysql.com/doc/refman/5.1/en/mysql-cluster-disk-data.html

Tyrael

( Akela | 2010. 11. 10., sze – 23:59 )

Szia!

Én a RAC-hoz hasonló megoldást csak DB2-vel hallottam és az is csak main frames gépeken, igaz itt nem az adatbázis szoftver tudja a leállás nélküli átkapcsolást hanem a main frame memória átvándorlás megoldása. De ezt csak hallottam, nem 100 hogy így is van, Oracle DB-kel dolgozok nem DB2-vel.
Szerintem pontosan fogalmazd meg mit is akartok megvalósítani. Kell-e nektek a DB szinten való load-balancing, vagy csak a HA megoldás kell, ha elég a HA megoldás milyen is kell pontosan, Data-Guard,Stream,Cold Failover, ha Cold Failover-es akkor milyen, kézi átkapcsolásos, oracle clusterware-rel megoldott vagy esetleg 3rd party féle átkapcsolásos.Ha Data-Guard-os akkor logikai vagy fizikai ezenkívül maximális védelem, maximális rendelkezésre állás vagy maximális teljesítmény módban. Ha RAC-ot akarok akkor az alkalmazásaitok amik rajta fognak futni nem e ütköznek bele a RAC hibáiba, mert sajnos vannak neki, és lehet pont emiatt fogjátok megutálni a RAC-ot, mert amire nektek kell arra nem jó, holott szerintem az egyik legnagyobb találmánya az ORACLE-nek.
Oracle szinten így hirtelen ennyi jutott eszembe, amivel foglalkoztam is, bár a stream-est még sose próbáltam /Primary DB és a Secondary DB között oracle stream megoldással kerülnek át az adatok/, ezt én is csak hallottam. Lehet ezenkívül még vannak újabb megoldások.
Én azt javasolnám, hogy szedd össze pontosan mit és mire is szeretnétek használni, és ezután érdeklődd meg melyik megoldás is lenne a legjobb nektek.

A DB2 normal PC-n is tudja, a Workgroup Edition-tol felfele, PureScale neven fut, es teljesen korekt shared everything cluster megoldas. A z/OS verziobol portoltak lefele, es aki hasznalta mar, a szerint nagyon durvan jo, egyeduli problema csak az ara (15k USD/socket, bar az meg mindig jobb mint a RAC).
Ha mar DB2, nekik van egy HADR nevu verzio is, ami 2 gepes hotspare shared nothing cucc, ezt probaltam is, HA/DR celokra jo, viszont clusterezni (teljesitmeny-novelesi cellal) csak bizonyos trukkok mellet (A server master x db-n, slave y db-n, B server master y db-n, slave x db-n0) Elonye hogy baromi stabil, megbizhato es relative fagyipenzbe kerul (1500USD/szerver)

A HADR az shared nothing, tehat nem kell kozos tarolo, mind2 szervernek sajat replikaja van a teljes db bol. Gyk ugy mukodik hogy diszkreiraskor a master elkuldi a binaris logot a slave-nek, amelyik ugyanugy beleirja (a mar kiszamolt) datat a sajat db-jebe. Lehet szinkron es aszinkron verziot is csinalni belolle, eleg popec cuccc.

Hm, ebben az esetben viszont nem tudom kitolni a storage-ről a performanciát, hacsak mondjuk nem azt csinálom h. pl. 2 lunon vannak a cuccok, 1-es lun a master, 2-es a slave és akkor egy ilyen "fura" elosztás, mint amit javasoltál is. Tükrözés meg TrueCopy és van még 1 mirrorom másik storage-re is. Atombiztos kb.

Ez a technológia ha jól értem megfelel az ORACLE dataguard-jának. Azaz amit végrehajtottam SQL utasítás(vagy ha akarom akkor asszinkron módba később) szinkronizál a slave/standby felé.
Ezért is írtam, hogy pontosan mondja el mit szeretne mert elég sok megoldás létezik, de a RAC amit előtte szeretett volna az nem DR megoldás.(Lehet DR is de azt csak bizonyos távolságban, ezért szokták azt csinálni hogy egy RAC cluster az 1ik telephelyen egy RAC cluster a másik telephelyen és közte DataGuard szinkronizál, csak ez nagyon költséges).

( Jason v | 2010. 11. 11., cs – 08:06 )

http://wiki.postgresql.org/wiki/Postgres-XC

talán. kéne hozzá vagy 3-4 gép és kipróbálnám. Mondjuk akkor a mysql-cluster -t is, de ahhoz minimum 5 kell, hogy értelme legyen.

--
"SzAM-7 -es, tudjátok amivel a Mirage-okat szokták lelőni" - Robi.

( ody42 v | 2010. 11. 11., cs – 13:44 )

Bar ez is Oracle, es egyre erdekesebb license araik vannak, de a mysql ndb cluster nem olyan rossz, de teny, hogy nincs osszehasonlitasi alapom, mert csak ezzel dolgozom. :) Sok RAM, es viszonylag gyors diszk alrendszer kell (LCP/GCP generalas miatt). Maga a cluster manageles viszont elegge kezi vezerlesu. Nalunk van alatta egy OpenSAF alapú mukodo middleware.

A clusteren beluli manageles meg nem trukkos, de ha meg arra huzol egy reteget...

Pl. van egy clustered, amiben van:
2 ndb management node
x db storage node, paronkent szinkron replikacioval
x db sql node, amikhez az applikaciok kapcsolodhatnak

majd kitalalod, hogy ez igy keves, es az egeszet megduplazod egy masik szolgaltatonal, a ketto kozott pedig csinalsz egy aszinkron replikaciot. Na itt mar kezd bonyolultabb lenni a management... :)

Jo az :)
A ket nagy cluster kozott master-slave (aszinkron) replikacio van. Mivel fizikailag is messze vannak egymastol, a szinkron replikacio szoba sem johet.
A kis clusterben a node groupon belul pedig szinkron replikacio van. (asszem 2PC amit a mysql hasznal)

Tehat van ket site, a ketto kozott aszinkron replikacio, a siteon belul pedig szinkron replikacio.