Erfaringer med MySQL Cluster?

[deviant]

Jeg har en MySQL basert produksjonsløsning som jeg gjerne skulle hatt litt bedre ytelse på, og vurderer å gjøre noen forsøk med den nye cluster teknologien til MySQL.

 

I den anledning lurer jeg på om noen her har gjort seg erfaring med denne løsningen. Har man opplevd spesiell problematikk rundt konfigurasjon eller drift? Hvordan oppleves stabiliteten og ytelsen sammenlignet med konvensjonelle MySQL baser?

[sofagris]

Har man noe ytelsesmessige fordeler av å eventuellt kjøre mySQL i cluster ?

Trodde man satte servere i cluster først og fremst for oppetidens del. (Har ikke sett noe på mySQL cluster)

Normalt er det riktig diskoppsett som gir best økning i ytelse.

Vi kjører MS SQL i cluster på jobb, og da er dette kun for at databasen skal kunne feile over på en annen server.

[blackbrrd]

For databaser med en overvekt av leseoperasjoner kan nok clustering være en løsning.

 

Hvis dere har endel skriveoperasjoner så kan det hende at flaskehalsen ligger der og da vil ikke clustering hjelpe ettersom skriveoperasjoner logisk nok må utføres på alle maskinene...

 

Som noen gjorde meg obs på her på forumet, så er raid-5 totalt uegnet til databaser med mange skriveoperasjoner, da må man heller bruke raid 0+1 (eller 1+0). Den eneste ulempen er at dette krever flere disker. På den andre siden er ikke harddisker spesiellt dyre...

 

Evt andre løsninger er mer ram på databaseserveren, evt mer prosessorkraft. Så lenge man har for lite ram til caching vil ytelsen bli veldig mye bedre ved å øke mengden ram. Det er gjerne det som gir mest for penga (gjerne 10-100x høyere ytelse) hvis det er mangel på ram som er problemet.

 

Du kan gjerne si noe om eksisterende hardware og størrelse på databasen.

Endret 23. august 2005 av blackbrrd

[lotto-kim]

Du forteller ikke noe om hvilken clusterløsning du har sett på, men siden du nevner den nye cluster teknologien går jeg ut i fra at du mener ndb?

 

Ndb er jo en storage engine som ligger i minne (på samme måte som heap), dette gjør at serverne man skal bygge opp clusteret av trenger mye minne, noe som ofte er veldig kostbart.

 

Jeg satte opp et cluster med ndb, brukte 4 servere med flere nettverksgrensesnitt for å bygge opp et full-redudant mysql-cluster. Konfigrueringen gikk fint uten problemer, alt var oppe å kjørte. Begynte da å migrere over noen små og store databaser, alt så ut til å gå veldig bra, helt til jeg restartet en av serverne. En av databasene som var på rundt 3GB måtte da synkroniseres med det eksisterende clusteret. Dette var ikke gjort på et par miniutter selv med gigabitkort. Det tok opptil 8timer for å få denne oppigjen. Og i de fleste tilfellene var det umulig å få inn igjen den servern som gikk ned. Det jeg måtte gjøre var å reinstallere mysql. Jeg kjørte også noen tester mot en av tabellene, siden alt lå i minnet regnet jeg med at spørringen ville gå raskt, her tok jeg feil, det viste seg at det var mye tregere en myisam. En av de største problemene var at ndb ikke hadde oversikt over radene i tabellen, så når man kjørte en spørring med count måtte mysql telle gjennom alle radene. Myisam har oversikt over alle radene så man slipper dette probleme med denne tabelltypen.

Min konklusjon var at ndb ikke er brukbart å bruke til et cluster grunnet dårlig ytelse og ustabilitet, alt virket som en tidlig aplha-verson.

 

Du har noen andre muligheter også, replikere databasene over til flere servere hvor du kjører skrive spørringer mot en server, og lese spørringer mot en annen. Problemet med denne løsningen er at databasene ikke er like på alle serverne til enhver tid, dette gjør jo da at man kan risikere å lese feil data i fra databasen. Systemer som feks ez-publish vil da ikke fungere på denne løsningen.

 

En felles lagringsenhet for alle serverne fungerer bra, som feks et san eller iscsi, men vil bli en kostbar løsning.

 

Jeg har nå selv sett på en løsning i fra emic networks, dette var en meget bra løsning, her trenger man minimum 3 servere for å få et full-redudant mysql-cluster med støtte for myisam, innodb og heap. Alle data vil være synkronisert til enhver tid på alle serverne og ytelsen er god.

[roac]

Som noen gjorde meg obs på her på forumet, så er raid-5 totalt uegnet til databaser med mange skriveoperasjoner, da må man heller bruke raid 0+1 (eller 1+0). Den eneste ulempen er at dette krever flere disker. På den andre siden er ikke harddisker spesiellt dyre...

Når du likevel bruker penger på disker til speil og striping av data, så sparer du ikke og bruker RAID 0+1. Ryker en disk der så sitter du igjen med et stripesett, mot RAID 1+0 hvor du sitter igjen med et stripesett som består av en enkelt disk og resten speil. Det er store forskjeller i grad av feiltoleranse her.

[blackbrrd]

Nå er det sikkert bare jeg som er teit, men det du mener er sikkert:

 

 

3 disker i raid 0

3 disker i raid 0

 

2 raid 0 arrays i raid 1

 

Eller har jeg misforstått?

[roac]

Nå er det sikkert bare jeg som er teit, men det du mener er sikkert:

 

 

3 disker i raid 0

3 disker i raid 0

 

2 raid 0 arrays i raid 1

 

Eller har jeg misforstått?

Du har ikke misforstått i det hele tatt

[blackbrrd]

Når jeg tenker meg om... ytelsen blir da den samme om du kjører

 

2 disker i raid 1

2 disker i raid 1

2 disker i raid 1

3 raid 1 arrays i raid 0???

 

og feiltoleransen blir da også bedre med 3 raid 1 og disse tre i raid 0?

http://www.ofb.net/~jheiss/raid10/ sier jo at det er matematisk riktig.

 

Så, da er det bare et spørsmål om ytelse...

Endret 25. august 2005 av blackbrrd

[roac]

blackbrrd: Det var jo nettopp det jeg poengterte: Forskjellen mellom RAID 10 (1+0) og RAID 01 (0+1)

[blackbrrd]

Vel, ting tar tid, og det ene svaret ditt tolket jeg feil

 

Det siste jeg nevnte er raid 10.... håper jeg.. hehehe

 

Har ikke hørt så mye om raid 01, så antar at det er den beste løsningen, raid 10 som er vanligst.. :o)

[deviant]

Har man noe ytelsesmessige fordeler av å eventuellt kjøre mySQL i cluster ?

Trodde man satte servere i cluster først og fremst for oppetidens del. (Har ikke sett noe på mySQL cluster)

Normalt er det riktig diskoppsett som gir best økning i ytelse.

Vi kjører MS SQL i cluster på jobb, og da er dette kun for at databasen skal kunne feile over på en annen server.

Det finnes ulike former for clustering.

 

Noen kjører typisk bare på èn node om gangen, og har èn eller flere stående passive, klare til å ta over dersom hovednoden feiler.

 

I andre såkalte parallell-clustere er det flere aktive noder som samarbeider om å løse de samme oppgavene. I slike løsninger deler nodene ofte på et felles diskområde, og baserer seg på hurtig interconnect.

 

MySQL Cluster skal være et fullverdig parallell-cluster.

[deviant]

For databaser med en overvekt av leseoperasjoner kan nok clustering være en løsning.

 

Hvis dere har endel skriveoperasjoner så kan det hende at flaskehalsen ligger der og da vil ikke clustering hjelpe ettersom skriveoperasjoner logisk nok må utføres på alle maskinene...

 

Som noen gjorde meg obs på her på forumet, så er raid-5 totalt uegnet til databaser med mange skriveoperasjoner, da må man  heller bruke raid 0+1 (eller 1+0). Den eneste ulempen er at dette krever flere disker. På den andre siden er ikke harddisker spesiellt dyre...

 

Evt andre løsninger er mer ram på databaseserveren, evt mer prosessorkraft. Så lenge man har for lite ram til caching vil ytelsen bli veldig mye bedre ved å øke mengden ram. Det er gjerne det som gir mest for penga (gjerne 10-100x høyere ytelse) hvis det er mangel på ram som er problemet.

 

Du kan gjerne si noe om eksisterende hardware og størrelse på databasen.

 

Moderne parallell-clustere gir betydelig bedret ytelse både på lese og skriveoperasjoner. Vanligvis gjøres det ved hjelp av delt lagringsplass (kun èn fysisk database) og sykronisert cache ved hjelp av en hurtig interconnect eller buss-forlengelse. På den måten trenger man bare å gjøre skriveoperasjonen èn gang, og det kan gjøres på en vilkårlig node. For eksempel benytter Oracle Real Application Cluster slik teknologi.

 

MySQL Cluster løser utfordringene på en helt annen måte, blant annet ved å holde hele databasen i minnet til enhver tid, og benytte egne "storage noder" for å sikre de utførte endringene til disk. Dette er noe av grunnen til at jeg er usikker på praktis anvendelse, og lurer på om noen har erfaringer å dele. Tidligere har man bare sett slike løsninger i realtime-databaser hos telecom-leverandører m.m.

 

Forøvrig er jeg helt enig i at RAID 5 og lignende teknologier er uegnet for databaser.

 

Databasen er i dag på ca 8 GB, vekstraten er ca 2 GB per år.

De største tabellene inneholder omlag 10 millioner rader.

Basen har et gjevnt trykk av lese og skriveoprasjoner, med en stor andel updates.

 

Produksjonen kjører i dag på

 

2 x Pentium Xeon 3,4 Ghz 1 MB

4 GB DDR PC3200 ECC

10 x 36 GB SCSI U320 15k

RedHat Enterprise Linux 3 ES x64

 

I tillegg har jeg en mindre maskin som replikert slave. Den brukes til hot-backup, og enkelte lese-jobber som eksport til xml indeks og diverse data-mining.

 

2 x Pentium Xeon 3,06 512KB

4 GB DDR PC3200 ECC

2 x 146 GB SCSI U320 15k

RedHat Enterprise Linux 3 ES x86

 

Slik løsningen er i dag er det meningen at denne slaven skal kunne ta over produksjonen i kortere perioder om nødvendig.

Endret 26. august 2005 av deviant

[deviant]

Du forteller ikke noe om hvilken clusterløsning du har sett på, men siden du nevner den nye cluster teknologien går jeg ut i fra at du mener ndb?

 

MySQL Cluster er et selvstendig produkt som baserer seg på ndb, ja. Det er mulig jeg tar feil, men jeg trodde dette var den eneste cluster teknologien MySQL er i besittelse av.

 

Ndb er jo en storage engine som ligger i minne (på samme måte som heap), dette gjør at serverne man skal bygge opp clusteret av trenger mye minne, noe som ofte er veldig kostbart.

 

Selvsagt. Heldigvis er kostnaden for minne langt lavere enn for konkurrerende cluster-teknologi. Oracle Real Application Cluster koster gjerne en liten million for 4 CPU. I tillegg krever slike tradisjonelle clusterløsninger delt lagring, som også er svært kostbart.

 

Jeg satte opp et cluster med ndb, brukte 4 servere med flere nettverksgrensesnitt for å bygge opp et full-redudant mysql-cluster. Konfigrueringen gikk fint uten problemer, alt var oppe å kjørte. Begynte da å migrere over noen små og store databaser, alt så ut til å gå veldig bra, helt til jeg restartet en av serverne. En av databasene som var på rundt 3GB måtte da synkroniseres med det eksisterende clusteret. Dette var ikke gjort på et par miniutter selv med gigabitkort. Det tok opptil 8timer for å få denne oppigjen. Og i de fleste tilfellene var det umulig å få inn igjen den servern som gikk ned. Det jeg måtte gjøre var å reinstallere mysql. Jeg kjørte også noen tester mot en av tabellene, siden alt lå i minnet regnet jeg med at spørringen ville gå raskt, her tok jeg feil, det viste seg at det var mye tregere en myisam. En av de største problemene var at ndb ikke hadde oversikt over radene i tabellen, så når man kjørte en spørring med count måtte mysql telle gjennom alle radene. Myisam har oversikt over alle radene så man slipper dette probleme med denne tabelltypen.

Min konklusjon var at ndb ikke er brukbart å bruke til et cluster grunnet dårlig ytelse og ustabilitet, alt virket som en tidlig aplha-verson.

 

Dette er svært verdifull informasjon. Jeg ser for meg at synkroniseringsproblemet vil være enda større i min base som lett vil kunne inneholde 10-15 GB med data.

 

Jeg har svært mye count spørringer mot basen, og ser hvordan dette vil kunne påvirke ytelsen betraktelig.

 

At denne teknologien fra MySQL ikke er moden for vanlig produksjon enda er noe jeg har hatt mistanke om. Takk for verdifull erfaring.

 

Du har noen andre muligheter også, replikere databasene over til flere servere hvor du kjører skrive spørringer mot en server, og lese spørringer mot en annen. Problemet med denne løsningen er at databasene ikke er like på alle serverne til enhver tid, dette gjør jo da at man kan risikere å lese feil data i fra databasen. Systemer som feks ez-publish vil da ikke fungere på denne løsningen.

 

Jeg er redd det er for mye skriveroperasjoner, spesielt updates, til at denne løsningen vil være effektiv nok. Dessuten er jeg bekymret over at replikeringen ikke er rask nok til parallelle spørringer. Dette vil kunne forstyrre en del funskjonalitet i applikasjonen.

 

Derimot har jeg tro på å dele opp dataene i flere individuelle databaser. Tabeller med mye updates kan f.eks. kjøre på en egen base som er optimalisert for denne typen operasjoner. Utfordringen ligger i å kartlegge relasjonene, finne ut hvilken funskjonalitet som kan splittes opp, og å skrive om applikasjonen til å støtte en slik løsning.

 

En felles lagringsenhet for alle serverne fungerer bra, som feks et san eller iscsi, men vil bli en kostbar løsning.

 

Som du sier er dette en kostbar løsning. På Linux har jeg også hatt en del utfordringer med kompleksiteten i delt lagring, skjønt disse er overkommelige. Dermed består jobben i å finne passende teknologi som støtter flere MySQL instanser mot samme database.

 

Jeg har nå selv sett på en løsning i fra emic networks, dette var en meget bra løsning, her trenger man minimum 3 servere for å få et full-redudant mysql-cluster med støtte for myisam, innodb og heap. Alle data vil være synkronisert til enhver tid på alle serverne og ytelsen er god.

 

Denne høres det ut som om jeg skal se nærmere på. Takk for tipset!

Endret 26. august 2005 av deviant