Srodne teme
Navigacija
Lista poslednjih: 16, 32, 64, 128 poruka.

MySQL - best practice

[es] :: MySQL :: MySQL - best practice

Strane: 1 2

[ Pregleda: 5041 | Odgovora: 23 ] > FB > Twit

Postavi temu Odgovori

Autor

Pretraga teme: Traži
Markiranje Štampanje RSS

cveticmilan
System administrator
Beograd

Član broj: 105312
Poruke: 161
*.nb.rs.

Sajt: www.nb.rs


+8 Profil

icon Re: MySQL - best practice02.04.2011. u 09:55 - pre 109 meseci
jos uvek se zezam sa ovim problemom. Mislim, ima stvarno dosta nacina da se resi ali posto je u pitanju spec. rad i detaljno istrazivanje zasto da ne probam sve kombinacije :)

Dakle, nebitno da li cu ici master/master ili master/slave hteo bi da odradim Automatic Fail-Over na ovaj nacin

http://onlamp.com/pub/a/onlamp...-mysql-replication.html?page=4

ali FEDERATED Storage Engine nije po defaultu instaliran (a neophodan je) sto znaci da moram sve iz pocetka i to iz source pa onda da naglasim u instalaciji , zar ne ?

Zasto takva politika ? Mislim jel ima neki poseban razlog ili sta ?


 
Odgovor na temu

bogdan.kecman
Bogdan Kecman
"specialist"
Oracle
srbistan

Član broj: 201406
Poruke: 15206
*.31.24.217.adsl2.beograd.com.

Sajt: mysql.rs


+2314 Profil

icon Re: MySQL - best practice02.04.2011. u 10:12 - pre 109 meseci
politika za sta? za federated? spominjao sam vec par puta .. federated je se koji se ne razvija uopste, napravljen je kao proof of concept i nikada nije osmisljen do kraja, radi pateticno, ima ozbiljne bagove koji koraptuju datu ... dakle -> neupotrebljivo ... covek koji ga je pisao (kao proof of concept a ne kao proizvod) vise nije u mysql/sun/oracle i krenuo je da pravi federated.x koji je kao zamisljen kao "proizvod" (dakle postavljen kako treba...) ali koliko sam ja ispratio 2 godine nije napisana ni linija koda ... tako da .. isto je kao i obican federated - neupotrebljiv...

politika je takva da klijentima nije dovoljno reci "ljudi to ne radi, nemojte da placete sutra kada ostanete bes zvih podataka na svim serverima" posto su oni u fazonu "ali evo meni radi vec 3 meseca bez greske" a onda placu i kukaju i pljuju i kunu kada ostanu bez podataka i onda im je mysql kriv i onda je mysql igracka i neozbiljna baza i sve ostalo ... e zato su ga izbacili iz oficijalnog release-a pa ti ako bas oces da ga ukompajliraj, nemoj posle da bude "nismo ti rekli da to ne radi"...

sto se tice automatskog fail-overa, reci cu ti samo jednu stvar, ne moj da verujes nijednom tekstu .. kada napravis i mislis da to radi - ISTESTIRAJ!!! dakle cupaj iz struje dok tamo neke klijentskje aplikacije tuku po podacima (i insert i select i update i delete) .. i gledaj dal to radi ili ne ... u 90% instalacija sa automatskim failoverom u jednom trenutku "nestanu podaci" (u 80% slucajeva pri vracanju originalnog mastera i u 20% slucajeva tokom inicijalnog failovera). dakle - sta god radis - probaj dal fizicki radi, ne da li radi "teoretski". dakle iscupaj master iz struje i vidi sta se desilo sa sistemom.

dalje, obrati paznju na semi sinhronu replikaciju sa 5.5
 
Odgovor na temu

cveticmilan
System administrator
Beograd

Član broj: 105312
Poruke: 161
*.nb.rs.

Sajt: www.nb.rs


+8 Profil

icon Re: MySQL - best practice02.04.2011. u 10:32 - pre 109 meseci
hvala opet na odgovoru i stvarno mi skracujes muke jer sam se inace cele nedelje zezao i evo dodjoh sobotom na posao da budzim. Pa mislim, meni nekako jeste navlaka i zaista mi zvuci kao dobar koncept ali posto samo zvuci dobro odustajem.
 
Odgovor na temu

bogdan.kecman
Bogdan Kecman
"specialist"
Oracle
srbistan

Član broj: 201406
Poruke: 15206
*.31.24.217.adsl2.beograd.com.

Sajt: mysql.rs


+2314 Profil

icon Re: MySQL - best practice02.04.2011. u 10:59 - pre 109 meseci
za federated - zamisao je extra!! lik koji je zamislio federated je seo i nacukao za metar dana "pokaznu vezbu" iliti "proof of concept" sa varijantom - evo raja vidite kako to moze da se napravi i kako bi moglo da radi .. aj sad odlucite da li hocete da ulozimo vreme i rad da to napravimo "da valja" ... onda su ovi iz marketinga doculi da postoji federated i krenuli da pricaju okolo o njemu kao o devetom svetskom cudu i kao i u vecini firmi totalno nas zakopali sa istim ... (posto marketingu ne vredi pricati ... ima odlican dilbert na tu temu ali ne umem da ga nadjem)

dakle problem sa federated je sto ne radi .. to je ceo cim .. dakle ima ozbiljne probleme i moze da napravi ozbiljno sran*e na serveru .. a ne verujem bas da su ti ti podaci sa kojima radis toliko nebitni da ako padne korupcija uvek imas validan bekap i mozes da podneses downtime .. mi imamo 2 klijenta koji koriste federated na produkciji .. malo malo pa se nesto smori, nestane pobrljavi ... ali njima nije problem, imaju cudo servera i rade sa skoro read only podacima tako da uvek imaju svezi bekap (podaci se transportuju sa jednog sistema na drugi sistem sa bekap/restore i onda se koriste na ovom drugom sistemyu kao read only dok ne dodje novi dump koji treba da se restoruje na tom sistemu) ... i njih briga kad se nesto zadangira, samo ponovo odrade restore i teraju dalje ... ali nam redovno salju izvestaje kada se nesto zadangira, kako se zadangiralo i sta sve nije radilo kako treba ...


 
Odgovor na temu

[es] :: MySQL :: MySQL - best practice

Strane: 1 2

[ Pregleda: 5041 | Odgovora: 23 ] > FB > Twit

Postavi temu Odgovori

Navigacija
Lista poslednjih: 16, 32, 64, 128 poruka.