Onderwerp: MySQL op aparte server

Oorspronkelijk geplaatst door ryankalkhoven

Kun je mij uitleggen waarom je dat juist voor mysql specifiek niet zou willen?

Ik heb nooit zoveel getest etc met mysql om te geven wat nu wel of niet beter zou zijn. Bovenstande uitspraak doe ik op basis van andere applicaties zoals mail en andere db applicaties.

Omdat het dusdanig veel queries kan opleveren dat het je performance van je netwerk kan beïnvloeden ben ik bang.

Wanneer je maar één applicatie als "De Telefoongids" zou draaien doe je alles dedicated, je weet toch wat er gebeurt. Wanneer je dit niet weet wil je dingen uitsluiten, dus niet iedereen op één box.

Tevens gaan alle MySQL applicaties plat wanneer je box down is, dit is bij Localhost beperkt tot die ene machine.

Oorspronkelijk geplaatst door izdesign

Wido die weet hier vast meer van dit doen ze volgens mij ook bij pcextreme.nl dacht ik..

Het is niet specifiek PcExtreme die dit alleen doet. Het gaat erom waarom je het doet.

De meeste personen denken dat je bij dedicated boxen juist veel problemen uitsluit, dat is bij MySQL juist niet het geval heb ik het idee.

Wij maken heel veel gebruik van losse MySQL servers, waarom?

Wij hebben redelijke grote webhosting clusters (5 - 10 webservers) en dan is het niet meer handig om je MySQL lokaal te draaien, je moet dan zorgen voor replicatie e.d. en dan heb je alleen read-only op bepaalde punten.

Upgraden naar een nieuwe versie is een stuk makkelijker en je kan een server samenstellen die helemaal gericht is op een bepaalde taak.

Zo kan je in je webservers simpele S-ATA disks stoppen en in je MySQL server kan je snelle RAID-Controllers plaatsen met ook goede disks.

Als je geen cluster draait, dan is het denk ik niet veel handiger, tenzij je erg veel SQL hebt wat qua performance niet samen kan met een webserver.

Vanaf MySQL 5.1 kan je MySQL ook goed clusteren en dan ben je van het SPOF af.

Je kan dan op alle nodes reads en writes doen, dat is natuurlijk helemaal super.

In /etc/hosts hebben wij gewoon een pointer gemaakt van db.pcextreme.nl naar het IP van de database-server.

Maar ik snap niet wat je bedoelt met "tenkoste van je netwerk".

Als ik een aparte server draai voor mysql dan wordt dat op een private netwerk gedaan. Mysql bied je niet aan alle internet gebruikers aan maar alleen aan je klanten dus publiek hoeft die niet te zijn.

Mail is een publieke service dus die moet direct aan het internet mysql kan op een private lan net als bijv. backupservers. Ik mag aannemen dat je ook backups via een private lan draait en niet over je internet kant.

Kortom het internet verkeer zal niet worden vervuilt met verkeer van en naar je mysql server.

En net als wat Wido zegt is dat je voor een dedicated machine heel goed met je hardware in kan spelen op de performance van de service die je draait.

Dus ik denk dat het wel degelijk voordelen heeft.

Maar ik ben van mening dat het allemaal afhangt van de schaal waarop het gebeurd.

@Wido; Zit een kern van waarheid in, echter zie ik geen voordeel in remote in jouw sitatie (waar ik zelf ook zit). Je MySQL repliceren is leuk, maar wanneer de webserver dood gaat en de website daar lokaal op draaide (dus niet ge-loadbalanced) heeft het nog weinig nut.

@Ryan: Je krijgt ontzettend veel intern verkeer dat gewoon niet nodig is. Zolang de box het zelf kan trekken ben je altijd sneller met localhost en meer save qua werking globaal gezien en tevens lokaal.

Wij hebben MySQL ook aan een intern netwerk hangen, daar heeft verder niemand toegang tot, dit is volledig gigabit voor de meest lage latency.

De backups gaan zelfs over een ander netwerk om er voor te zorgen dat als er een gigabit over het backupnetwerk gaat dat dit geen invloed heeft op de performance van het interne netwerk.

Wido, dat is ook een optie uiteraard. Ligt er even aan of je het wel extern aan zou willen bieden.

Ieder voordeel heeft zo zijn nadeel en andersom. Ligt een beetje aan de situatie.

DA kan wel werken met een apparte MYSQL

Oorspronkelijk geplaatst door Wido

Vanaf MySQL 5.1 kan je MySQL ook goed clusteren en dan ben je van het SPOF af.

Welke nieuwe features van 5.1 maken dat (beter) mogelijk? In 5.0 zit ook ndb?
http://dev.mysql.com/doc/refman/5.0/...-overview.html

In /etc/hosts hebben wij gewoon een pointer gemaakt van db.pcextreme.nl naar het IP van de database-server.

Dat is erg verstandig, zo heb je geen DNS overhead.

Oorspronkelijk geplaatst door Thijs

Wanneer je wil moven van box naar box zal je toch box1 en box2 moeten gebruiken.

Dezelfde hostname gebruiken gaat niet echt

Als je 1 mysql server voor meerdere servers draai dan heeft ie voor zover mij bekend altijd dezelfde naam.
Ik ga dan uit van een dedicated mysql server....

Oorspronkelijk geplaatst door Thijs

@Ryan: Je krijgt ontzettend veel intern verkeer dat gewoon niet nodig is. Zolang de box het zelf kan trekken ben je altijd sneller met localhost en meer save qua werking globaal gezien en tevens lokaal.

Maar is dit niet wat ik zeg dan? Zolang het om kleine belasting gaat doe je het op 1 en dezelfde machine en zodra de belasting te groot wordt voor dezelfde machine dan ga je het splitsen.

Kortom afhankelijk van de schaal waarover het gaat.

(Eindelijk weer eens een goede discussie ipv die onzin van de laatste tijd.)

Ik ben alleen nog benieuwd naar eventueel wat cijfers... Misschien dat Wido wat inzicht kan geven van op welk moment jullie zijn overgestapt naar losse servers in clustervorm etc.??

Oorspronkelijk geplaatst door ryankalkhoven

Ik ben alleen nog benieuwd naar eventueel wat cijfers... Misschien dat Wido wat inzicht kan geven van op welk moment jullie zijn overgestapt naar losse servers in clustervorm etc.??

Het lijkt me voor de hand liggen dat je dat doet zodra de load Apache+MySQL richting de 1.00 gaat. Dan koppel je MySQL los en ga je er losse webservers aanhangen. De volgende stap is MySQL clusteren en je (read) queries verdelen.

Maar daar is natuurlijk geen algemeen iets als #queries/hour voor te geven.

Oorspronkelijk geplaatst door sp-services

DA kan wel werken met een apparte MYSQL

Hoe dan? Wèl dat de klant gewoon alles kan aanpassen in DirectAdmin aan mySQL

Oorspronkelijk geplaatst door Keenondots

Het lijkt me voor de hand liggen dat je dat doet zodra de load Apache+MySQL richting de 1.00 gaat. Dan koppel je MySQL los en ga je er losse webservers aanhangen. De volgende stap is MySQL clusteren en je (read) queries verdelen.

Maar daar is natuurlijk geen algemeen iets als #queries/hour voor te geven.

Het is inderdaad een goede conclusie dat bij een x-load je dat gaat toepassen, maar waar ik dan nieuwsgierig naar ben is:

Stel je hebt 0.4 load aan mysql en 0.6 aan apache. Wat gebeurd er dan zodra je dit extern plaatst. Dan schat ik in dat je niet met 0.4 op je totale load terug zakt op die machine, maar misschien 0.3 omdat er 0.1 extra nodig is voor apache of je eth..... In die hoek zat ik even te denken.
(Volgens mij doelde de TS daar ook op alleen heb ik het idee dat hij verwacht dat je er niet zoveel mee opschiet als in mijn voorbeeld).

Oorspronkelijk geplaatst door ryankalkhoven

Stel je hebt 0.4 load aan mysql en 0.6 aan apache. Wat gebeurd er dan zodra je dit extern plaatst. Dan schat ik in dat je niet met 0.4 op je totale load terug zakt op die machine, maar misschien 0.3 omdat er 0.1 extra nodig is voor apache of je eth..... In die hoek zat ik even te denken.

Dat lijkt me geen stof om calculaties tot achter de komma op los te laten zonder de applicatie in kwestie te kennen. Dus in een Shared Hosting omgeving is daar al helemaal weinig over te zeggen. Apache krijgt wel meer geheugen ter beschikking op een node als MySQL er niet meer op draait, daardoor kan hij requests wellicht sneller (meer tegelijk) verwerken, waardoor de load daalt. De latency van een enkele query kan dalen omdat het niet over je lo interface gaat, maar over eth0 (of eth1, of bond0, you get the point).

Daarnaast is load ook maar een getal. Als je load < #CPU's is er weinig winst te behalen. Je koopt natuurlijk geen Dual Xeon om een load van 0.01 te draaien*.

Dit soort zaken stel je m.i. vooral proefondervindelijk vast (live in een Shared Hosting omgeving, vooraf voor een dedicated applicatie).

*) Hmm, onze zwaarst belaste server doet momenteel:
653 processes, load average: 0.12, 0.14, 0.14
(EDIT: oh natuurlijk, het is 18u, Nederland zit aan tafel)