Onderwerp: MySQL Replication gebaseerde setup zonder single point of failure

Ik ben bezig met een case study voor een mysql cluster achtige applicatie, maar dan gericht op de webhosting markt. Het probleem met mysql cluster is, dat alle databases en indexes tegelijk in het geheugen geladen moet worden. Dit is nog te overzien wanneer je een database van 1 gb hebt, echter wanneer er meer dan 300+ klanten op een mysql server staan, is mysql cluster gewoon geen optie meer (major memory consumer).

Vandaar dat ik naar een oplossing heb gezocht.

Ik heb een mysql replication based setup, omgebouwd van een 2 tier systeem naar een 3 tier systeem. Dit heb ik gedaan zodat je je applicaties niet hoeft aan te passen en toch gebruik kan maken van mysql replication. Dit is een absolute vereiste wanneer het gaat om webhosting. Scripts als phpBB en vBulletin zijn enorme scripts die uit meerdere classes bestaan en heel veel meer queries. Om al deze scripts per klant te moeten aanpassen, zou onmogelijk zijn.

Verder brengt de tier 3 setup ook nog wat voordelen met zich mee. Het introduceert een high availability setup, wat een ander vereiste is in een cluster based oplossing.

Ik heb al mijn plannen in het engels uitgelegd op mijn weblog: http://funzoneq.livejournal.com/19503.html omdat ik feedback verwacht vanuit verschillende hoeken. Verder heb ik grafieken toegevoegd om de situatie te verduidelijken.

Ik zou graag van jullie feedback willen ontvangen over de technische aspecten van deze setup, voordat ik begin met het programmeren van deze applicatie.

Hoewel mijn ervaringen met MySQL-clusters niet zo groot zijn, heb ik er wel al veel onderzoek naar gedaan.

Dat gehele MySQL-cluster gebeuren moet je uit je hoofd zetten, die NDB tabellen zijn nou niet echt om over naar huis te schrijven.

Wat je het beste kan doen is het volgende.

Schrijf je applicatie zo dat deze onderscheid kan maken tussen READ en WRITE databases, ofwel, SELECT (READ) en UPDATE, DELETE, INSERT (WRITE).

Je pakt 1 host die laat je als WRITE host dienen, deze is dan ook je master van de replication. Dit hoeft geen dikke bak te zijn.

Vervolgens pak je 2, 3, 4, 5, zo veel bakken als jij wil, als replication slaves, ofwel READ-hosts.

Nu kan je applicatie zijn SELECT's doen vanaf deze hosts, gaat de master dood, dan kan je geen writes meer doen, maar wel reads.

Je kan die master dan via heartbeat redundant uitvoeren, maar dan moet je weer wat gaan verzinnen op het moment dat die dode bak weer up komt.

MySQL is op dit moment nog niet volwassen genoeg om echt goed te clusteren.

Er zijn wel opties zoals M/Cluster of GoldenGate, maar daar moet je toch echt al snel aan prijzen van 30k gaan denken en of dat het waard is?

Het idee is wel aardig, een query redirector. Maar het grote probleem (master server down = geen write queries) blijft. Het is dus geen volledige failover/HA oplossing.

Wido, jij schreef dat MySQL met een upcoming versie wel volledige HA kan bieden?

Oorspronkelijk geplaatst door Keenondots

Het idee is wel aardig, een query redirector. Maar het grote probleem (master server down = geen write queries) blijft. Het is dus geen volledige failover/HA oplossing.

Wido, jij schreef dat MySQL met een upcoming versie wel volledige HA kan bieden?

Klopt, dat probleem heb je dus nog steeds, maar als je een beetje goed programmeerd moet je zonder writes kunnen, maar dat ligt natuurlijk ook helemaal aan je applicatie.

Ik heb contact gehad met MySQL Nederland, ik begreep dat in versie 5.1 volledige clustering zou komen (disk based), maar dat blijkt ook nog steeds met die NDB tabellen te werken, niet iets wat ik zoek en handig vind.

Oorspronkelijk geplaatst door Wido

Klopt, dat probleem heb je dus nog steeds, maar als je een beetje goed programmeerd moet je zonder writes kunnen, maar dat ligt natuurlijk ook helemaal aan je applicatie.

Ik heb contact gehad met MySQL Nederland, ik begreep dat in versie 5.1 volledige clustering zou komen (disk based), maar dat blijkt ook nog steeds met die NDB tabellen te werken, niet iets wat ik zoek en handig vind.

Voor reguliere webhosting wil je dan wel een redirector die de queries kan verdelen. Misschien is een redirector, n-read slaves en een DRDB-based master wel haalbaar. Ervaring* ontbreekt denk ik.

*) Google: "... circa 1.270 voor mysql drdb".

Oorspronkelijk geplaatst door Keenondots

Voor reguliere webhosting wil je dan wel een redirector die de queries kan verdelen. Misschien is een redirector, n-read slaves en een DRDB-based master wel haalbaar. Ervaring* ontbreekt denk ik.

*) Google: "... circa 1.270 voor mysql drdb".

Dat zou kunnen, naar een query redirector heb ik nog nooit gekeken, zal vast wel bestaan (gok ik).

Data tussen meerdere MySQL-servers delen is een no-go, dan krijg je echt problemen met LOCK's e.d.

Interessant:
http://www.mysqlperformanceblog.com/...l-replication/

Ik vraag me af of de (mem)cache ook stale (niet meer te gebruiken) wordt zodra er een wijziging van de data heeft plaats gevonden?

Daarnaast vraag ik me af of het niet mogelijk is om de master redundant te maken, door bijvoorbeeld een van de slaves de rol van de master over te laten nemen zodra deze uitvalt?

@Wido

Je hebt niet het volledige artikel gelezen. Mijn setup is namelijk op basis van MySQL Replication. De query director zorgt er voor dat je toch de voordelen van mysql replication hebt, maar er geen rekening mee hoeft te houden in je applicaties. Verder zal de query director een HA mogelijk maken.

Inmiddels heb ik wat meer reacties gekregen van uit de mysql community. Er zijn al oplossingen die er rekening mee houden. Lees deze 2 artikelen eens door:

http://www.onlamp.com/lpt/a/6549
en
http://sqlrelay.sourceforge.net/

Het enige probleem is dat je voor de ene weer een API (sql relay) moet gaan gebruiken en dat je voor de andere moet gaan load balancen tussen de masters of je scripts weer moet aanpassen.

Toch is de onlamp methode een zeer geschikte methode.

@ Arnout
In mijn artikel beschrijf ik ook het feit dat je je query cache (memcached) selectief moet flushen. Wanneer er een INSERT, UPDATE of DELETE op een bepaalde tabel valt, moet je alle selects van die tabel die gecached zijn flushen. Anders denken de users dat ze gek worden, omdat hun veranderingen niet worden doorgevoerd

en over de redundant master, zie mijn artikel, DRDB of mysql multi-master van OnLamp.

@keenondots
DRDB bestaat altijd uit een Active- en een backup-server. Beide servers kunnen dus niet tegelijkertijd actief zijn. Als je dat wil zul je een multi-homed-master-setup moeten bouwen zoals in het onlamp artikel.

Ik heb inderdaad niet het volledige artikel gelezen, dat klopt, ik heb alleen even mijn ervaringen hier gepost.

Solution 1: DRDB
One solution is to create an active-backup situation via DRDB. DRDB keeps one partition synchronized over two machines. This partition will include the databases.

Volgens mij werkt dit niet gezien MySQL niet altijd meteen alle updates naar schijf schrijft.
Dan heb je dus kans op een corrupte database zonder dat je het door hebt op het moment dat je overschakelt naar de backup server.

Met bijv. PostgreSQL kan het wel, doordat daarbij standaard de data synchroon naar schijf wordt geschreven op het moment dat je een commit doet.

Solution 3: Query Director

[...]

Here are the general ideas:

Based on MySQL Replication
The current webserver to mysql server is a tier 2 structure. I am planning to make it a tier 3 structure. In between the webserver and the mysql replication group, comes the query director. The main task of the query director will be the splitting of the SELECT queries from the UPDATE, INSERT and DELETE queries.

Select queries
All SELECT queries will be cached with the Memcached application from Danga.com. This application allows a distributed use of memory, making scalability easy and fast. Once a write-query updates the table, the cache will have to be filtered. If a SELECT query doesn't exist in Memcached, the query director will load balance it to one of the slaves.

Bij veel applicaties zou dit goed kunnen werken.

Het probleem blijft echter dat MySQL replicatie asynchroon is.
De gegevens op je slaves lopen dan ook ALTIJD iets achter op de master.
De vraag is dan ook wat er belangrijker is? Dat er een zo laag mogelijke downtime is, of dat de gegevens consistent en up-to-date zijn?
In het laatste geval zou ik zo'n setup niet voor fail-over doeleinden gebruiken, maar eerst de master proberen te reanimeren...

Oorspronkelijk geplaatst door maxnet

Het probleem blijft echter dat MySQL replicatie asynchroon is.
De gegevens op je slaves lopen dan ook ALTIJD iets achter op de master.
De vraag is dan ook wat er belangrijker is? Dat er een zo laag mogelijke downtime is, of dat de gegevens consistent en up-to-date zijn?
In het laatste geval zou ik zo'n setup niet voor fail-over doeleinden gebruiken, maar eerst de master proberen te reanimeren...

Het is inderdaad precies wat je net wil. Daarom kan je ook twee keuzes maken: Of read-only of negotiate master. Er staat ook bij dat er een 'meest up to date'-slave word uitgezocht, maar verlies van data kan gebeuren, ookal is het hoogst uit een seconde of 10 (MAX!). Als slaves meer dan 20 seconden achter lopen met replication worden ze even uit de pool gehaald, zodat ze rustig terug kunnen replicaten. Zodra ze weer up to date zijn, komen ze weer terug in de slave pool. Wanneer dit regelmatig gebeurd, kunnen er twee dingen aan de hand zijn: Je hebt te weinig slaves of je hebt teveel write queries. Het eerste geval: plaats een slave bij. Het tweede geval: upgrade hardware of begin een nieuw cluster.

Het valt me zojuist pas op dat er flink wat apparatuur aan deze opstelling te pas komt. Zo tel ik een totaal van 16 servers en 6 switches. Gezien dit om een enterprise oplossing zou gaan denk ik dat dat je dan A-merk hardware inzet en zodoende mag je dus ook rekenen op een gemiddelde van 600 euro per server en 200 euro per switch. Hierdoor kom je wat betreft hardware al snel uit op 9.600 euro voor de servers en 1.200 euro voor de switches, een totaal van 10.800 euro.

Bovenop de hardware zul je ook flink wat kostbare uren in het geheel moeten steken om het te bouwen en te finetunen waarbij ik van een uurtarief van 100 euro per uur uitga en je tenminste 150 tot 200 uur nodig hebt om zoiets (stabiel) neer te zetten. Totaal dus zo'n 15.000 euro.

Op basis van mijn aannamen schat ik dat je voor de in de whitepaper beschreven oplossing zo'n 25K euro nodig hebt om te realiseren. Als je dan kijkt naar de oplossingen die Wido noemden, zoals die van Goldengate en M/Cluster, die ongeveer 30K kosten, maar zich wel al ruimschoots bewezen hebben en doorgetest zijn. Dan vraag ik me af of de oplossing die in de whitepaper beschreven staat wel de best bang for you buck zou zijn nog even los van de stabiliteit, data integriteit en daadwerkelijke beschikbaarheid.

Het blijkt dus dat mijn oplossing al bestaat: http://sequoia.continuent.org/HomePage

Dit is het open-source backend van m/cluster. Een applicatie die normaal 30.000 euro kost (ondersteuning enzo). Je moet het alleen zelf opzetten, maar dan heb je ook wat