[MySQL] Slechte Performance met Replicatie

[Davio]

Een bedrijf waar wij zaken mee doen, heeft een MySQL-server die doorgaans zo'n 5000 transacties per seconde afhandelt. Op het moment dat er gerepliceerd wordt, zakt de performance naar ongeveer 50 transacties per seconde. Het bedrijf runt een website met PHP die vanaf deze database leest.

Nu hebben wij in ons bedrijf wel veel ervaring met meer bedrijfsgerichte databases (voornamelijk Progress), maar niet met MySQL dat hier als volwaardige business database gebruikt wordt.

Binnenkort gaan wij dan ook langs om te kijken wat er beter kan, maar mijn vraag aan jullie is:
- Welke algemen tips kunnen jullie geven met betrekking tot MySQL, replicatie en performance?
- Waar moeten we voornamelijk op letten?
- Ik heb op internet al een tooltje gevonden: http://www.maatkit.org/ , is iemand hier bekend mee?
- Ik las ook dat er verschillende versies zijn van MySQL, oplopend in prijs (Community is gratis, Cluster is $10.000), maakt dit veel verschil uit?

Ik heb zelf ook al het één en ander op internet gezocht, maar ik vraag hier gewoon om jullie persoonlijke inzichten mbt. performance en replicatie.

[cariolive23]

Tip: Huur een MySQL-dba in, die kan je in korte tijd veel wijzer maken dan wat via een forum in 100 reacties mogelijk is. En daarnaast wellicht ook de problemen oplossen. Dit hoeft echt geen grote klus te zijn, na enkele uurtjes onderzoek is vaak wel duidelijk waar de problemen vandaan komen. Waarschijnlijk is dit veel goedkoper dan zelf eerst MySQL leren kennen en dan nog eens de problemen op gaan lossen.

Je geeft in bovenstaand verhaal véél te weinig informatie om ook maar een indicatie te krijgen van de oorzaak, dat kan echt van alles zijn. Wat zijn bv. "5000 transacties per seconde" ? 5000 keer niks gaat vrij snel, maar 5000 keer een flinke query, dat is een heel ander verhaal. Overigens heeft Tweakers.net het nooit voor elkaar gekregen om een kleine 1000 transacties per seconde uit hun MySQL-server te persen, zo rond de 600-700 hield het wel op. Maar dat zijn uiteraard wel andere transacties dan waar jij nu naar kijkt.

Ps. Ik ben geen MySQL dba, ik pas.

[Davio]

Oké, het is misschien beter een MySQL-dba in te huren, maar ik ben gewoon benieuwd of Tweakers zelf problemen hebben ondervonden met MySQL replication. Wat praktijkvoorbeelden misschien. Daar vraag ik om.

We gaan er alleen heen om een indicatie te krijgen van hun probleem, we weten ook niets meer dan wat ik hierboven heb aangegeven. Ik wilde alleen wat meer voorbereid zijn dan ik nu ben. En mocht het te moeilijk voor ons zijn, kunnen we altijd nog iemand inhuren.

[cariolive23]

Ja, Tweakers heeft er een hoop problemen mee gehad, de huidige situatie ken ik niet.

Het voornaamste probleem was wel dat de MySQL-replicatie door Artemis 5 een grote achterstand had opgebouwd, waardoor de data op deze server onbruikbaar was.

Welke (sub-) versie van MySQL gebruik je?

[Davio]

cariolive23 schreef op donderdag 18 november 2010 @ 14:02:
Ja, Tweakers heeft er een hoop problemen mee gehad, de huidige situatie ken ik niet.

[...]


Welke (sub-) versie van MySQL gebruik je?

Ik gebruik zelf de nieuwste GA, 5.1.52.

[Snow_King]

Als je gaat repliceren schrijf je binary logs, is de disk waarop deze moeten worden weggeschreven wel snel genoeg?

[Verwijderd]

Ik weet niet hoe de koppeling is tussen de twee servers is. En wat @hierboven ook zegt, je gaat in 1 keer veel meer met je disk doen. De slave gaat namelijk ook lezen van deze disk.

[JaQ]

Ik hoop maar dat jij (of je manager) geen beloftes hebben gedaan. Als je zelf aangeeft dat je geen MySQL kenner bent, dan kan het maar zo zijn dat je de "go_fast" parameter niet op true zet en de performance nog verder instort.

De probleemomschrijving en het probleem zijn veel te generiek om een specifieke uitspraak over te doen. Gokken doe je over het algemeen niet met (kritische) systemen van klanten.

[Davio]

JaQ schreef op donderdag 18 november 2010 @ 16:09:
Ik hoop maar dat jij (of je manager) geen beloftes hebben gedaan. Als je zelf aangeeft dat je geen MySQL kenner bent, dan kan het maar zo zijn dat je de "go_fast" parameter niet op true zet en de performance nog verder instort.

De probleemomschrijving en het probleem zijn veel te generiek om een specifieke uitspraak over te doen. Gokken doe je over het algemeen niet met (kritische) systemen van klanten.

Nou, we hebben geen beloftes gedaan, het bedrijf heeft gewoon aan ons gevraagd of we er een kijkje naar willen nemen, en dat willen we best natuurlijk.

Nu zijn er een aantal factoren die voor elke db gelden en die dus meer server gerelateerd zijn, dat is ook het probleem niet.

Ik vraag me alleen af of er specifieke MySQL-quirks zijn waar we rekening mee moeten houden. Misschien heeft MySQL wel bekende bugs met replication of werkt het in het algemeen gewoon bagger.

[cariolive23]

Davio schreef op donderdag 18 november 2010 @ 14:31:
[...]

Ik gebruik zelf de nieuwste GA, 5.1.52.

Oké, dat is wat jij gebruikt, maar wat gebruikt de klant op zijn servers?

[GlowMouse]

cariolive23 schreef op donderdag 18 november 2010 @ 14:02:
Ja, Tweakers heeft er een hoop problemen mee gehad, de huidige situatie ken ik niet.

[...]


Welke (sub-) versie van MySQL gebruik je?

Dat gaat over replicatie-lag op de slave. De master hoort nauwelijks vertraagd te worden.

- Ik heb op internet al een tooltje gevonden: http://www.maatkit.org/ , is iemand hier bekend mee?

Dat is meer dan 'een' tooltje; het is een hele verzameling handige tools als je ermee om kunt gaan.

- Ik las ook dat er verschillende versies zijn van MySQL, oplopend in prijs (Community is gratis, Cluster is $10.000), maakt dit veel verschil uit?

MySQL Cluster is een heel ander product met heel andere karakteristieken. Ik zou niet zomaar iemand overzetten.

Ik vraag me alleen af of er specifieke MySQL-quirks zijn waar we rekening mee moeten houden. Misschien heeft MySQL wel bekende bugs met replication of werkt het in het algemeen gewoon bagger.

Op de slave is het single-threaded, dat is het enige 'probleem'. En de write performance wordt niet spectaculair beter, daarvoor (en alleen daarvoor) is sharden een betere oplossing.

[Wolfboy]

Het probleem wordt vermoedelijk veroorzaakt doordat het inschakelen van replicatie opeens ook het binary log inschakelt waarbij _elke_ transactie direct weggeschreven moet worden met daarna een fsync. Als je autocommit gebruikt kan dit een flinke impact geven op je performance.

Zodra je de commits gaat groeperen heb je in ieder geval al veel problemen opgelost. Of als je fsync geen verplichting maakt. Maar let er wel op dat het uitschakelen van fsync _heel_ gevaarlijk kan zijn in het geval van crashes oid.

[Davio]

Wolfboy schreef op maandag 22 november 2010 @ 17:56:
Het probleem wordt vermoedelijk veroorzaakt doordat het inschakelen van replicatie opeens ook het binary log inschakelt waarbij _elke_ transactie direct weggeschreven moet worden met daarna een fsync. Als je autocommit gebruikt kan dit een flinke impact geven op je performance.

Zodra je de commits gaat groeperen heb je in ieder geval al veel problemen opgelost. Of als je fsync geen verplichting maakt. Maar let er wel op dat het uitschakelen van fsync _heel_ gevaarlijk kan zijn in het geval van crashes oid.

Bedankt voor de tip.

Ik heb begrepen dat het probleem voornamelijk optreedt wanneer replicatie uitstaat en dan opeens wordt ingeschakeld. Ik ga in ieder geval meer onderzoek doen naar de door jou genoemde mogelijke oplossing.

[Guru Evi]

Kijk eerst eens op je systeem waar je resources worden verbruikt. Is het je schijf, CPU, RAM, netwerkverbinding. Ik denk in ieder geval dat het hoogstwaarschijnlijk de hardware is waar je op draait. Zijn de arrays met data en logs gescheiden en is er wel een actieve BBU? 5000 transacties is niet zo erg als alles read-only is en mooi in RAM blijft. Met 50 transacties per seconde ziet het er naar uit dat je op 1 (RAID1) schijf werkt en aan de max IOPS komt (RAID1 = max IOPS / 2) - schakel je per ongeluk niet de query log in ipv de binary log?