MySQL dual master problematika

Pozdrav,
imam neka pitanja vezana za MySQL Dual master replikacije:

1. Da li je neko koristio dual master nacin repliciranja i kakva su iskustva iz prakse (odrzavanje, podesavanja....)
2. Koliko je ovaj nacin pouzdan i "skup" (mislim na troskove ljudi i zivaca)?
3. Koji je optimalan nacin povezivanja vise lokacija (sirenjem trzista moramo da odgovorimo na zahtev da imamo vise dislociranih lokacija pod jednom bazom)?
4. Koliko pomaze klusterizacija i koliko ona kosta na cca 30 lokacija ?

Saveti i iskustva su u svakom slucaju dobrodosli.
Hvala puno

---

licno - da
klijenti - da, njih nekoliko stotina, iskustva - razna - ne znam sta te tacno zanima ..



zavisi od nekoliko faktora. MySQL replikacija ima standardni problem sa "nema checksuma replikacionog paketa" .. to znaci da ako ti je mreza losa mozes da imas razne "cudne" probleme. Ako ti je mreza dobra (na primer masine su u lan-u) nemas problem. Ako imas "nesigurni net" problem sa nedostatkom checksum-a resavas tako sto napravis da ti replikacija ide kroz ssl i tako ssl odradi deo sa checksumom. Svejedno je korisno da replikacija ide kroz ssl ako nije lan u pitanju (zbog sigurnosti podataka, je li)

sto se kruzne replikacije tice, nema nikakve "dodatne" probleme u odnosu na klasicnu replikaciju... to radi, radi u produkciji na vise stotina jako zeznutih mesta i radi lepo, bitno je samo da se ispostuju (zaobidju) svi poznati nedostatci mysql replikacije.



nemam pojma sta si ovde pitao a da ima veze sa mysql-om .... da ovo nije mysql forum odgovorio bih ti "internetom" .. ovako ..



"klasterizacija" je pojam koji ne znaci nista. klaster znaci "grupa"/"grozd" .. ako napises koji problem hoces da resis, da li je to HA/HR ili pricamo o performansama ili ... mozda i dobijes neki odgovor

---

Zanima me pouzdanost ovakvog nacina povezivanja, ali odgovor je u donjim redovima :)



Ovo sam citao u vise clanaka, slicna je konstatacija, samo sam se bojao da se ne upecam da nije to neka ppt hvala na racun kruzne replikacije




Da nekako detaljnije objasnim sta mi je na pameti:
1. Kod nas (u Srbiji ) je jako cenovno osetljivo trziste. Internet veze su prilicno nepouzdane, a gazde firmi ni cvonjka nece da uloze u infrastrukturu
2. Zahtevi korisnika po pitanju kvaliteta sistema su sve veci, i sve je veci broj dislociranih radnih jedinica koji nisu u LAN-u, pa shodno tome pokusavam da resim problem sa kruznim replikacijama (ovde prica sa novopecenim gazdama - koliko para toliko muzike ne pije vodu)
3. Iz toga razloga me zanimaju neka iskustva po pitanju dual master replikacija (mada sam odgovor u globalu dobio)
4. kada sam koristio ORACLE tehnologije, radili smo nesto sa klasterima pa je to izgledalo kao resenje sa velikim bazama (moj projekat je dosta manji). Pretpostavljam da MySQL u enterprise verziji pruza istu/slicnu funkcionalnost, pa me je zanimalo da li pomocu toga mogu da resim problem udaljenih lokacija (mozda lupam ovde, ali nisam preterano upucen) :)
5. Na netu sam citao o MySql replikacijama (konkretno dual master) i pitanje je da li ima neki detaljniji pdf sa objasnjenjima oko replikacije ( - znam da ima knjiga Advanced MySql Replication tehniques) i da li je dostupan za javnost


Hvala puno na odgovorima, ako imas neki savet reci, bice mi od koristi, a ja se nadam se da cu uspeti da se izgombam sa ovom problematikom

---

za "savet" .. nista pametnije od:
http://dev.mysql.com/doc/refma...-replication-multi-master.html
http://dev.mysql.com/tech-reso...dvanced-mysql-replication.html

i sve ostalo "standardno za replikaciju"

RBR je jos uvek nestabilan
MIXED je @%%@&@_#$
Obavezno teraj replikaciju kroz SSL ako nije LAN
upiti tipa "insert into ... select" ako je select bez "order by" ce ti zaklati replikaciju kad tad .. dakle, uvek order by to je osnovno klanje za SBR



pazi, svaki tekst koji nadjes da ga je pisao neko ko radi mysql support u mysql-u je 100% istinit .. dakle nama uopste nije u interesu da ti uzmes nesto pa da ti ne radi ...isto tako, od supporta dobijas uvek full info .. ako je bug - dobijes info da je bug, ako je nedostatak u dizajnu mysql servera - i to dobijes kao info .... tako da .. ako je dokument "tehnicki" to je to .. nema lazi nema prevare (zato nasi dokumenti pokazuju da je mysql mnogo losiji nego sto to pokazuju dokumenti o ostim mysql-u drugih firmi koje prodaju mysql podrsku :) ) ...

e sad .. sto se tice "komercijale" .. tj raznih najava "mysql moze ovo i ono i kuva kafu i vodi decu u setnju" to zaboravi .. to pisu marketing idioti ... mi im kazemo evo napravili smo proof of concept, zanimljiva ideja, raspitajte se dal ima "zahtev" za tako necim pa da zalegnemo da pravimo .. moze bude gotovo za godinu dve, oni uzmu i posle 3 dana objave kako "novi feature mysql-a .. od danas i u vasem bioskopu" ... kreteni !!!111


to nije samo kod nas, tako je skoro svuda...



:) da da .. koliko para ...

SSL obavezno
SSL proteras kroz TVOJ tunel
spustis MTU

kupis MEM i njime monitorujes sve servere .. ili napravis sam neku skriptu koja ce ti monitorovati stanje replikacije na svim masinama

obrati paznju da na "domacim" linkovima mozes cesto da ostanes bez linka .. ostajanje bez linka na duze vreme moze da izazove razne situacije koje moras da predvidis u svojoj aplikaciji inace merge nece biti moguc kasnije



ajd da preskocimo ovo posto nemam snage da objasnjavam vise da "klaster" kao rec stvarno ne znaci nista .... oracle ima klaster resenje za HA koje tebi ni za $#@ ne bi pomoglo... ti nemas problem sa HA ti imas problem sa geo replikacijom koja bi bilo pozeljno da je sinhrona ali to ne moze tako jednostavno .. mysql isto ima MySQL cluster, koji je opet HA/HR resenje .. i isto tako ti ne pomaze .. mozes da napravis sam klaster tako sto ces da stavis neki monitoring tool, neki cluster manager (npr HA) i mysql servere u cirkularnoj replikaciji i onda napises skripte sta ako ... mozes ...



ima knjiga :) .. za pdf .. kreni od dva linka s'vrha posta ..

sto se replikacije tice .. imas

SBR (statement based replication). SBR radi tako da mysql provali da li tvoj SQL koji si izvrsio menja nesto ili ne i ako menja
- zapamti trenutni timestamp
- zapamti taj sql

slave to povuce, setuje lokalni timestamp na procitanu vrednost i izvrsi tvoj sql

sta je problem ovde, ako imas upit "INSERT INTO t1 (a,b,c) SELECT a,b,c FROM t2 WHERE id > 123;" na masteru i na serveru ne mora da znaci da ce "SELECT a,b,c FROM t2 WHERE id > 123" vratiti rezultate istim redom pa ako uzmemo da t1 ima i auto_inc polje id moze se desiti da sada isti ID u tabeli t1 na slave-u i na masteru imaju razlicite vrednosti za a,b,c ...

sto je najgore, ovo ce proci "neopazeno" dok u nekom trenutku neki upit koji zavisi od tih podataka ne pukne .. pritom, u baze ce biti kompletni haos (na slave-u)...

dodatno postoje problemi sa konkurentnosti i slicno, moras da racunas da se na masteru statementi desavaju konkurentno ali se u binlog upisuju sekvencijalno i na slave-u izvrsavaju sekvencijalno u jednom threadu ... na masteru se oni upisuju redom kojim dolaze ali se ne izvrsavaju redom koji dolaze uvek zbog interlockinga threadova ..

i vrlo znacajan problem sa ne transackcionim tabelama je ... ako ti urads

delete from x;

i na pola tabele taj delete pukne .. na masteru imas pola tabele, na slaveu imas obrisanu celu tabelu !!!

sta je dobro kod SBR-a, ma koliko promena ima, SBR protok izmedju mastera i slave-a je vrlo mali

RBR (raw based replication) RBR radi tako sto se repliciraju samo izmene ... dakle mysql zapise "gde" se i "sta se" promenilo i tu informaciju salje slave-u ... to znaci da za

update t1 set a=10;

ako t1 ima 1m slogova mysql ce poslati 8m podataka na slave da replicira ovaj statement .. (za razliku SBR-a koji ce poslati nekoliko bajtova). Prednost je sto RBR nije osetljiv na sve ono na sta SBR jeste (lose napisane upite, redosled i slicno). dakle RBR ne izvrsava statement na slave-u vec samo primenjuje sve promene ...

sta je lose ... paaaa
1. nije jos dovoljno u production upotrebi tako da jos ima bagova koje treba isterati
2. mnoooogo veci protok podataka izmedju mastera i slave-a
3. ni on nema checksum :(

MIXED - ovo ne radi .. (tj kao radi .. ali je suvise bagovito trenutno) .. fora je da po defaultu binlog cuva SBR a ako mysql prepozna da je u pitanju SBR UNSAFE statement onda odradi RBR ... idealna stvar ali - bagovita jos uvek

---

Nemam sta dodati osim PUNO HVALA na jako korisnim informacijama.
Dosta stvari sam naslucivao, ali sada mi je mnogo jasnije.
Sto se tice cele price, nema druge, nego sesti pa probavati dok ne dodjemo na pouzdanost koja ce biti zadovoljavajuca.

Hvala jos jednom i svako dobro

---

nema na cemu .. nego ... zaboravh da spomenem .. RBR i MIXED postoje tek od 5.1 dakle to ne postoji u 5.0 i nizim verzijama

---

To sam pretpostavio. Mi koristimo MySQL 5.0.45 verziju i na RBR i MIXED nisam naletao do sada

---

ja znam da ljudi ne vole da diraju sta radi .. ali ... please .. 5.0.82 je aktuelan .. http://www.mysql.rs/category/new-release/ ne izbacujemo mi te nove verzije iz zabave :)

---

Upravo tako - If it's not broken - don't fix it' :)
Kad se jednom opeces...

ne bih oftopicario - hvala za fantastican post!

---

nije bas nesto sto bih ja vezao za mysql al ajde ... 5.1.30 na primer ima "table corruption" bug .. bez obzira da li si naleteo na njega ili ne "moras" da odradis upgrade ... 5.0.45 .. eno tamo drugi post sa 5 ekrana ispravljenih bagova, nema veze da li te neki od njih trenutno udara po dzepu, bolje da upgradeujes nego da te lupi pa da se pitas de ti je bekap !!

kao sto rekoh, mysql ne izbacuje binary kada promeni 3 reci u dokumentaciji ... svaki release ima "razlog" ... nije bas neophodno raditi upgrade svaki put kada izadje release .. ali ..

i dodatno, binary koji dolazi uz rpmolike distro-e nije ni za .!. .. binary koji pravi debian je debilan .. jos jedino novell pravi ok binary

dakle ... - koristite binary sa mysql sajta - ... ustedecete sebi mnooooooooogo muka...

---