Mysql-proxy read-only-backend probléma

Adatbázis: SQL, XML DB

Hello,

Mysql-proxy segítségével szerettem volna többek közt r/w loadbalancingot megoldani két sql szerver közt de sajnos nem sikerült , az alábbiakban részletesen vázolom mit próbáltam.
Adott két mysql szerver Master-Master replikációval (hívjuk őket sqlA és sqlB-nek). A szervereken sok DB található, és ezekhez csatlakozik több másik szerver. (hívjuk őket cliensA cliensB cliensC-nek....)
A kliensek mindegyikén található egy-egy mysql-proxy.

    mysql-proxy 0.7.2
    glib2: 2.16.6
    libevent: 1.3e
    lua: Lua 5.1.3
    LUA_PATH: /usr/lib/mysql-proxy/lua/?.lua
    LUA_CPATH: /usr/lib/mysql-proxy/lua/?.so
    == plugins ==
    admin: 0.7.0
    proxy: 0.7.0

A cél az lett volna, hogy a kliensek a proxy-n keresztül csatlakoznak az sql szerverekhez. Az sqlA szerveren írás-olvasás működne, az sqlB-n csak olvasási műveletek futnának.
Úgy gondoltam erre a mysql-proxy tökéletes megoldást biztosít a következő configgal:

    ENABLED="true"
    OPTIONS="--admin-address=:4041 --proxy-address=:3306 --proxy-backend-addresses=10.10.10.1:3306 --proxy-read-only-backend-addresses=10.10.10.1:3306 --proxy-read-only-backend-addresses=10.10.10.2:3306 --log-file=/var/log/mysql/mysql-proxy.log --log-level=debug"

Sajnos ez így életképtelen volt, nem volt hajlandó a két read-only beállítást figyelembe venni. Nem kevés keresgélés után kiegészítettem a fenti configot rw-splitting.lua scripttel. A neten fellelhető patchekkel és kiegészítésekkel felvértezve.

    ENABLED="true"
    OPTIONS="--admin-address=:4041 --proxy-address=:3306 --proxy-backend-addresses=10.10.10.1:3306 --proxy-read-only-backend-addresses=10.10.10.1:3306 --proxy-read-only-backend-addresses=10.10.10.2:3306 --proxy-lua-script=/usr/lib/mysql-proxy/lua/proxy/rw-splitting.lua --log-file=/var/log/mysql/mysql-proxy.log --log-level=debug"

Ekkor már az sqlB szerveren is történtek olvasási műveletek. De a kliens szervereken futó alkalmazások , nagyon akadozva működtek csak, legtöbbszőr elveszítették a kapcsolatot vagy egyáltalán nem is tudtak csatlakozni az sql szerverekhez.

A mysql-proxy jelenleg is működik úgy, hogy csak egy --proxy-backend-addresses van megadva semmi más, de ezzel pont a lényegít veszti el.
A kérdésem az lenne, hogy ezzel kapcsolatban van valakinek tapasztalata , vagy más ötlete javaslata, hogyan lehetne ezt megvalósítani.

Előre is köszi.
üdv

  • 1578 megtekintés

( cydrk | 2009. 09. 08., k – 16:58 )

Szia,

Latom nem sokan valaszoltak eddig.

Amenyit nekem sikerult foglalkozni mysql proxyval, erosen experimental es rendszerint sok haxolas aran hajlando csak mukodni.
Allati jo lesz, ha egyszar stable lesz. Addig is esetleg tudok ajanlani valami mast attol fuggoen mit szeretnel?

drk

Szia,

Nagyon sokat olvasgattam már a témáról, nem csak fél órát szántam rá... A végén én is arra jutottam, hogy ez így most nem fog menni, hagyom egy darabig mert folyamatosan változik , lehet 1-2 hét vagy 1 honap mulva lesz valami újitás.

Lényegében bármilyen működő megoldás érdekelne, a lényeg , hogy a terhelést el tudjam osztani két szerveren és esetleges meghibásodás esetén is legyen tartalék. Szóval ha van ötleted elég nyitott vagyok.

üdv

Hat.. En is igy vagyok vele, varok.. mar lassan 3. eve ha jol remlik de lehet csak 2. Valtozik, jonnek ujdolgok javitjak a butasagokat stb azota is ez van es azota is elmondjak mysql-ek hogy milyen jo(lesz).

Nos ezzel egy igen erzekeny temaba nyultal :) Millio szamra vannak megoldasok.
Ezek kozott lehet valogatni ezrevel. Gepeid mennyisegetol fuggoen, az alkalmazashoz valo hozzaferestol fuggoen (pl tudod e szerkeszteni a kodot esetleg kepben is vagy vele) egesz addig, hogy teljesen transparens legyel az alkalmazas fele... Vegtelen...De csak hogy valami esszerut is irjak.

Klasszikusok:
Mysql master + replikak: Ezesetben 1 mastered van es tobb replika, mastert irod, replikakrol olvasos. Esetleg mas tablakat/db-ket replikalsz mas-mas slave-ekre, ezzel kicsit megoldva shardingot.

Master-Master+slave: Ezesetben multimastert kell hasznalni amirol erdemes tudni hogy experimental (ambar szemelyes kedvencem). A "klasszikus" felallas, hogy a 2 mastert HAproxyval vagy MMM-el manageled. MMM a slavekre is hat, haproxyval eddig csak olyan megoldast lattam ahol az adott eppen meghalt master slave-jei is kiesnek. Ez is jo, de a multimasterben van kockazat. (konzisztencia tesztnek ott a maatkit es az egyik post amely szereny szemelyem femjelzi master syncronizalas lock nelkul)

Illetve a 3. klasszikus modszer, a mysql+heartbeat+drbd mint master es ezen ucsorgo replikak. Ez talan a legkimeletesebb mivel itt a legkisebb a riziko.
Ellenben 1 geped unatkozni fog es nem segit az olyan gondokban mint a nagy tablak alterelese meg stb (es ha mar onmagam nepszerusitem: mit tehet erted a multimaster)

Plusz 4. lehetosegnek ott az ndb amit csak azert emlitek mert letezik, amugy draga sok tekintetben nem csak penzugyileg es limitaltak a kepessegei.

Ha esetleg barmelyikben erdekelne bovebb info, szivesen.

drk

Szia,

Köszi a választ, hasznos volt. Az MMM-el még nem találkoztam de meg fogok ismerkedni vele.
Mindenféle képpen olyan megoldást szeretnék amivel nem kell beavatkozni a klienseken futo alkalmazásokba. Egy köztes réteget akarok beiktatni ami mindent eldönt és megold helyettuk. (melyik szerverről olvas hova ír, stb...)
Jelnleg mint írtam is Master-Master replica van az sql szerverek közt, de mindenképpen írni csak az egyikre szeretnék, a másik a terhelés megosztásban segétkezne és ha kiesik a fő akkor még van tartalék.

üdv

A multimaster akar MMM el relative experimental de ugytunik neked nem gond.
MMM -nel a 2 master kozul az aktiv kap egy writer ip-t, abba lehet irni es reszemrol LVS-el szeretem balance-olni a replikak kozt.

De azt hiszem neked a HAproxys megoldas jobb lenne.. HAproxy+mysql. A srac bevallasa szerint application layer alapon megy (haproxybol kiindulva ez egesz logikusan hangzik :)). Es ez az ami neked jolesz :)

drk

Utána néztem és átgondoltam, de ez azért nem jo nekem(amugy nagyon frankó) mert az alkalmazási rétegben kell ketté választani már az írást és az olvasást, legalábbis én így értelmeztem. Mivel itt weboldalakat is ki kellene szolgálni , és nem tudom ,hogy a php-nak lenne ilyen modulja, ami ezt csinálja így ez buko.

üdv

( petya | 2009. 09. 08., k – 17:06 )

Van egy perconas meres arrol, hogy mekkora overhead a proxy, es az derult ki, hogy nagy. Probaltak korabban is megcsinalni, de akkor meg nem mukodott.