hello
van egy mysql szerverem és rákerült pár nagyobb adatbázis és eléggé lassú lett
ezért valami cluster megoldásban gondolkodom ahol 2-3 szerver szolgálná ki a
lekéréseket és így nem utolsó sorban a redundancia is megvalósulna
viszont úgy kellene megcsinálni hogy az ügyfeleknek ne kelljen változtatni semmit
jellemzően myisam és innodb alapú adatbázisok vannak,
tehát egy éjszakai 1 órás kieséstől eltekintve minden ugyan olyan lenne mint előtte
Még csak most olvasgatom a témát és ugy értelmezem hogy az
adatbázis motort le kell cserélni ndb -re minden adatbázisban
Valóban így van ?
van olyan megoldás amiben nem vesznek észre semmit az ügyfeleknek a változásból ?
ki mit ajánl ?
köszi a segítséget előre is
- 2303 megtekintés
Hozzászólások
Bar pontosan nem irtad le mit is szeretnel, de szerintem a mysql-proxy lesz a baratod.
-== If you want peace prepare for waR ==-
- A hozzászóláshoz be kell jelentkezni
A mysql-proxy mindenre jó csak balancingra nem. A r/w splittinget én speciel nem tudtam normálisan megoldani. Arról nem is beszélve, hogy néha elszállt nagyobb terhelésnél. Illetve a nativ sqlhez képes elég vicces teljesítményt ad. Szerintem alkalmazás szintjén kellene megoldani a balancingot. Master-Slave replikációval.
- A hozzászóláshoz be kell jelentkezni
A kovetkezo esetben azert eleg hasznalhato tud lenni.
Van 1 master server es 2,3... replica. Kodbol eleve szetvannak valasztva a r/w muveletek. Insertek masterre, select-ek a mysql-proxy-ra ami elosztja a terhelest a slave-ek kozott.
Nem tudom te mikori verziot hasznaltal, nekem egyenlore nem dolt be nagy terhelesnel.
Es a sebessegere sincs panaszom. Nyilvan van kicsit kesobb valaszol, mint proxy nelkul a szerver de ez adott feladatban levo query-khez kepest elhanyagolhato, osszessegeben gyorsult a rendszer.
-== If you want peace prepare for waR ==-
- A hozzászóláshoz be kell jelentkezni
Ha a kódban szét van választva a r/w minek a mysql-proxy?
- A hozzászóláshoz be kell jelentkezni
Mert egyszerubb 3-4 slave kozott vele elosztani a lekerdezeseket mint kodban mindig sorsolni egyet.
Lentebb irtad hogy ti pont kodbol valo sorsolassal oldottatok meg, nem vitatom hogy kicsiben ez a legjobb megoldas, de ez kenyelmesen csak akkor valosithato meg ha mar a rendszer tervezesenel ezt a szempontot figyelembe veszik.
Nagyon nagyban viszont mindenkeppen valami eros clusterezes az ami kell.
Amugy mysql-proxy-ban LUA-val szet lehet valasztani a read muveleteket a write-oktol. Ezzel csak az a baj hogy ezt nem lehet nagyon alltalanosra megirni, igy mindig az adott rendszert figyelembe veve kell eljarni.
-== If you want peace prepare for waR ==-
- A hozzászóláshoz be kell jelentkezni
A kérés éppen az volt, hogy a kódhoz ne kelljen nyúlni, hisz nem fogják az ügyfelek átírni minden kódjukat emiatt, inkább keresnek valaki mást, aki meg tudja oldani a hostolást normálisan ;)
- A hozzászóláshoz be kell jelentkezni
A cluster-hez bizony nbd kell. Az ndb-nek vannak kötöttségei - legalábbis amikor néztem voltak neki. Meg kell nézni, hogy az érint-e téged.
"Jegyezze fel a vádhoz - utasította Metcalf őrnagy a tizedest, aki tudott gyorsírni. - Tiszteletlenül beszélt a feljebbvalójával, amikor nem pofázott közbe."
- A hozzászóláshoz be kell jelentkezni
subscribe
- A hozzászóláshoz be kell jelentkezni
+1
- A hozzászóláshoz be kell jelentkezni
load-balancing is megfelel erre szerintem
- A hozzászóláshoz be kell jelentkezni
A LB-t hogyan valósítanád meg?
- A hozzászóláshoz be kell jelentkezni
hasonlóan mint ez, igaz nem csináltam még ilyet, de szemezek vele :)
http://www.howtoforge.com/loadbalanced_mysql_cluster_debian
- A hozzászóláshoz be kell jelentkezni
Olyan megoldást láttam már hogy van két SLAVE egy MASTER, replikáció van köztük. Írni csak a MASTER-re írnak, és %-os arányban van elosztva a MASTER/2 SLAVE között az olvasás, de ez PHP-ból lett megoldva.
- A hozzászóláshoz be kell jelentkezni
Mi is így oldottuk meg, nagyon más megoldás nincsen jelen pillanatban szerintem, amivel normálisan/olcsón meg lehet oldani LB-t mysqlnek.
- A hozzászóláshoz be kell jelentkezni
mármint úgy érted, hogy írni MINDENHOVA írnak, és az olvasás megy 3 felé.... ugye?
- A hozzászóláshoz be kell jelentkezni
"Írni csak a MASTER-re"
melyik részét nem érted?:)
- A hozzászóláshoz be kell jelentkezni
és akkor a slave-ek hogy frissülnek?
- A hozzászóláshoz be kell jelentkezni
a MASTER tolja beléjük a változásokat. automatikusan.
- A hozzászóláshoz be kell jelentkezni
...azaz gyakorlatilag azokra is írunk.
- A hozzászóláshoz be kell jelentkezni
a kliens nem ír, csak az egyikre. és ez a lényeg. az, hogy valaki más átvarázsolja az adatokat, az a kliens szemszögéből transzparens, nem igényel változtatást a kliensben.
- A hozzászóláshoz be kell jelentkezni
Igen, de olvasni "tudni kell" mind a 3-ról, azt pedig valahogy meg kell oldani. :)
- A hozzászóláshoz be kell jelentkezni
Connection pool, bármelyikről olvashatsz, pont ez a lényeg. A kérdés mondjuk mindig az, hogy egy network split esetén hogy működik egy ilyen rendszer...
- A hozzászóláshoz be kell jelentkezni
Connection pool, bármelyikről olvashatsz, pont ez a lényeg. A kérdés mondjuk mindig az, hogy egy network split esetén hogy működik egy ilyen rendszer...
- A hozzászóláshoz be kell jelentkezni
MySQL replikációnál óvatosan majd az írás utáni azonos adatra vonatkozó olvasással a slave serverekről.
Van ugyanis delay is!!! (Azaz egy kis késleltetés, amíg a Master-re írt adat a Slaven megjelenik.)
Értelemszerűen minnél nagyobb a terhelése az adatbázis szervernek annál több lehet a késleltetés.
Slave serverre ezért érdemes inkább olyan applikáció részeket kirakni, amelyek nem igényelnek realtime használatot.
- A hozzászóláshoz be kell jelentkezni
az "kis" delay előre nem kalkulálható ideig is eltarthat.
ergó üzembiztos megoldáshoz aki írni is szeretne, és konzisztens adatbázist szeretne látni (azaz szinte mindenki), az az olvasáshoz is csak a mastert használhatja.
na innentől kezdve egész hasznos ez a "megoldás"...
- A hozzászóláshoz be kell jelentkezni
Replikáció, de itt is figyelni kell a splitre, amire ha jó programozok vannak kéznél gyorsan találtok megoldást.:)
- A hozzászóláshoz be kell jelentkezni
Network split után merge-elni kell majd, ez azért egy nem triviális feladat.
- A hozzászóláshoz be kell jelentkezni
Nem mondtam, hogy triviális feladat.
- A hozzászóláshoz be kell jelentkezni
Régóta foglalkoztat engem is a téma, de még nem találtam igazán jó megoldást.
- A MysqlProxy még elég experimental, valóban szinte többet árt, mint használ (míg kikalkulálja, kihez is forduljon, addig direktben egy agyonterhelt mysql szerver is már rég válaszolt)
- NDB-t - szerintem - csak egy, nagy, saját kezelésű, önmagában nagy adatbázisforgalmat generáló alkalmazáshoz érdemes felépíteni, legalább 3db szerverrel, amik közül szinte garantálni tudod, hogy bármilyen körülmények között max. 1 halhat le (memóriában futó adatbázis)
- Talán a Master-Slave replikáció lehet a legalkalmasabb, de ez is inkább saját alkalmazásoknál működhet jól, mert alkalmazás szinten kell elosztani a terhelést. Max. a saját alkalmazásaidnál, meg a felhasználók esetleg azonos rendszereinél (joomla, drupal, stb.) megpatch-eled az adatbázis modult a többiek meg jobbhíján terhelni fogják a master-t
- A hozzászóláshoz be kell jelentkezni
+1
- A hozzászóláshoz be kell jelentkezni
- A hozzászóláshoz be kell jelentkezni
Az uj NDB-nek megszunt csomo limitacioja (alter table pl), viszont meg mindig lassucska. Mostanaban meregettunk ilyet. Sok data nodedal tuti lehet novelni a sebessegen, de ahhoz kell jo par szerver meg ndb instance.
- A hozzászóláshoz be kell jelentkezni
Kicsit off, de már rég meg érdekel: más -akár kereskedelmi- adatbázisszerver támogatja komolyabb korlátozások nélkül az N node -os clustert? (ahol N mondjuk 8/16)
- A hozzászóláshoz be kell jelentkezni
én a RAC kivételével nem ismerek ilyen általánosan használható megoldást.
a szerény véleményem, hogy ezt a funkcionalitást jól, hatékonyan és általánosan (a kliens ne vegyen észre semmit) nem biztos, hogy egyáltalán meg lehet oldani. szerintem ez egy tipikus "silver bullet", ami ha létezne, a világ összes problémáját meg lehetne vele oldani.
NB: a RAC a különösen hatékony jelzővel van hadilábon.
- A hozzászóláshoz be kell jelentkezni
Oooo... tartok tole, hogy vannak olyan problemak a vilagban, amire meg egy db cluster sem megoldas :-)
--
()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.
- A hozzászóláshoz be kell jelentkezni
igen, a szar kódot semmi nem javítja meg :)
--
"SzAM-7 -es, tudjátok amivel a Mirage-okat szokták lelőni" - Robi.
- A hozzászóláshoz be kell jelentkezni
Toltak alá vasat: exadata v2. TB méretű pci-x-be illesztett ssd tárolókat használ cache-nek, így már hatékony :-)
Üdv,
BaZso
- A hozzászóláshoz be kell jelentkezni
http://www.mysqlperformanceblog.com/2009/10/09/finding-your-mysql-high-…
http://www.mysqlperformanceblog.com/2009/10/16/finding-your-mysql-high-…
http://www.mysqlperformanceblog.com/2009/11/13/finding-your-mysql-high-…
Ha tobb ugyfel is van lehet egyszerubb tobb master-master replikaciot beuzemeleni es terheles fuggvenyeben szetszorni az ugyfeleket.
- A hozzászóláshoz be kell jelentkezni
Master-Master replikáció azért rendesen le tudja szívatni az embert.:) (pl. autoincrement)
- A hozzászóláshoz be kell jelentkezni
auto_increment_increment
auto_increment_offset
- A hozzászóláshoz be kell jelentkezni
1 példa volt a sok közül, nem csak ezzel van gond szerintem.
- A hozzászóláshoz be kell jelentkezni
Nyilvan nem csodaszer, megvannak a maga limitacioi, de viszonylag egyszeruen beallithato, monitorozhato, nem igenyel shared storage-ot.
- A hozzászóláshoz be kell jelentkezni
Jogos, de szerintem a M-M replikációhoz is alkalmazkodnod kell alkalmazás szintjén is.
- A hozzászóláshoz be kell jelentkezni
Az ndb-nek nagyon sok limitacioja van, pl a 8k-s rekordmeret, nincsenek foregin key-ek, ezekbe valoszinu bele fogsz futni egy ilyen kornyezetben. Azzal nem ertek egyet, hogy az ndb lassu, bizonyos muveletek lassuak ndb-ben, pl nagyobb joinok. A scaledb lenne neked valo, ez RAC szeru megoldas mysql-re, ez viszont meg nem jott ki, es shared storage kell hozza.
- A hozzászóláshoz be kell jelentkezni
Kár, hogy Béta még. Egyébként majd ha egyszer eljut odáig, hogy produktív környezetben használható lesz biztosan jó lesz. De elég sok kérdést, hozna magával a scaledb... Milyen cluster fs-t használjon az ember.;) Illetve szerintem nem mostanában lesz ennek a stabil változata.
- A hozzászóláshoz be kell jelentkezni
Szia,
- NDB valszeg nem lesz neked jo , mert sok a limitacio es felfog tunni a usereknek elobb utobb.
- MYSQL-PROXY experimental es a megbizhatosag .. hat alacsony.
- Mysql multimaster (esetleg MMM-el) nem arra van tervezve (mivel nincs is tervezve), hogy mindket helyre irj igy erosen inkonzisztenciat kockaztatsz (ez maatkittel workaroundolhato, de semmikep sem javasolt ha nem ismered PONTOSAN az alkalmazast.
- READ loadot lehet balanceolni konnyeden LVS -el sima master-replica viszonyokban.
- HA-PROXY-t erdemes lehet megvizsgalnod, de R/W splitting nagyon problemas es mysql alapvetoen nem tudja.
Szoval SZVSZ vagy rizikot vallalsz es Multimaster/ha-proxy/mysql-proxy, vagy izmos gepeket es ndb-t allitsz uzembe, ertesitve a usereket a limitaciorol (mielott azonban ezt bevallalod tanuljatok meg alaposan)
drk
- A hozzászóláshoz be kell jelentkezni
A több szerverre egyszerre történő írást 2PC algoritmussal lehet valamilyen szinten
kezelni, azonban ehhez kell egy tranzakció manager, amelyik tárolja a függőben lévő
tranzakciókat.
Viszont, ha két különböző szerverről próbálsz adatbázisokba írni 2PC-vel akkor az ugyanúgy
bukós lesz amennyiben a tranzakciómenedzserek nem beszélgetnek egymással. Hmmm... ez már
nem az egységsugarú user joomlát telepít hűde biztonságosan kategória....
- A hozzászóláshoz be kell jelentkezni
+1
- A hozzászóláshoz be kell jelentkezni
Ezt csak azért tudom, mert 1 hétig dolgoztunk a nagyon über algoritmusunkon, aztán rájöttünk, hogy
hát... ez nem működik. Hátha sikerül másoknak spórolni 1 hetet :)
- A hozzászóláshoz be kell jelentkezni
Nekem ez kiválóan működik: http://downloads.mysql.com/docs/mysql-load-balancer-en.a4.pdf
A slaveket --proxy-read-only-backend-addresses -re kell megadni, míg a mastert --proxy-backend-addresses -re kell megadni. Persze a felhasználás jellege: sokkal több select mint insert...
- A hozzászóláshoz be kell jelentkezni
Még ugyan nem teszteltem, de szimpatikusnak tűnik a Tungsten a feladatra:
http://tungsten.sf.net
A Connector és Router együtt papíron elvileg orvosolja a problémát.
A másik lehetőség ha minden kötél szakad, hogy a Master - Salve elrendezés mellé még bepakolnak memcached szervert. Íráskor nem csak a Master kapja meg az adatokat, hanem a memcached is. Olvasáskor pedig először a memcache-ből próbálja az alkalmazás kiszippantani az adatokat és csak akkor fordul az adatbázishoz ha ez sikertelen volt. Sikeres adatbázisból történő olvasás után szintén berakja az adatokat a memcache-be.
Nem éppen a legegyszerűbb megoldás de sok helyen működik. Hátránya, hogy ha elszáll a memcached akkor a fene megette az egészet mert a teljesítménye a rendszernek irgalmatlanul lecsökken amíg az adatok újraépülnek a cache-ben.
- A hozzászóláshoz be kell jelentkezni
terracotta for php? :D
--
"SzAM-7 -es, tudjátok amivel a Mirage-okat szokták lelőni" - Robi.
- A hozzászóláshoz be kell jelentkezni
Illetoleg megint ott tartunk, hogy kod oldali support kell a dologhoz. Es ez nem biztos, hogy az, amit a kerdezo szeretne.
--
()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.
- A hozzászóláshoz be kell jelentkezni
A tunsten-hez nem kell a kódhoz nyúlni mert a connect elintézi helyettünk. A másik pedig szétosztja a kéréseket.
Viszont azért írtam le a másik megoldást is mert ezt hosszú távon érdemes meglépni még ha kényelmetlen is mert sok pénzt (szervert) lehet így megspórolni.
- A hozzászóláshoz be kell jelentkezni
subscribe
____________________
Ha igen akkor miért nem...
Linux 2.6.30-gentoo-r4 i686 Intel(R) Core(TM)2 Duo CPU E6550 @ 2.33GHz GenuineIntel GNU/Linux
- A hozzászóláshoz be kell jelentkezni