haha- @Dennis en @Rollerscapes bedankt voor de uitgebreide reacties, ik reageer morgen nog even inhoudelijk!
haha- @Dennis en @Rollerscapes bedankt voor de uitgebreide reacties, ik reageer morgen nog even inhoudelijk!
als er nu 2 kapotte hds in zitten, heb je best kans dat de rest ook snel stuk gaat. Als je de server gaat gebruiken voor productie zou ik ze snel vervangen (kijk dan gelijk eens naar ssd, dat vind mysql ook erg lekker, let wel op trim en raid combinaties)
Weet je heel zeker dat MySQL juist met ssd omgaat?
Ik heb gehoord dat sommige DB's hier nog moeite mee hebben omdat ze de snelheid niet goed kunnen bepalen en dan een verkeerd query plan maken.
Vooral het gebruik van indexes op ssd kan onverwachte resultaten geven.
Park The Hosting Manager - your friend in hosting software
"Zo zijn ook wij één leverancier. Dé leverancier in gedegen Linux kennis, wanneer jij dat nodig hebt."
Boek je admin vandaag nog via : www.admin.nu
Gevestigd in Nederland en Moldavië
Lees hier de webhostingtalk.nl forum regels en voorwaarden!
Sh*t, betrapt
Nee serieus, ik heb dit gehoord van iemand die zelf DBA is en grote database systemen onderhoud.
Zoals ik al zij 'sommige DB's', het werkt wel maar je kan onverwachte resultaten krijgen als de index op een SSD staat (omdat die niet zo groot hoeven te zijn).
De query planner denkt dat de index op normale disk staat en daardoor hem als 'langzamer' bestempeld dan de SSD daadwerkelijk is.
Omdat hij een langzame verwacht en in werkelijkheid heel snel is, gaat z'n hele plan anders uitpakken.
En let vooral op 'sommige', ik zeg niet dat dit voor MySQL ook zo is.
Vandaar ik vraag 'Weet je heel zeker dat MySQL juist met ssd omgaat?'.
http://www.pfz.nl/archief/1326160-postgresql-vs-mysql/ (sorry van de titel)
Een SSD voor databases, da's apart, PgSQL heeft een intens lange discussie gehad over bijzonder gedrag van PgSQL op een SSD, de bizar-korte seektijden brachten de queryplanner van streek. Hebben jullie daar nog een RAID aan gehangen en hoe ga je om met het garbage-cleanen en de leeftijd van de SSD ivm het hoge aantal fsyncs?Nu zit er wel een verschil in PostgreSQL en MySQL, maar de werking van een query-planner verschild niet veel van elkaar.Ik weet niet in hoeverre de queryplanner borkt als de seektijden van de index zo laag worden. Het zal wel niet zoveel uitmaken, maar als je toch geld gaat uitgeven dan zou ik de SSD gebruiken voor datgene waar je disk-doorvoer-bottleneck zit en dat is niet de laadtijd van de index.
Maar, ook SSD is niet onfeilbaar dis ook daar zou je RAID moeten toepassen en dan loopt het voor 160GB al aardig in de papieren,. met terabyte SSD's tegen 9000 euro is het nog geen optie, een dikke RAID array met BBU kun je voor een fractie van de prijs opzetten en dat performt niet eens zo gek veel slechter.
Een bekend probleem van VM is de disk container, het host OS moet deze als bestand wegschrijven waardoor er een snelheidsvermindering optreed.Tegenwoordig kun je op een goede (!!) VM vrijwel alles draaien. Ook hele drukke DB servers. De overhead is nihil en de voordelen zijn groot.
Als de disk direct is gekoppeld aan de hardware heb je dit probleem inderdaad niet meer.
Nog een ander probleem is dat de disk-controller aangeeft dat de data is weggeschreven, maar in werkelijkheid nog in de cache van het host zit.Een database wil je liever niet in VM draaien.
Tenzij de virtual harddisk direct is gekoppeld aan de hardware zelf.
Transactionele storage engines kunnen hierdoor last krijgen van data corruptie bij een crash van de host, dit was vroeger te minste zo.
Ik weet niet of dit inmiddels al verbeterd is?
Even snel met Google gezocht en kwam dit topic tegen bij onze Amerikaanse vrienden(nog niet helemaal gelezen overigens, even geen tijd).
http://www.webhostingtalk.com/showthread.php?t=1053550
En http://www.slideshare.net/gslin/mysq...ntation-567083 (twee jaar oud).
De ontwikkelingen van SSD zijn de laatste paar jaren enorm versneld, dat ik ze niet meer kan bijhouden, dus ik kan het fout hebben.
Park The Hosting Manager - your friend in hosting software