Citat:
zasto nije namenjen virtualnim serverima
tako je dizajniran. mysql cluster je vrlo specificno resenje.
Citat:
meni zaprato tj. tacno treba scenario broj 2
pretpostavio sam, zato sam ti i rekao da zaboravis mysql cluster. gledaj na mysql cluster kao na no-sql resenje .. posto on jeste ACID ... ali sto se performansi tice ima skoro sve probleme no-sql baza ... namely - relacije :D jedan ozbiljan join koji ce na mysql-u da traje ispod sekund ce na mysql clusteru da traje nekoliko minuta :(
e sad, sto se samog hpc/lb resenja tice, imas 2 nacina da to izvedes
1. master + nekoliko slave-ova. obavezno semisync replikacija izmedju mastera i slaveova (dakle 5.5), najbolje ako mozes unutar aplikacije da resis read/write razbijanje po serverima tako da master opterecujes samo sa pisanje a da na slave servere rasporedis citanje... mada mozes i da koristis proxy + rw lua script ... treba ti sistem za failback koji moze da se odradi i sa rh cluster managerom (koji sigurno poznajes bolje od mene posto sam ja vise trosio HB)
2. master-master lanac .. ovo je malo kompleksniji setup ... ista prica kao i [1], semisync replikacija, neki failover system kroz rh cluster manager ... ono sto je tu najveci problem je sto master-master lanac ume da pravi probleme .. obavezno mixed ili raw replikacija, sa statement ces da puknes ko zvecka ... i ako aplikacija nije vec unapred napravljena, mora da se obrati ozbiljna paznja na autoincrement ponasanje u takvom setapu .. najveci problem doduse nema veze sa mysql-om vec sa glupim developerima koji "ocekuju" da se neke stvari desavaju onako kako su "oni zamislili" (pa recimo ocekuju da je slog sa vecim ID-em uvek "noviji" od sloga sa manjim, sto u ovom slucaju ne mora da bude tacno) .. opet UUID prica koja generise unique id po serveru je super ali sa mysql-om ocajno radi (PK index kao veliki char ... bacanje resursa) ... ostaje "seljo" metoda, kako je ja zovem, a to je da PK bude ili kompozitni od ID+SERVER_ID (gde je server_id default = 1/2/3/4 zavisno od servera do servera) ili da je ID << 2 a 0 i 1 bit su setovani zavisno od servera ... naravno tu autoinc onda pada u vodu pa mora da se pravi drugaciji nacin popunjavanja id-a ...
nisam ti nesto previse pomogao, tj, ne verujem da sam ti rekao nesto novo ovde ... (osim sto ti u startu spasavam vreme koji bi mozda potrosio na mysql cluster da bi kasno uvideo da ti ne radi posao) ... sve se svodi na prilicno jednostavan setup mysql-a (upalis binlog, upalis log-slave-updates, setujes autoincrementstep i postavis set master i eto - sve radi) .. najkomplikovaniji deo sledi posle toga - a to je da kada odlucis kako ces da radis sa mysqlom (1 ili 2, ja licno smatram da je [1] bolje resenje ali zavisi od mnogo cega, nekad je [2] mnogo bolje) - da smislis kako ce tacno da ti radi failover u slucaju kada crknes 1 ili 2 ili 3 servera odjednom (kapiram da pricamo o 4 mysql noda, dakle ako riknu 4 nema failovera :D ) ... dakle u [1] moras da, ako je rikno master odradis unapredjenje jednog od slave servera u novi master (da prvo odlucis koji u odnosu na to gde se nalaze po pitanju stizanja replikacije - ako si koristio semisync kao sto rekoh onda je bar jedan stigao sve - njega treba da nadjes) i da prebacis tvoj app da sada to bude master a ostali da budu slave (puko prebacivanje cluster ip-a kao sto ide kod apache-a nece bas da odradi posao) ... i onda treba da vidis kako vracas failed node nazad u hpc grupu kada ga "opravis" a da ti to ne zezne nista (na primer prosli vikend smo imali klijenta koji je ostao bez 1 dana podataka zato sto radio "rucno" vracanje masine u hpc grupu i postavio je nju kao mastera te pregazio sve promene koje su se desile od trenutka kada je ta masina ispala iz grupe pa dok je nije vratio ... jeste inzenjer je dobio otkaz zato sto nije citao logove i procedure al ... firma je ostala bez ~20h podataka)
e sad, to je to uopsteno ... mislim da sam dovoljno jasno objasnio "koncept" sa dovoljno detalja da mozes da odlucis kako ces dalje ... za detalje kako to da napravis, tu sam, samo se prvo odluci sta pa kad zapnes, tu smo :D ... ako nesto pak nije jasno iz ove opste price .. reci
sto se tice ove cirkularne replikacije (master-master) .. nije los tekst .. ja vise volim da dajem link na ovaj:
http://onlamp.com/pub/a/onlamp...dvanced-mysql-replication.html .. mislim da je bolji, (a i pisao ga je kolega), no prica je ista ..
nekoliko bitnih stavki
- nemoj da koristis mysql binary iz RH-a, njihov binary nije ni za .!., baguje pod velikim opterecenjem (bagovi u libc-u) i generalno je golo .... koristi binary sa dev.mysql.com
- ja licno preferiram RH distro-e za linux (fedora za kod kuce, rhel za servere), i preferiram sve da instaliram iz rpm-ova, ali mysql na RH i dalje stavljam iz tar.gz u /usr/local/mysql .. RPM ovi rade (oni sa dev.mysql.com) ali ja i dalje preferiram /usr/local .. ( ako instaliras rpm-ove sa dev.mysql.com, prvo poskidas sve rh rpm-ovde sa --nodeps --force a onda instaliras one sa dev.mysql.com i sve radi kako treba i sav dependecies ostane ispostovan)
- obavezno koristi 5.5.x i semisync replikaciju