Replikacija u praksi - sta (ne) raditi?

firma za koju radim je istovremeno i service provider i software vendor (koristi softver koji pisemo za sopstveno poslovanje + prodaje drugim firmama). ovo naglasavam jer software pisemo mi tako da mozemo da uticemo na dizajn - kako ga napravimo, tako nam je al' mozemo da ga pisemo kako nam volja, bez da zavisimo od nekoga.

deo firme koji koristi nas softver proizvodi prilicno podataka, sto u fajlovima, sto u bazi. oni su resili da pazare server(e) za bazu i fajlove. ovde pricamo samo o bazi.

posto gomila ljudi stalno nesto unosi i pretrazuje, firmi je bitan fail-over. zato su dosli na ideju (management) da razmotre MySQL sa replikacijom. realno, transakcije nisu toliko bitne (ako nesto propadne, moze da se ponovi) ali ih oni smatraju jako bitnima i hoce replikaciju baze u realnom vremenu.

sad dolazimo do pitanja:
- sta mi sve treba: valjda 2 servera + 2xLinux (mozda Oracle linux?) + 2 x MySQL enterprise, neki 1GB link izmedju servera. to sve ima da stoji u istoj zgradi (New York)
- koliko je realno ocekivati da real-time replikacija bude stvarno real-time?
- sta ako pukne master u smislu da rikne neki komad hardvera i server ode off-line na neodredjeno vreme? da li ce slave da preuzme njegovu ulogu automatski? sta se radi u ovakvoj situaciji?
- sta ako pukne slave? mogu li konekcije da preusmerim na master i da sistem nastavi da radi?
- sta kad bude trebalo da se radi upgrade aplikacije (baze)? da li upgrade-ujem master, brisem slave data pa startujem slave ispocetka? kakva su tu iskustva?
- da li particionisanjem tabela na aktivne i pasivne podatke mogu da "pomognem" replikaciji?

sta nisam pitao a treba da znam? kakva su Vasa iskustva?

ostalo: trenutno citam http://downloads.mysql.com/docs/refman-5.6-en.a4.pdf i drugu literaturu pa molim da ne gubite vreme na objasnjavanje pojmova

Potpis

Acta, non verba!

ako sam dobro shvatio, MIXED replikacija sa SSL-om izmedju nodova je optimalni kompromis performansi i pouzdanosti?

Potpis

Acta, non verba!

da



zavisi od kolicine update-a, ono sto je problem sa mysql replikacijom je sto je single threaded tako da ako ti napadnes mysql master sa 200 konekcija koje rade update na 200 tabela to ce na masteru da ide super brzo ali posto je slave single threaded (to ce tamo 5.6, 6.0 mozda da promene) na slave-u ce to da se izvrsi mnogo sporije nego na masteru tako da slave moze da ti kasni. Obzirom da tebi ne treba master-master vec master slave da bi odradio failover to nije preterano problematicno posto samo ako rsne master ti sacekas da slave izvrsi do kraja sve sto je radio i to je to. Obavezno upali semi-sinhronu replikaciju (5.5+) gde se transakcija zavrsava kada se na slave posalje data (ne cekas da se izvrsi ali sacekas da se posalje, to ne traje dugo na gbit netu). Dakle na masteru ce biti neznatno sporije transakcije ali imas 100% sigurnost da ako rsne master slave ima svu datu, eventualno ces morati da sacekas slave 5-10min da "sustigne" stanje mastera (obicno je to znacajno brze).



nema nista automatski, tebi rsne master, slave ce da izvrti njegov log do kraja i ti imas slave koji ima datu. Kako ces ti sada da prebacis taj slave da bude novi master zavisi od tebe. Ima brdo skripti na netu koje to rade, neke samostalno, neke u okviru hartbeat-a .. sve u svemu mysql trenutno ne nudi automatizovano resenje za failback - ti moras da ga napravis sam. Mi radimo na tome trenutno sa oracle linux timom ali nemam pojma dokle je to stiglo.



koje konekcije?



zavisi sta radis i koje su ti potrebe. Najcesce se
1. zaustavi aplikacija
2. odradi upgrade na masteru
3. napravi bekap mastera
4. taj bekap amstera iskoristi za jumpstart slave-a (rebildujes slave ispocetka)
5. start svega

mada ima milion stvari koje mozes da uradis zavisi od aplikacije, vremena, para, masina ...



particionisanje podataka je korisno, sta ti je aktivno i pasivno ne znam



nisi pitao da li postoje 3rd party resenja :D

zavisi sta ti treba realno ali pogledaj Percona XtraDB Cluster
Ono sto su pera i ekipa resili i ponudili dzabe a tebi moze da znaci je

- Synchronous replication
- Multi-master replication support
- Parallel replication
- Automatic node provisioning

Tako da mozes da napravis sinhronu replikaciju master master koja radi paralelno i da resis sve svoje probleme :D. Ne znam koliko je taj sistem stabilan, percona na zalost ne moze da priusti tu kolicinu testiranja koju mi mozemo, ali sta znam, da sam na tvom mestu - ja bi probao

Potpis

arhimed
http://www.mysql.rs/ | http://elco.crsndoo.com/

ako imas gbit mrezu i obe masine su u istoj zgradi, koristi RAW bez ssl-a

Potpis

arhimed
http://www.mysql.rs/ | http://elco.crsndoo.com/

Ako uzmes tj. platis MySQL enterprise dobijas i MySQL support (+ razne alatke) tako da nista ne treba da brines posto ce oni sve da podese :)

naravno, samo u tom slucaju moras da kupis minimum 2 subscription-a (ne mozes da radis replikaciju sa samo jednim serverom :D )

Potpis

arhimed
http://www.mysql.rs/ | http://elco.crsndoo.com/

Cudi me da Bogdan nije pomenuo, ali za deo sa pretragom mysql-proxy je odlicno resenje. Sve SELECT-ove mozes da gurnes na proxy, a onda da ih proxy rasporedjuje na master i slave podjednako, tako da i ako slave pukne sve automatski radi i dalje... samo sporije, naravno.

Ovo je dobro resenje ako ti je vecina upita SELECT, ako nije pitanje je koliko je dobro resenje imati master-slave. Ja bi onda razmislio o nekoj fallback varijanti, dva mastera, drbd + keepalive, ovo sam probao i radi skroz OK - mada mislim da su se nesto razisli u zadnje vreme.... Mana je sto jedna masina mora da moze da odradi sav posao...

Potpis

Please do not feed the Trolls!

Blasphemy? How can I blaspheme? I'm a god!'

nije toliko dobro resenje posto je proxy koliko toliko umro ... razni konektori imaju mogucnosti da rade load balansing...




drbd nije tako dobar kao sto deluje

Potpis

arhimed
http://www.mysql.rs/ | http://elco.crsndoo.com/

Moze pojasnjenje ovoga?

Potpis

Please do not feed the Trolls!

Blasphemy? How can I blaspheme? I'm a god!'

Izgleda da je prestao da se razvija...

http://pecl.php.net/package/mysqlnd_ms

vezano za "koliko toliko umro" pogledaj changelog i videces 2 release-a 2010 i jedan 2011 i to je to .. za 13 dana ce biti tacno godinu dana da nije izasla nova verzija... pa ti zakljuci sam dalje

vezano za "razni konektori imaju mogucnost da rade load balansing"
- connector\J ima load balansing odavno
- odbc koliko znam ne podrzava nista no ko to jos danas koristi :D
- .not konektor takodje podrzava load balansing (The name or network address of the instance of MySQL to which to connect. Multiple hosts can be specified separated by commas. This can be useful where multiple MySQL servers ...)
- OOo konektor - nikad u zivotu nisam probao, ne znam ni cemu sluzi
- php konektor ima brdo podrske za ovo od mysqlnd-ms koji radi neki bazicni split read i readwrite statementa preko ostalih ... ne secam se da li real_connect ume da uzme da host spisak ip adresa razdvojenih zarezom ili ne ali ne bi bio neki veliki problem da se to nasilji i ako je odgovor ne
- C api je naravno C api - tu je sve moguce :D, connector\C i connector\C++ takodje


Svi imaju i dodatnu foru da mogu da salju datu direktno MEM-u.

sve u svemu svaka bolja aplikacija ce koristiti neki pool, a onda u samom pool-u mozes da namestis da se vrti vise servera, to je sve prilicno jednostavno kada imas MASTER-MASTER, posebno ako je MASTER-MASTER sinhrono (sto sada moze samo sa perkoninim dodatkom, sa mysql originalom moze samo semi sinhrona replikacija MASTER-MASTER i sporija je od perkonine verzije zato sto je slave apply job na mysql-u single threaded dok perkona ima budz koji radi multithreaded slave apply tako da se binlog na slave-u izvrsi skoro isto brzo kao i na masteru .. 5.6 resava dosta problema tog tipa ali kada ce 5.6 biti GA ne znam)


nadam se da sam razjasnio

Potpis

arhimed
http://www.mysql.rs/ | http://elco.crsndoo.com/

moram da se vratim na ovu temu. karte su promešane, ulog povećan.

skorašnja epizoda sa uraganom je "oduvala" firmu na approx nedelju dana. taj zastoj je napravio poveliku štetu. da bi se to izbeglo u budućnosti, razmatra se mogućnost deploymenta sistema (par java-web-tomcat aplikacija + Solr-Lucene + mysql) na više mesta 4 lokacije širom sveta, u različitim vremenskim zonama.

od baze se traži master-master (zapravo, 4 x master) replikacija, tj, da svako piše u najbližu bazu, na pr.: kinezi u hong-kong, ameri u newjork, europljani u london, itd.

i još se traži da, ako bilo koji nod (mysql) ispadne, ostali mogu da preuzmu njegovu ulogu do oporavka.

razmatram i druge baze (oracle, mssql, pogledaću i db2)

pitanje za ovde: šta bitno u prethodnoj diskusiji nije rečeno a trebalo je, s obzirom da sada nije master-slave u jednom objektu nego master-master-master-master na sve 4 strane sveta?

Potpis

Acta, non verba!