failover linux / mysql server

[Standeman]

Mijn situatie is als volgt: we hebben een linux server draaien met een mysql 4 database. Dat werkt allemaal prima, maar indien er een vliegtuig op het datacenter land of de hdd de geest geeft hebben we toch een klein probleempje omdat we dan de data van die dag kwijt zijn (tenzij het om ~05:00 gebeurt, want dan is backup klaar )

Ik ben dus aan het bedenken hoe we failover van onze linux server voor elkaar gaan krijgen.

Nu heb ik het idee opgevat om de db te laten repliceren naar een failover server op een andere locatie via ssl. Wanneer de primaire server plat gaat om wat voor reden dan ook, is het een kwestie van dns records aanpassen en kunnen onze applicatieservers daar hun data kwijt. Onder andere hier en hier staat prima beschreven hoe het zou moeten werken.
Ik wil nog wel de mysql 4 db gaan upgraden naar versie 5. Dit omdat onze failover server al versie 5 geïnstalleerd heeft staan en ik dan ook via workbench bij die machine kan komen.

Is dit een werkbare, stabiele oplossing of zijn er nog andere mogelijkheden om iets soortgelijks voor elkaar te krijgen?

[FireDrunk]

De database op shared storage draaien? Cluster + heartbeat software installeren en zorgen dat als de een uitvalt de service op de ander gestart word. Loadbalancer ervoor die passive-active draait, en daardoor als 1 server uitvalt de connectie automagisch forward naar de andere actieve server.

Dan hoef je zelf niets meer te doen bij een outage/failure/whatever.

[Standeman]

uhmm, kan je iets langzamer praten, ik ben slechts een eenvoudige developer die gebombardeerd is tot de infrastructuur man

FireDrunk schreef op woensdag 16 februari 2011 @ 09:59:
De database op shared storage draaien?

Wat bedoel je precies met shared storage? Heeft dit iets te maken met replicatie?

Cluster + heartbeat software installeren en zorgen dat als de een uitvalt de service op de ander gestart word.

heartbeat software snap ik, alleen het cluster gedeelte niet echt. Dat betekend toch dat er meerdere machines (vm?) draaien? Op dit moment heb ik maar de beschikking over 2 machines. Dus van een cluster zal niet zo snel spraken zijn (gok ik)

Loadbalancer ervoor die passive-active draait, en daardoor als 1 server uitvalt de connectie automagisch forward naar de andere actieve server.
Dan hoef je zelf niets meer te doen bij een outage/failure/whatever.

Dat hele loadbalancing verhaal is iets waar ik me nog in moet verdiepen. Maar op dit moment zou het al heel wat zijn wanneer ik alleen maar dns records hoef aan te passen

[lier]

FireDrunk schreef op woensdag 16 februari 2011 @ 09:59:
De database op shared storage draaien? Cluster + heartbeat software installeren en zorgen dat als de een uitvalt de service op de ander gestart word. Loadbalancer ervoor die passive-active draait, en daardoor als 1 server uitvalt de connectie automagisch forward naar de andere actieve server.

Dan hoef je zelf niets meer te doen bij een outage/failure/whatever.

Blijf je nog steeds aan één vliegtuig genoeg houden om de hele omgeving onderuit te halen.

[erwinb]

Als je een storage systeem gebruikt op basis van b.v. NFS, b.v. NetApp, dan kan dit systeem deze data voor youw repliceren.
Als er dan een outage is in één van de datacenters, dan is de data ook beschikbaar op de tweede locatie.
Met NetApp kan je een omgeving zo inrichten dat je bij een datacenter outage totaal geen problemen ondervind en de database er dan ook altijd zal zijn.
Ook is het vook voor de performance beter om de database zelf NFS te laten praten met het storage systeem. Oracle noemt dit "Direct NFS" en slaat daarmee het OS over.
Zo'n replicatie werkt synchroon tot ongeveer 100 km, daarboven wordt het a-synchroon, waarbij de delta afhankelijk is van de lijn snelheid en het aantal mutaties op de database.

[ Voor 13% gewijzigd door erwinb op 16-02-2011 13:16 ]

[Freezerator]

Opzich zou replication al moeten doen wat je wil, alleen let wel, het is geen backup. Je laat alles repliceren naar je slave en je hebt een praktische live omgeving klaarstaan. Maar je zal nogsteeds goede backups moeten maken. Immers als je op de master tabellen verwijderd, zal de slave dat braaf repliceren

Wat je anders ook kan doen is met mysqlhotcopy een goede copy maken en die rsyncen met je backup server. Het voordeel van replicatie is dat je een betere restore tijd hebt omdat je niet een volledige backup hoeft terug te zetten.

[ Voor 27% gewijzigd door Freezerator op 16-02-2011 13:24 ]

[--WaaZaa--]

Als het puur over de mysql-cluster gaat: we gebruiken hiervoor zelf Mysql-cluster. Je moet hiervoor wel de huidige mysql server ombouwen. Maar als je dat hebt gedaan, kun je zelfs zonder échte downtime de boel laten draaien.

Je hebt dan meerdere sql en data nodes. Als je hierbij 2 management nodes pakt, zou dit volledig redundant moeten zijn.

[mace]

DRBD is wel nuttig in jouw geval denk ik: http://www.drbd.org/

Dan zorg je er voor dat mysql z'n data op het DRBD-volume opslaat, als 1 van de servers eruitknalt is het automagisch gerepliceerd op de andere.

[CyBeR]

lier schreef op woensdag 16 februari 2011 @ 12:19:
[...]

Blijf je nog steeds aan één vliegtuig genoeg houden om de hele omgeving onderuit te halen.

Nou is 'er stort een vliegtuig op m'n dc' niet iets waar je als gemiddelde organisatie rekening mee moet gaan houden. Bij een dergelijk grote calamiteit is 't voor de meeste bedrijven prima aanvaardbaar om even downtime te hebben. Je moet natuurlijk wel een off-site backup hebben zodat je niet al je data kwijt bent, maar dat is in z'n algemeenheid een goed idee.

[FireDrunk]

Al het bovenstaande komt eigenlijk op hetzelfde neer: Zorg dat de data op een redundante locatie op het netwerk staat. NFS is hiervoor prima te gebruiken. Koop een redelijke zakelijke NAS of een wat duurdere NetApp/EMC om de data van je mysql server op te zetten. Zorg er daarna voor dat je in je OS clustering aanzet (CentOS heeft het ingebouwd dacht ik, van Ubuntu zullen er redelijk wat standaard oplossingen zijn die je met google prima zou moeten kunnen vinden). Nadat je deze software geinstalleerd hebt, regel je in dat als de active node > x-tijd niet gezien word, de MySQL service automatisch op de secundaire node gestart word, en omdat de data op shared storage (op het netwerk) staat, is er geen verlies van data.

Nadeel van dit is dat het x-tijd downtime geeft, voordeel is dat het redelijk goedkoop is.
Duurdere oplossingen leveren je kortere downtime, en redundantie zonder dat je zelf veel hoeft te doen.
Offsite mirroring functies van NetApp's en EMC's zijn erg leuk, maar ook erg prijzig...
Met een beetje handig rsync kan je al een redelijke offsite backup zelf inregelen.

Mocht je echt redundantie over je hele netwerk leggen, zul je zoiets moeten bouwen:

[ Voor 7% gewijzigd door FireDrunk op 17-02-2011 08:43 ]

[real-doc]

Wat ik begrijp van TS, is dat de live beschikbaarheid van de data in geval van een calamiteit niet de hoogste prioriteit heeft. In een calamiteit-situatie is het zoals hijzelf aangeeft geen probleem handmatige acties uit te voeren om het geheel weer live te krijgen. Zolang er maar geen dataverlies optreedt.

Een SAN is natuurlijk een grappig idee, maar de vraag is of minstens 50k aan NetApp hardware en licenties het doel rechtvaardigt. Een SAN heeft in dit geval overigens als bijkomend nadeel dat de replicatie block-based is, waar MySQL replicatie query-based is. Een vliegtuig op een datacenter kan in dit geval bij SAN-based replicatie dan alsnog voor corruptie op de database zorgen. Het SAN heeft immers geen weet van queries, de caching internals van MySQL/OS/filesystem en transacties. Die ziet gewoon blockjes en bytes langsvliegen en repliceert totdat de calamiteit optreedt. Of dat laatste blockje dan vervolgens je database files of filesystem corrupt maakt, maakt het SAN weinig uit.

Daarom denk ik dat TS het beste gewoon voor een simpele MySQL replicatie kan gaan. Mocht je bijvoorbeeld foute queries op je productiedatabase willen afvangen, kan je er ook nog voor kiezen je database geforceerd een aantal seconden/minuten/uren achter te laten lopen in replicatie middels de maatkit tools.

[Verwijderd]

Standeman schreef op woensdag 16 februari 2011 @ 09:56:
Nu heb ik het idee opgevat om de db te laten repliceren naar een failover server op een andere locatie via ssl. Wanneer de primaire server plat gaat om wat voor reden dan ook, is het een kwestie van dns records aanpassen en kunnen onze applicatieservers daar hun data kwijt.

Voor jou situatie is dit een prima oplossing, ik zou ook voor een dergelijke oplossing gaan Shared storage, fiberchannel enzovoort enzovoort is allemaal leuk en aardig, alleen vreselijk duur en met de door jou gestelde eisen totaal zinloos en overbodig.

[AndriesLouw]

Gewoon MySQL zijn ingebouwde master-slave replicatie gebruiken, en bij downtime inderdaad de DNS schakelen naar je slave. Wanneer je master weer online komt, die eerst terug laten repliceren (dus master en slave van rollen laten wisselen).

Als je dan vanuit je applicatie altijd naar je DNS-naam connect, is er niets aan de hand in geval van downtime (wel TTL een beetje laag houden dan).

Let er wel op dat replicatie tussen verschillende versies van MySQL wel eens niet helemaal lekker wil lopen. Zet ook een monitor op je replicatie-status, want het wil soms om gekke redenen nog wel eens uitvallen, zeker in de oudere versies van MySQL.