MySQL cluster - HOGYAN?

Linux-haladó

Kedves Fórumozók,

Az alábbi problémára keresem a választ, illetve azt, hogy egyáltalán lehetséges-e.

Adott egy központi szerver, ami egy dedikált MySQL szerver. Majd ehhez képest földrajzilag távol (de a kliensek szempontjából helyi) 3-4 (idővel a számuk bővül) másik szerver, szintén dedikált MySQL szerverek. A feladat az lenne, hogy az adatbázist használó alkalmazások (az alkalmazásba történő beavatkozás nélkül) az írást (INSERT, UPDATE, DELETE) a központi MySQL szerveren hajtsák végre (szekvencia ütközés elkerülése végett), míg az adat lekérdezéseket (SELECT) a hely szerveren keresztül. Mindeközben a központi és a távoli SQL szerverek konzisztenciája fennmarad.

Cél: Adott egy központi adatbázis és több telephely. A lekérdezéseket az erősen korlátozott sávszélesség miatt a helyi hálózatban lévő dedikált SQL szerver szolgálja ki, míg az adat módosítások mindig a központi szerveren történik. Arra elég a sávszélesség, hogy az időnként felmerülő (kb percenként 20-30) adat módosítást le tudja kezelni, de arra nem, hogy azt a számtalan lekérdezést is ki tudja szolgálni. Néha egészen nagy adathalmazt kérdez le a szoftver, ami ha az interneten keresztül történne, akkor akár másodperces válaszidőt is eredményezhet, ami nem elfogadható.

Fontos szempontok:
- A 100%-os konzisztencia az adatbázisok között (real time)
- Hibatűrő rendszer, vagyis ha leszakad valamelyik helyi gép a hálóról, vagy a központról, akkor a hálózat helyreállását követően érje magát utol a rendszer.
- A központi szerver elérhetetlensége esetén az írás műveletek fussanak hibára, de a lekérdezések menjenek tovább.
- Bővíthetőség, új telephelyek nyitása esetén könnyű legyen csatlakoztatni a helyi szervert a hálózathoz.
- A szerverek közötti kommunikáció titkosított csatornán történjen.
- Az egyes oldalak skálázhatók legyenek. Ha szükséges, mind a központi, mind a helyi szerverek load balanszolhatók legyenek további szerverek beiktatásával.

Ha ez nem megoldható, akkor merre induljak el, hogyan oldható meg ez, vagy egy ilyen környezet? Fontos, hogy a kliens alkalmazások nem módosíthatók.

Persze nem konfig beállításokat, vagy parancsokat várok itt, hanem irány mutatást, hogy hol keressem a megoldást, vagy mi lehet egyáltalán megoldás.

A segítséget és a válaszokat előre is köszönöm.

  • 6632 megtekintés

( ody42 v | 2014. 02. 11., k – 15:03 )

Tudsz ilyet, a kozpontban levo mysql cluster legyen a master, a telephelyeken levo mysql clusterek pedig slavek, amik a masterrol fognak replikalni. Tehat a setup egy egyszeru master/slave replikacio.
A mysql clusterek kozotti replikacio viszont aszinkron, tehat minimalis delay lehet a slaveken. (Ilyen forgalom mellett nem fogod eszrevenni, kiveve, ha nagyon szar a halozat a siteok kozott)
Ami meg fontos, hogy a mysql cluster csak row based replicationt tud, azaz erdemes megnezni azt is, hogy milyen jellegu irasok fognak tortenni a masteren, mert lehet, hogy egy szimpla update is nagy replication trafficot fog okozni. (Nyilvan ez sema fuggo is, ha normalizalva van, akkor nem gond)

>- A 100%-os konzisztencia az adatbázisok között (real time)
majdnem, lasd aszinkron replikacio

>- Hibatűrő rendszer, vagyis ha leszakad valamelyik helyi gép a hálóról, vagy a központról, akkor a hálózat helyreállását követően érje magát utol a rendszer.
ezt tudni fogja, kiveve ha a masteren kiporog a binlog, de ezt te tudod szabalyozni. worst case esetben ott a backup/restore.

>- A központi szerver elérhetetlensége esetén az írás műveletek fussanak hibára, de a lekérdezések menjenek tovább.
ez nyilvan megoldhato

>- Bővíthetőség, új telephelyek nyitása esetén könnyű legyen csatlakoztatni a helyi szervert a hálózathoz.
uj slaveket hozzaadni pofonegyszeru, a masterhez nem is kell hozzanyulni a master/slave felallas eseten.

>- A szerverek közötti kommunikáció titkosított csatornán történjen.
ssl replicationt tudsz csinalni, az alapesetben eleg kell, hogy legyen

>- Az egyes oldalak skálázhatók legyenek. Ha szükséges, mind a központi, mind a helyi szerverek load balanszolhatók legyenek további szerverek beiktatásával.
mysql cluster tud online bovitest (data node hozzaadast), de a gyakorlatban meg nem probaltam, illetve nem tudom, hogy pl. a re-partitioning is online muvelet-e.

És mi biztosítja nekem azt, hogy az írás a masterre megy, az olvasás viszont a telephelyi szervereken fog történni?

Ha pedig írni is a telephelyi gépekre írok, akkor hogyan oldom meg, hogy ne legyen azonosító ütközés? Pl egyszerre vesz fel egy adatot ugyanabba a táblába. Akkor mind a kettő ugyan azt az azonosítót kapja vissza, és máris van egy ütközés. :(

>És mi biztosítja nekem azt, hogy az írás a masterre megy, az olvasás viszont a telephelyi szervereken fog történni?

Ezt az alkalmazásnak kell tudnia, ha az alkalmazás nincs erre felkészítve, akkor a multi-master irány marad. (ez más megközelítést igényel, és megvannak a veszélyei, pláne ha az alkalmazáshoz nem nyúlhatsz hozzá)

>Ha pedig írni is a telephelyi gépekre írok, akkor hogyan oldom meg, hogy ne legyen azonosító ütközés? Pl egyszerre vesz fel egy adatot ugyanabba a táblába. Akkor mind a kettő ugyan azt az azonosítót kapja vissza, és máris van egy ütközés. :(

Ha auto increment-es tablaid vannak, es csak az uj adat felveteletol felsz, akkor azt meg tudod oldani, hogy minden telephelyre raksz egy mysql access-t, es autoincrement offset-tel felosztod a kulcs tartomanyt a telephelyek kozott.
Ez persze az ellen az eset ellen nem ved, ha ket kliens ugyanazt az adatot akarja modositani, ott a replication soran lehet feloldani az inkonzisztenciat(igy vagy ugy), erre a mysql cluster a 7.1-tol ad lehetoseget.

Takarékosabb, az tuti, de nem kell offsetekkel játszani, aztán bővítéskor újraszámolgatni a tartományokat, mert elvileg a GUID mindig egyedi lesz. Illetve ha kliensoldalon már megbízhatóan tudsz primary key-t generálni a rekordnak, pár utat megspórolhatsz az adatbázis felé.

Erről van amúgy egy egész jó és rövid leírás itt: http://www.codinghorror.com/blog/2007/03/primary-keys-ids-versus-guids…

Ezt kérdeztem már én is, nem kaptam rá választ. (egyébként amennyire tudom, az utóbbi: http://hu.wikipedia.org/wiki/Glob%C3%A1lisan_egyedi_azonos%C3%ADt%C3%B3)

Én meg az ilyen "gyakorlatilag nulla az esélye, bár elméletileg előfordulhat" dolgoktól tudok anyázni hangosan, mert ugye Murphy törvényei... :)

Arról nem beszélve, amit szintén említettem, hogy bizonyos esetekben szükséges a folyamatosan növekvő sorszám, amennyire még érvényesek a könyvviteli és egyéb ismereteim.

Utóbbi.

consider the observable universe, which contains about 5×10^22 stars; every star could then have 6.8×10^15 universally unique GUIDs

A nevével ellentétben nem is cél, hogy _globálisan_ egyedi legyen, elég lokálisan is (egy összefüggő rendszeren belül)

szerk: illetve ugye illik azért kezelni az exceptionöket is, nem kell rábízni magunkat a véletlenre

( cstt v | 2014. 02. 11., k – 15:05 )

Vannak mysql proxyk, de jelenleg nem alkalmasak RW splittingre. Jelenleg ezeket alkalmazás szinten kell megoldani.
Ha megoldható is lenne ott van még a késés kérdése hogy írja a kliens az master 1-re és olvassa a master 2őn, de master 2 még nem frissült.

Szerintem telephelyeken lévő SQL szervereket felejtsd el, és a központi eszköz lehetne redundáns. http://codership.com/content/using-galera-cluster, elvileg ez tud wan clusteringet is.

Az igaz, hogy hogyan kérdez le a telephelyi szerverről, ha az még nem frissült - erre még nem is gondoltam. Mivel írás után azonnal select..., és ha az még nem frissült, akkor nem lesz benne a felvitt, módosított adat. :(

Viszont a telephelyi szerverek nem hagyhatók ki a játékból, mert vannak olyan lekérdezések, amik 2-3MB adatot kérdeznek le. Ezesetben az egy szűkebb sávszélesség esetén 2-3 mp is lehet és sajnos van olyan telephely, ami ettől jobban nem is bővíthető sávszélesség szinten. És akkor ez csak 1 kliens, de telephelyenként akár 5-20 kliens is lehet. Ha azt mindet ráeresztem egy kis sávra, akkor használhatatlan lesz az alkalmazás.

A legegyszerűbb, ha elfelejted a távoli kapcsolatot, csak a local szerverekre írsz és olvasol, majd szinkronizálod azt a mastere. A kérdés, hogy local adatbázisok módosításait kell-e szinkronizálni az összes local adatbázisba, vagy csak a local adatbázisok adatait kell összegyűjteni a masterre. Az id ütközést elkerülheted, ha uuid használsz, az soha nem fog ütközni.

Magam még nem használtam, de leírás szerint lefedi amit kért.
High Availability and Scalability Solution [...]
1) Synchronous replication. A transaction is either committed on all nodes or none.
2) Multi-master replication. You can write to any node.
3) Parallel applying events on slave. Real “parallel replication”.
4) Automatic node provisioning.
5) Data consistency. No more unsynchronized slaves.

Ez alapján megvan a hibatűrés (5) és konzisztencia (1). Helyi lekérdezések és írások lehetségesek, mivel multi-master (2), azok automatikusan szinkronban vannak tartva (1). Korlátozott sávszélen csak az írási szinkron megy majd. Skálázhatóság és load balancing benne van, tudja az említett időbeli szerverszám bővítést is kezelni. Ha elszakadnak a szerverek egymástól, akkor az írások (tranzakciók) hibára mennek / mehetnek, ahogy kéri (1).
Azt nem tudom hogy a szerverek közti kommunikáció titkosított-e, ennek utána kell nézni.
Félreértenék valamit?

( msandor v | 2014. 02. 11., k – 15:25 )

elteszem későbbre (feliratkozom)

( NoMan | 2014. 02. 11., k – 19:53 )

Látom azért van megoldás minden esetben, de miért érzem, hogy egyik sem teljes?

A master-slave esetében úgy látom a gondot az okozza, hogy hogyan irányítsam a kéréseket select - helyben, insert, update, delete - master-en.

A multi-master megoldás pedig egy külső nem mysql képesség, ami bennem felvet egy kérdést: meg lehet ezekben bízni? Használ valaki ilyet éles adatbázison? Milyen problémák merültek fel vele? Mivel az adatbázis pénzügyi dolgokat is kiszolgál, nem volt célszerű ha hibázna, vagy összekeveredne.

Esetleg google keresőszavak mellett kaphatnék némi szöveges véleményezést, tapasztalat megosztás...stb, mivel volt szívás, mit nem szabad elkövetni az adott cuccal...stb. Ez még hatalmas segítség lenne, mert most per pillanat előttem van pár multi-master megoldás és egyikről sem tudom, hogy melyik miért jó, vagy miért jobb, minta másik.

Mysql-nek replikációjának több megoldás is van:
* Mysql CLUSTER tapasztalat lassú, sok megkötés. https://dev.mysql.com/doc/refman/5.5/en/mysql-cluster-limitations-limit…
* Mysql replikáció (beépített) mysql 5.5 -nél Master - slave esetében is rendszeresen szét esik, master -master nem ajánlott
* Galera (xtradb) replikáció min 3-4 szerver kell hozzá csak innodb és más megkötés ami talán értelmes használat esetén elfogadható https://mariadb.com/kb/en/mariadb-galera-cluster-known-limitations/. Itt működik normálisan multi master-master is. Ha replikációt kell csinálni én ezt választanám. Sebességben Mysql CLUSTER felett van de normál mysql alatt.

Mysql replikáció (beépített) mysql 5.5 -nél Master - slave esetében is rendszeresen szét esik

mysql.com -on van egy osszefoglalo, hogy mire kell figyelni master-slave replikacional. Nem trivialis, olvass utana.

Ha szejjelesik, a hiba a te keszulekedben van. A master-slave (avagy 'normal') replikacio teljesen megbizhatoan mukodik.

( NoMan | 2014. 02. 12., sze – 12:39 )

hát egyre szomorúbban tapasztalom, hogy szinte lehetetlen lesz ezt megoldani az eredeti elképzelés szerint...

- a master-slave ugye nem megoldás és ahogy az elhangzott gyakorta szétesik

- a master-master szintén széthullik és még lassulást is okoz

Viszont akkor mi maradt?

Egy hülye kérdés: létezik olyan, hogy távoli mysql cache. Úgy értem, hogy adott egy SELECT ami mondjuk generál egy 2MB-ot adatcsomagot. Azt áttolja a hálózaton és letárolja, majd ha legközelebb azt kérik le, akkor cache-ből szolgálja ki. Ha pedig frissülés van a tárolt adatokon, akkor a cache-t megjelöli elévültként a rendszer, tehát újboli lekérdezés esetén újra az adatbázishoz nyúl.

Vagy van esetleg valami olyan adatbázis szerver, amivel a probléma hatékonyan megoldható? Gondolok itt pl oracle adatbázis szerverre.

Ezt a cache-es dolgot meglehet oldani MySQL-ben. Kell egy tmp tábla ami federated, és a távoli szerverre kapcsolódik, majd a helyi szerveren kell egy trigger, ami insertnél és updatenél lemásolja, frissíti a helyi táblát vagy egy részét.

--
Fontos! Ha berágok, nem feltétlen személyed ellen szól...
openSUSE 13.1 x86_64

( Sixday v | 2014. 02. 12., sze – 13:35 )

Nincs itt semmi nagy varazslat, kell egy master a kozponti telephelyre, a tobbire slave-ek.
Ez a szetesik a replika cimu dolog nem tudom mi lehet, a master/slave replication teljes mertekben megbizhato resze a mysqlnek kb. 8-9 eve.
Az iras/olvasasok szetvalasztasat pedig ha tetszik ha nem csak alkalmazas szinten lehet normalisan megoldani a db layerben.

( hackac | 2014. 02. 12., sze – 20:01 )

Végigolvastam. Lehet hogy eretnek gondolat, de inkább egy terminal server kell a központba, és nem halálfejes MySQL cluster játék :)

( pista_ v | 2014. 02. 12., sze – 20:45 )

Hasonló felállás: központ, több telephely, ahol 7x24-ben dolgoznak és drága vonal esetén is a hibajavítás 14 óra (max), 2-3 óra leállás pedig már igen problémás. A telephely nem nagyváros, így a bőséges sávszél is felejtős. Mivel sok cliens van, így hiába a webes felület, képesek azzal is megenni a sávot, node nem ragozom tovább.
Mindenképp kellett a telephelyre SQL, de nem a saját megoldásával lett megoldva az adatszinkron, hanem saját "szinkron szerverrel". Természetesen a program is ennek megfelelően volt tervezve, azaz, ha szakadás van, attól a helyi SQL-be vihetett fel adatokat, az majd "átszinkronizálódik". Amíg szakadás van, addig a helyi clienseknek jelezte a képernyőn, hogy "Szinkronhiba", így egy lekérdezésnél képbe volt, hogy nem az egész cégre vonatkozó adatot látja.
Most épp másik programra váltunk - egyéb okok miatt -, de a szinkront itt is saját fejlesztésben oldják meg. Nem tudom a program mennyire van felkészítve a több telephelyes működésre, de ha nincs, akkor elég csúnyán bele lehet szaladni egy inkonzisztens adatbázisba.

Bizonyos esetekben nincs is azzal gond, hogy a helyi adatbázisba dolgozik úgy, hogy nem lát ki a rendszer. Viszont vannak olyan esetek, ahol ez szinte elképzelhetetlen pl: könyvelés.

Továbbá a saját sync megoldás, ami még nem tesztelt, nem bejáratott és nem egy közösség használja, hanem csak 1 cég. Így rengeteg hibát és szélsőértéket tartogathat. Nem vagyok benne biztos, hogy az kisebb kockázatot jelent.

Persze javítsatok ki ha tévedek.