MySQL Cluster (Community Edition)

[TheNephilim]

Hallo allemaal!

Mijn oog viel onlangs op MySQL Cluster en ik heb er toch nog wat vragen over, hieronder een beschrijving van de situatie, vragen en problemen.

Het gaat om een webapplicatie gescript in PHP, we maken gebruik van een MySQL database. We hebben eerder al problemen gehad met schaalbaarheid en niet alle oplossingen vielen binnen het budget.

Huidige situatie:

• Loadbalancer (LM2500 van Kemp); verdeeld aanvragen over 2 webservers.
• N1 & N2 (webservers); maken via een switch verbinding naar MySQL server
• DB (databaseserver, MySQL); handelt aanvragen van N1 & N2 af

Nieuwe situatie:

• Loadbalancer; zelfde rol als voorheen
• N1&N2/DB1&DB2; vervullen nu rol als webserver & mysql storage node
• DB3; is nu cluster manager

Vragen:

• Kan in PHP alles hetzelfde laten? Eventueel mysqli-connecter ipv mysql is geen probleem.
• Verbinding van een IP/Hostname naar een lokale socket (verbinden met locale storage node)
• Is er een PhpMyadmin versie waarmee ik dit kan managen?

Hiermee heb ik denk ik het gros van mijn vragen wel gedekt. Ik hoop hiermee iets meer te weten te komen over het MySQL cluster en de implementatie daarvan in een bestaande webomgeving. Misschien zie ik dingen over het hoofd.

[LauPro]

Ik heb nog weinig echt goede open source tools gezien om dit te managen. Er zijn wel wat wrapper scripts maar dat is ook niet echt handig.

Wil je gebruik maken van MySQL cluster met een slave/master? Want distributed master is lastig ivm object id's.

[TheNephilim]

De bedoeling is gebruik maken van NDB (in memory). High performance is belangrijker dan de redundantie.

Mijn idee was dat het MySQL cluster gewoon een opzichzelf staant iets is. Dus een grote DB server, maar vanaf buitenaf gewoon 1 DB. Dus geen wijzigingen wat betreft connecties etc.

Als ik met (bijv.) 1 master en 3 slaves ga werken, moet ik schrijven naar de master en lezen vanaf de slaves. Dan betekend dat ik mijn applicaties aan moet passen naar een schrijf en lees laag en 2 verbindingen. Of mysql proxy, die kan dit ook maar dit levert weer latency op.

Maar of ik hiervoor bij MySQL cluster aan het juiste adres bent weet ik nog niet

[LauPro]

Oké dan begrijp ik je opstelling. Met de MySQL-slaves is het gebruikelijk om een soort van round robin te doen op deze slaves, en alleen de Master aan te spreken voor de writes. Volgens mij was hier al een soort van proxy voor. Moet er wel bij kanttekenen dat tegenwoordig met MySQL memcaches het idee van slaves eigenlijk niet zoveel zin heeft tenzij je echt idioot veel reads hebt (bijv. wikipedia oid).

Meestal is het handiger om 1 grote main MySQL db te houden en een slave back-up. En daar dan omheen nog wat slaves die je kan raadplegen en je read-load een beetje te verdelen. Maar ook met caching in je app kan je eigenlijk wel voorkomen dat deze queries bij de db uitkomen.

Dus misschien ben je meer op zoek naar een goede cachingstrategie in je web frontend.

[TheNephilim]

Eigenlijk wilde ik alle writes en reads naar 1 zelfde IP/hostname doen. Dus lokaal zoals ik al zei. Als dit niet kan moeten we een boel applicaties herschrijven en dat is geen optie. Dus het cluster moet vanaf buitenaf gewoon 1 DB en 1 server zijn eigenlijk. Van binnen bestaat die uit 2 nodes en 1 manager. Ik begreep dat die servers allemaal gewoon hun eigen werk doen. Dus dat ik gewoon kan schrijven naar DB1 en ook lezen en dat ie zelf uitzoekt waar ie het vandaan haalt.

Maar als ik je zo begrijp is dat dus niet mogelijk? We gebruiken wel een db-class dus is het mogelijk om alles wat begint met INSERT, UPDATE, etc op een andere verbinding te gooien misschien. Alleen lijkt het me te duur om 2 verbindingen te openen.

Cache is voor ons geen optie. Het gaat namelijk om een spel (onder andere), waar het niet mogelijk is om out-dated content te serveren. We doen 50% SELECTs en de rest is onderverdeeld in verschillende writes.

[LauPro]

Dan ben je dus eigenlijk op zoek naar de genoemde proxy die read-query naar de slaves stuurt en write queries naar de master.

[GlowMouse]

Ik zou me eerst inlezen in NDB voor je vanalles verzint. NDB is alleen handig in enkele situaties, en ik denk dat je er flink op achteruit zult gaan. Ook nu je vraagt of alles met pma te managen valt, zou ik eerst maar flink experimenteren op een eigen locatie.

Gelet op een eerdere uitspraak van je ("Het optimaliseren van de database is overigens niet aan de orde, de applicatie die erop draait is er te groot, log en te slecht gescript voor.") lijkt het me meer voor de hand liggend om toch de database te optimaliseren. Als er niets geoptimaliseerd is, kun je vaak met een paar klikjes de boel flink versnellen.

[cariolive23]

Bernardo schreef op vrijdag 19 maart 2010 @ 19:51:
Het gaat om een webapplicatie gescript in PHP, we maken gebruik van een MySQL database. We hebben eerder al problemen gehad met schaalbaarheid en niet alle oplossingen vielen binnen het budget.

Over wat voor database, toepassing en workload hebben we het eigenlijk? 99 van de 100 keren dat er problemen zijn met performance, komt dat doordat men daar (min of meer) voor heeft gekozen. Daar kun je nog zoveel hardware tegen aan gooien, je zult zelden een redelijke performance krijgen.

1. Hoe groot is de database (in GB's)?
2. Hoeveel tabellen en indexen zijn er in deze database?
3. Hoeveel concurrent users heb je op de database zitten (dus EXACT gelijktijdig queries uitvoeren)?
4. Hoe complex zijn jouw queries? Geef als voorbeeld eens een zeer complexe query
5. Hoeveel queries voeren jouw scripts per page-view uit en hoe complex zijn deze queries? (gebruikspatroon)
6. Heb je al met EXPLAIN de langzaamste queries geanalyseerd en geoptimaliseerd? Dit is onmisbaar, moet stap 1 zijn
7. Welke hardware gebruik je voor de database?
8. Welke versie van MySQL gebruik je? Pas sinds versie 5.1.x schaalt MySQL enigzins, zie deze bv. test van Tweakers (volgens mij moet er ook ergens een 5.1 test zijn, kan hem even niet vinden)

[ Voor 5% gewijzigd door cariolive23 op 21-03-2010 08:55 . Reden: EXPLAIN !!!!!! Hoe kon ik het vergeten te noemen... 8)7 ]

[TheNephilim]

@LauPro: Dat zou misschien een optie wezen, maar geeft dat niet veel extra latency?

@GlowMouse: Dat klopt, alleen draait die applicatie op een ander web-cluster en hebben we inmiddels dat redelijk onder controle. Load van die DB is gemiddeld 3 nu, dus dat is in orde. Het cluster waar ik het nu over heb is een nieuwer web-cluster met nog geen blijvende database oplossing. We maken nu gebruik van enkele losse servers en willen graag 1 grote server/cluster/etc. Ik lees verder inderdaad vaak dat NDB meer voor High Availability is dan voor High Performance, toch zie je ook berichten over HP mogelijkheden.

@cariolive23: De DB stelt nu nog niet veel voor, maar we willen wel een schaalbaar DB model hebben.

1. Enkele MB's, de applicatie is nog niet online maar slechts in Alpha fase. Het is versie 3 van een eerder project, die heeft een DB van ongeveer 10GB, deze gaat wel groter worden.
2. ~100 tabellen op dit moment, worden er denk ik ongeveer 180.
3. We hopen rond de 1500 gebruikers te kunnen bedienen tegelijker tijd.
4. De queries zijn niet super complex maar wel tot 20 joins vooral INNER en LEFT overigens.
5. Query voor gebruikers informatie, speelkarakter, console en updates/writes voor het uitvoeren van handelingen. Ga vanuit dat 50% read is en 50% write (~30 UPDATE en ~20% INSERT).
6. Het project moet eerst in Beta fase zijn om echt de queries te optimaliseren, anders loop je jezelf voor de voeten. Maar ik kan zeggen dat er geen extreem brakke queries in zitten. Performance is prima, al komt dat doordat het nog niet online is.
7. Dit is nog een zeer simpele dual Opteron 270 met 8GB geheugen.
8. 5.0.77

Verder wil ik nog even duidelijk maken dat het hier gaat om een nieuw project. We willen nu alvast weten hoe we goed kunnen schalen, zodat we als het straks druk word, we (bijv.) een servertje bijplakken en klaar. Misschien nog overstappen naar PHP 5.3 om gebruik te kunnen maken van MySQLi. Onder 5.3 ondersteund die nog geen persitente connecties en die hebben we wel nodig.


Het type applicatie is een online spel (text-based). Dit zorgt ervoor dat je eigenlijk niet kunt cachen (webserverside), want je informatie is snel outdated. Verder veel writes op de database omdat gebruikers constant acties uit kunnen voeren. Het is geen 'lui op je gat zitten' spel zoals Travian.

Ik hoop dat jullie wat met deze informatie kunnen. Ik kan helaas niet teveel zeggen, dit zou misschien het thema van het spel laten zien.

[GlowMouse]

Bernardo schreef op zondag 21 maart 2010 @ 12:34:
Verder wil ik nog even duidelijk maken dat het hier gaat om een nieuw project. We willen nu alvast weten hoe we goed kunnen schalen, zodat we als het straks druk word, we (bijv.) een servertje bijplakken en klaar. Misschien nog overstappen naar PHP 5.3 om gebruik te kunnen maken van MySQLi. Onder 5.3 ondersteunt die nog geen persitente connecties en die hebben we wel nodig.

Hoe weet je nu al dat je die zeker nodig hebt? Als je je inleest, zie je dat je die juist wilt vermijden in vrijwel alle gevallen.

Snel outdated betekent niet dat je niks kunt cachen. Als je iets kunt cachen voor 100 requests dan is dat toch een verbetering.

Als je een database wilt laten schalen, dan kom je al gauw terecht bij replicatie met een aantal slaves. Je moet je afvragen of jij de problemen op kunt lossen die kunnen optreden bij zo'n infrastructuur. Ik Zou me daarom toch richten op optimalisaties.

[TheNephilim]

GlowMouse schreef op zondag 21 maart 2010 @ 12:40:
[...]

Hoe weet je nu al dat je die zeker nodig hebt? Als je je inleest, zie je dat je die juist wilt vermijden in vrijwel alle gevallen.
Bedoel je PHP 5.3 of persistente connecties?

Snel outdated betekent niet dat je niks kunt cachen. Als je iets kunt cachen voor 100 requests dan is dat toch een verbetering.
Dat is waar, maar de meeste cache-progs zijn vrij log. Heb je een tip voor een cache systeem die zich niet verslikt en 'oude' content weergeeft?

Als je een database wilt laten schalen, dan kom je al gauw terecht bij replicatie met een aantal slaves. Je moet je afvragen of jij de problemen op kunt lossen die kunnen optreden bij zo'n infrastructuur. Ik Zou me daarom toch richten op optimalisaties.
Klopt, maar op een gegeven moment ga je toch het probleem krijgen dat 1 server niet meer genoeg is. Al heb je gelijk en moeten we eerst optimaliseren voordat we naar de hardware kijken. Ik wilde toch even weten wat de opties zijn en hoe ze toepasbaar zijn.

[cariolive23]

MySQL 5.0? Die wordt niet meer ondersteund en schaalt bij mijn weten slecht op x86-omgevingen. Wanneer jij een database hebt van in totaal 10GB en je hebt 8GB RAM, dan zullen de belangrijkste delen van jouw database in RAM leven, dat moet dus razendsnel zijn. Mits je de juiste configuratie gebruikt.

Gebruik je overigens innoDB of MyISAM? MyISAM is een drama met concurrency, lockt de tabellen wanneer er moet worden geschreven in een tabel.

1500 gelijktijdige gebruikers zijn nog geen 1500 concurrent users op jouw database die gelijktijdige queries aan het uitvoeren zijn. Dus nogmaals, hoeveel concurrent users moeten er op jouw database kunnen? En wat gaan deze users uitspoken? 2 selects, een update en een insert, of zijn het hele scheepsladingen vol met queries die per keer per user naar de database worden gestuurd?

Ik zat laatst nog met "een langzame database" die per webpagina zo'n 2000 select's voor zijn kiezen kreeg. Iedere query minder dan 1ms, maar met 2000 stuks, is het natuurlijk tergend langzaam. Teruggebracht tot een handjevol slimme queries en alle problemen waren als sneeuw voor de zon verdwenen: minder dan 0.2 seconde per pagina. Je kunt met dit soort optimalisaties wachten tot je in Beta zit, maar dan ben je wel de lul: Je mag een belangrijk deel van je code opnieuw gaan schrijven en je hebt al gebruikers die een beroerde ervaring hebben met jouw scripts.

Het aantal tabellen valt wel mee, jammer dat je niets zegt over de indexen, daar zit een belangrijk deel van jouw mogelijke performance. En dat moeten wel bruikbare indexen zijn, dan heb je er ook wat aan... En dat kun je nu al testen, daarvoor hoef je echt niet in Beta te zitten.

Maar voordat je verder gaat, ga eerst een MySQL versie 5.1 installeren, dan ben je tenminste weer up-to-date. Met een beetje geluk krijg je er ook nog wat performance bij. Al weet ik niet of MySQL al goed uit de voeten kan met 20 JOIN's, geen idee in hoevere ze dit hebben opgepakt. Je zou PostgreSQL kunnen overwegen, schaalt uitstekend en kan in elk geval met grote aantallen JOIN's uit de voeten. Kun je direct gebruik maken van functionele indexen, kun je wellicht ook nog een hoop aan hebben om de performance nog verder op te krikken.

[LauPro]

GlowMouse schreef op zaterdag 20 maart 2010 @ 16:44:
Gelet op een eerdere uitspraak van je ("Het optimaliseren van de database is overigens niet aan de orde, de applicatie die erop draait is er te groot, log en te slecht gescript voor.") lijkt het me meer voor de hand liggend om toch de database te optimaliseren. Als er niets geoptimaliseerd is, kun je vaak met een paar klikjes de boel flink versnellen.

Ik vraag mij af of dit überhaupt een optie is. Het is hier geen vast opgestelde webpagina. Als er sprake is van een game dan heb je het over een random shitload aan asynchrone read/writes (en voornamelijk reads). Natuurlijk zou je mechanismen in kunnen bouwen dat je bepaalde dingen cached in je app zodat je je DB een beetje ontlast maar dat lijkt mij lastig in te bouwen.

Bernardo schreef op zondag 21 maart 2010 @ 12:34:
@LauPro: Dat zou misschien een optie wezen, maar geeft dat niet veel extra latency?

Het geeft altijd extra vertraging, maar het idee is dat het 'duurder' is om de master DB te belasten met niet ertoe doende reads dan een slave. Volgens mij is de latency dus wel te overwegen. Het werkt alleen niet samen met transacties. Dus je moet sowieso een onderscheid maken tussen commit-queries en readonly queries.

[TheNephilim]

@cariolive23: Om even terug te gaan naar het andere spel, die heeft 16GB geheugen en een DB van 8GB. Dat past dus makkelijk. We gebruiken deels MyISAM en op de schrijfintensieve tabellen innoDB. We draaien het oude spel met 1600 queries per seconde piekbelasting. Zoals ik al zei, gemiddled ~50% SELECT, ~30% UPDATE en ~20% INSERT. Gemiddeld 16 queries per pagina. Kan niet meer gejoined worden. User-query bestaat uit enkele JOINS en subqueries. We zullen MySQL 5.1 eens gaan bekijken. Die gaan we in ieder geval voor ons nieuwe project installeren. PostgreSQL hebben we ook net geïnstalleerd, ziet er goed uit. Foreign keys en makkelijke stored procedures. Misschien gaan we er mee verder, we kunnen altijd nog over. Probleem is dat het geen dedicated server is, dus moeten we bestaande projecten aanpassen voor gebruik met PostgreSQL.

@LauPro: Nou misschien kunnen we daar eens naar kijken. MySQL proxy, 1 master en 2 slaves. Is het makkelijk te beheren? Dus server bijprikken en klaar of moet je dan allerlei dingen gaan herstarten enzo?

[qless]

Als je toch opnieuw gaat bouwen en HP nodig hebt is mischien cassandra wat voor jullie? Zeer makkelijk extra servers toevoegen, nadeel is wel dat er geen transaction support inzit.

[cariolive23]

qless schreef op maandag 22 maart 2010 @ 14:17:
Als je toch opnieuw gaat bouwen en HP nodig hebt is mischien cassandra wat voor jullie? Zeer makkelijk extra servers toevoegen, nadeel is wel dat er geen transaction support inzit.

Dit soort databases hebben nog wel meer nadelen dan alleen geen support voor transacties. Voordat je hiermee aan de slag gaat, ga je uiteraard eerst even kijken wat je nu precies nodig hebt. Dan pas ga er een passend product bij zoeken.

Puur voor de snelheid hoef je het niet te doen, relationele databases kunnen ook razendsnel zijn. Moet je de boel alleen wel zo gebruiken dat je het snel maakt. Brakke applicatiecode, verkeerd gebruik en verkeerde configuraties, dat zijn de grote knelpunten van databases en deze knelpunten kom je bij ieder soort, bij ieder merk database tegen.

[TheNephilim]

Om hier nog even op terug te komen; we hebben inmiddels een testcase opgezet. 2 webservers als slave en een andere server als master. De slaves doen alle SELECTS lokaal en UPDATE/INSERT/etc naar de master. Master-slave replication dus.

Mysql 5.1.46 hebben we gebruikt, helaas kwamen we erachter dat hier geen InnoDB bij-in zit. Maar die kunnen we vast er nog bij installeren voor zover ik kon begrijpen.

Het replicaten zelf opzetten was wenig werk. Na wat software aanpassingen draait ons nieuwe project dus op de master-slave setup. Werkt prima, enige jammere:

- Om UPDATE te doen heb je ook rechten op SELECT nodig op de master
- Enige vorm van delay is toch te merken, maar hier valt vast nog het 1 en ander te tweaken.

Sessies inmiddels ook in de DB, vroeg me af wat er gebeurd bij de volgende actie: Inloggen (maakt sessie aan) -> vervolgpagina (roept sessie aan); bestaat de sessie daar al? header ("location: "); is namelijk erg snel!

[nielsl]

Bernardo schreef op donderdag 20 mei 2010 @ 14:31:
Om hier nog even op terug te komen; we hebben inmiddels een testcase opgezet. 2 webservers als slave en een andere server als master. De slaves doen alle SELECTS lokaal en UPDATE/INSERT/etc naar de master. Master-slave replication dus.

Mysql 5.1.46 hebben we gebruikt, helaas kwamen we erachter dat hier geen InnoDB bij-in zit. Maar die kunnen we vast er nog bij installeren voor zover ik kon begrijpen.

Het replicaten zelf opzetten was wenig werk. Na wat software aanpassingen draait ons nieuwe project dus op de master-slave setup. Werkt prima, enige jammere:

- Om UPDATE te doen heb je ook rechten op SELECT nodig op de master
- Enige vorm van delay is toch te merken, maar hier valt vast nog het 1 en ander te tweaken.

Sessies inmiddels ook in de DB, vroeg me af wat er gebeurd bij de volgende actie: Inloggen (maakt sessie aan) -> vervolgpagina (roept sessie aan); bestaat de sessie daar al? header ("location: "); is namelijk erg snel!

maar nu het meest interessante, heb je ook performancewinst? Worden queries sneller uitgevoerd? Of zit r nog winst in DB optimalisatie? Misschien dat je daarover ook nog wat kunt vertellen?

[GlowMouse]

En nog interessanter: hoe goed overzie jij de gevolgen als één van je drie servers uitvalt.

5.1.46 zonder InnoDB is vreemd trouwens.

[TheNephilim]

@ nielsl: Er is vast nog vanalles te optimaliseren, dat ontken ik niet, maar ik wil al wel vast een schaalbare omgeving bekijken. Achteraf oplossingen zoeken hebben we vaker gedaan en dan loop je vaak achter de feiten aan. De performancewinst hebben we nog niet uitgebreid kunnen testen, maar dat gaan we zeker goed bekijken.

@ GlowMouse: Als 1 van de slaves uitvalt is dat geen probleem. Die krijgen alleen maar SELECT's voor hun kiezen en valt de server om, dan stuurt onze Loadmaster er ook geen requests meer heen. Als een Master uitvalt zijn er inderdaad grotere problemen. We zijn nog bezig met uitzoeken wat handig is, een hotspare master of gewoon standaard 2 masters. Nou is het geen kritische applicatie, maar redundancy is zeker een punt van aandacht. Dat InnoDB probleem is al opgelost, foutje in de config.

Verder heb ik de performance weer wat op weten te krikken. Waar ik eerder nog sprak van latency, is deze nu helemaal verdwenen. Uiteraard zoeken we daar nog wel een oplossing voor, want als de servers het wat drukker hebben doet deze zich misschien wel weer voor.

De applicatie is nu zodanig aangepast dat alle leesacties naar een slave gaan (localhost via mysql.sock) en de writes allemaal naar de master server. Die heeft een InnoDB versie van alle tabellen, de slaves MyISAM. Tot nu toe ben ik erg te spreken over de werking van het geheel, al zullen we verder moeten testen om te kijken wat het onder stress doet, dat is de volgende stap.

Het idee is uiteindelijk om straks webserver-db combinaties te hebben, bestaande uit; quad-core CPU (liever meer cores dan Ghz), 4GB werkgeheugen, 1 snelle disk (raptor, ssd). Al met al vrij goedkope kleine servertjes.

[ Voor 0% gewijzigd door TheNephilim op 21-05-2010 00:24 . Reden: Opmaak, spelfouten ]

[TheNephilim]

Sinds we nu toch gebruik maken van de InnoDB engine op de master server, bedacht ik me dat we nu ook makkelijk met transactions kunnen gaan werken.

Voor elke serie updates, die bij elkaar horen, start ik een transactie en ik commit deze aan het eind. Zou nou één van de "tussenliggende" statements een error produceren, issued de db-wrapper een rollback en stopt verdere uitvoering van het script.
Nou checken we van te voren alles, ook zeker de input, dus een fout in 1 van de update statements zal niet gauw voorkomen. Maar het is wel een mooi fallback systeem naar mijn inzien.