A kovetkezo architekturat ti hogy valositanatok meg?
A < -- > B
| |
v v
C..X D..Y
A,B - 2 RW node (active, multi-master)
C,D..X,Y - n RO node (passive, slave)
Az irasok a 2 masteren tortennenek, van hogy egymastol foldrajzilag tavol eso helyen, de azert kielegito kapcsolattal. A slavek a hozzajuk kozelebb eso mastert hasznaljak alapbol es failoverelnek a masikra ha az kiesik, ha visszajon es konzisztens lesz (masik mastertol behozza a lemaradasat) akkor pedig visszacsatlakozik.
Rengeteg felmegoldast talaltam:
- MySQL-MMM: active-passive megoldast tud csak, rengeteg esetet nem kezel le (levlistajuk tele van szethullott cluster reportokkal), kell kulon monitoring host
- MySQL Event Scheduler/Federated Engine: Slave-ek eseten egesz jol lehet pakolgatni a 2 master kozott, de nem tudni mi tortenik akkor ha egy kieses utan visszajon a masik master.
- ClusterFS es MyISAM-only, external locking: Igazabol ezt alapbol elvetettem, mert eleg nagy hack.
Igazabol a masterek eseten Cassandra is jo volna, nem kotelezo a MySQL, de a reader node-oknak mindenkeppen MySQL-nek kell lennie.
Active-Passive megoldasban is gondolkodtam mar komprumisszumkent, de ott szinten nagyon oda kell figyelni applevel szinten:
- Ha ki akarom olvasni amit modositottam es meg nem ert el a reader node-hoz amit random valasztottam, akkor problemak lesznek
- Ha kiesik a writer node akkor a failover lassabb
Extrak:
- A slave-nek csak a masteren tarolt informacio egy resze kell, de ha jol tudom a slave-ben nincs olyan funkcio, hogy en csak ezt a bizonyos db-t, vagy tablat szeretnem kapni. Masternel tudom, hogy letezik ilyen, de ott sem lehet slavenkent megadni ezt az infot. (Vagy igen?)
- A slaveken lesznek tovabbi egyedi DB-k, amiket lokalisan hasznalnak csak, viszont backup celjabol szeretnem oket egy helyre replikalni. Tehat n db master -> 1 db slave. Megoldhato?
- 1431 megtekintés
Hozzászólások
levlistajuk tele van szethullott cluster reportokkal), kell kulon monitoring host
Lehet, hogy stabilabb lenne az, ha (hangosan gondolkodom) B (slave) figyelne A-t, es ha az kiesik, akkor master-re avanzsalna at...
ha jol tudom a slave-ben nincs olyan funkcio, hogy en csak ezt a bizonyos db-t, vagy tablat szeretnem kapni.
A mysql-nek meg lehet (meg kell) mondani, hogy mely db-ket akarod replikalni.
SPAMtelenül - MX spamszűrő szolgáltatás, ahogyan még sosem próbálta
- A hozzászóláshoz be kell jelentkezni
Extrakhoz:
- Slave filterezes: slave oldalon ezt meg tudod oldani, replicate-do-db, replicate-do-table, replicate-ignore-db, replicate-ignore-table.
- 1 slave-nek tobb masterje van: ezt csak hackelessel, hogy idonkent valtod a mastert. Replikacio backupnak eleve fail, mert user error ellen nem ved. Pl. az alkalmazas nyom veletlenul egy drop table-t, akkor ugyanugy le fogod replikalni. En menteseket csinalnek, plusz binlogokat mentenek offsite, vagy n darab blackhole engine-t hasznalo instance-t tartanek erre a celra 1 gepen.
Az aktiv-aktiv clustering miert fontos?
- A hozzászóláshoz be kell jelentkezni
Ebbe a postba reagalnek tobb kerdesetekre is:
Nem a replikacio a backup, hanem a replikalt/aggregalt tartalom kerulne dumpolasra, leegyszerusitve a backup modszert, de ez nem annyira fontos ha nem megy.
Slave filternel a teljes binlog kuldesre kerul csak ami nem kell azt eldobja?
Hogy mire kell:
Anelkul hogy reszletekbe bocsatkoznek, Linux/BSD rendszerek egyes allapotait tarolna a cluster. A felso szint lenne a management reteg, ide kerulnek a userek, konfiguraciok, taskok, a slave-ek pedig csak a sajat rendszerukre vonatkozo infot tarolnak le.
Jelenleg nem tudni hogy horizontalisan mennyire fog skalazodni a rendszer, viszont azt igy hirtelen nem tartottam idealisnak, hogy 1 ponton lehessen csak irni. A szerverek nem valoszinu, hogy azonos DC-ben vannak, de mindenkepp egy orszagnyi teruleten belul.
Update1:
Backupra ezt talaltam:
http://code.google.com/p/mysql-mmre/
- A hozzászóláshoz be kell jelentkezni
Slave filter: igen.
Ha egy orszagnyi teruleten belul vannak, akkor szerintem nem problema az 1 master irasa, mmm failover gyorsabban tortenik, mint gondolnad. A 2 master irasaval performanciat nem nyersz. Backupot ha innodb-d van, akkor en xtrabackup-pal csinalnam, nagyon bevalt nagyon nagy db-knel is.
- A hozzászóláshoz be kell jelentkezni
hasznos lenne, ha nem csak azt irnad le, hogy mit szeretnel, hanem mihez kell, hatha tudunk jobbat.
MMM tud aktiv aktivot, de ott sem szokas eles forgalmat egyszerre ket Masterre tolni a key clashing miatt.
ha viszont nincsenek egyedi kulcsaid a rendszerben, es nem zavar, ha esetleg azonos ertekkel letrejon ket rekord egyidoben, akkor akar mukodhet is.
autoincrementre be lehet allitani, hogy melyik node milyen lepeskozzel novelje az autoincrement erteket, ergo ha beallitod, akkor abbol sosem lesz utkozesed (tehat pl. 2 nodenal beallithatod, hogy egyik node csak paros, masik csak paratlan rekordokat oszt ki)
de ettol fuggetlenul az aktiv-aktiv felallas nagy szopas szokott lenni. :/
ha utkozes van,, vagy valami miatt szetesik a szinkron, akkor altalaban az a vege, hogy van ket felig rossz adatbazisod, mikozben megallt koztuk a replikacio, ami tovabb melyiti a tavolsagot a ketto kozott.
applikaciot nem lehet modositani?
en valami ilyesmit csinalnek:
A-B
/\
/ \
/ \
/ \
v v
C..X D..Y
hagyomanyos MMM active-active, csak az egyik kap direktbe forgalmat.
Tyrael
- A hozzászóláshoz be kell jelentkezni
subscribe
- A hozzászóláshoz be kell jelentkezni
AFAIK MySQL-re nincs stabil es feature-complete active-active shared-nothing clustering megoldas (ha jol ertem, neked ez kellene). Fejlesztenek par dolgot, de meg semmi sem eleg stabil.
Lasd itt: http://hup.hu/node/95211
- A hozzászóláshoz be kell jelentkezni