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
Citat:
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
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
Citat:
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
to nije samo kod nas, tako je skoro svuda...
Citat:
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)
:) 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
Citat:
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) :)
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 ...
Citat:
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
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