MySQL Cluster vagy replika

Adatbázis: SQL, XML DB

Sziasztok!

A következő problémába futottam bele, a segítségeteket kérném. Van fizikailag két gépem, ezeket szeretném clusterbe rakni, vagy replikálni a lényeg, hogy minél nagyobb rendelkezésreállást biztosítsak. Manual és gugli után, a következő-t már tisztán látom. A clusterezéshez szükség lenne egy harmadik management gépre, ez nem igazán kivitelezhető. (Rövid idő, hosszú beszerzési idő.) Mi a véleményetek a replikációról? Ki mit ajánlana az adott lehetőségekhez mérten? Előre is köszönöm.

  • 1843 megtekintés

( andrej_ v | 2009. 09. 29., k – 16:47 )

A mgmt lehet ugyanott ahol az egyik node. A replikáció az master-slave alaphelyzetben, a master-master replikációt csak roppant körültekintően lehet bevezetni. Egyébként jól szokott működni.

( uTibor | 2009. 09. 30., sze – 10:31 )

Jó reggelt!

Lenne még egy kérdésem: Tegyük fel, hogy master-slave felállásban replikálok egy MySQL instance-t, ebben az esetben, a master esetleges lehalása esetén, a slave átveszi a munkát, illetve van-e lehetőség ennek megvalósítására? Előre is köszi.

( petya | 2009. 09. 30., sze – 10:45 )

Udv!

MySQL Cluster: az NDB nem egy general purpose engine, ha erre akarsz menni, nezd meg, hogy amire hasznalod, arra jo e. Hulye neve van szerintem, mert mindenki azt hiszi, hogy igy kell HA MySQL-t csinalni.
Replikacio: itt azt kell eldontened, hogy az adatintegritas vagy az adatok rendelkezesre allasa a fontos. Ha az integritas, akkor heartbeat,drbd-s aktiv-passziv cluster. Ennek a hatranya, hogy amikor crash utan kapcsol at a heartbeat a passziv nodera, a mysqlnek valoszinu instance recoveryzni kell, ami a mysqlnek legendasan sokaig tart (van egy perconas patch, ami par sor, es nagysagrendet tuningol rajta).
Ha az adatok rendelkezesre allasa a fontos, akkor az MMM-et nezd meg. Ez master-master replikacio, de hasznalhatod ugy, hogy csak az egyiknek van writer role-ja. Itt Az aszinkron replikacio miatt adott esetben adatvesztessel jarhat az atkapcsolas, de maga az atkapcsolas rovid ido lesz. Ezt ki tudod ugy vedeni, hogy a binlogokat drbd-re rakod, igy meglesz a masik node-nal is, failoverkor vissza tudja jatszani. Ezzel a sync_binlog=1 nyilvan velejar.

Egyre erősebben hajlok a replikáció felé. A következő elképzelésem jelenleg: Replikáció, master-slave felállásban, előtte egy mysql proxy, ami failovelvernél (lehal a master) átdobja a munkát a slave-re. Egyik problémám ebben a megoldásban, hogy a MySQL proxy még csak alpha állapotú, így nem ajánlják produktív környezetben. A legfontosabb a rendelkezésre állás, ezt kellene valahogy elérnem. Utánna nézek az MMM-nek.

Ehhez még egy általam tapasztalt dolog: kb. egy éve volt szerencsém egy mysql clusterhez. Egy adott webes alkalmazás alá kellett, ami viszonylag méretes adatbázist használt: tény, hogy működött, de a valamennyire is összetett query-k esetében egészen gyalázatos sebességet produkált.
Emiatt gyakorlatilag használhatatlan volt az alkalmazás (a query-k átírása nem jöhetett szóba).

A cluster helyére egy master-slave/slave-master replikáció került: azóta is megy gond nélkül, a sebessége is nagyon jó.

Szóval a clusternél _nagyon-nagyon_ kell figyelni az adatbázis szerkezetére és a query-kre. Ami egy lokális (normál) mysql-en jól fut, az itt katasztrófa tud lenni...

( mazursky | 2009. 10. 02., p – 15:47 )

szintén érdeklődök ;~))

/mazursky 

Love your job but never love your company!
Because you never know when your company stops loving you!