Onderwerp: Multi-Master Replication, ervaringen?

Wat misschien ook van belang is om te melden is dat multi master replicatie niet echt voordeel biedt als je veel updating queries hebt (update, delete, insert). Die moeten altijd op alle machines worden uitgevoerd en zorgt dus niet of amper voor loadbalancing.

Replicatie is dus eigenlijk alleen zinvol om je SELECTs te loadbalancen.

Daarnaast, als je semi-synchronous replicatie aan zet, en je 2 masters zitten ver van elkaar kunnen updating queries ook nog eens erg traag worden. Semi-synchronous replicatie zorgt ervoor dat de betrouwbaarheid van de replicatie verbeterd, maar zorgt dus voor extra delay in je updating queries.

maatkit (tegenwoordig percona toolkit) heeft goede monitoring tools. Besef goed dat een master-master een stuk complexer is dan een master-slave opzet, het is belangrijk je goed af te vragen of de extra complexiteit (en daarmee mogelijke storingen/problemen) opwegen tegen het voordeel dat een master tijdelijk niet bereikbaar is.

Houd er overigens ook rekening mee dat als je gebruikt maakt van een offset voor het autoincrement probleem je goed na moet denken over je primary keys welke autoincrement gebruiken. Je kunt bijvoorbeeld denken aan factuurnummers die nu vertrouwen op een autoincrement. Deze zullen dan ineens niet meer opvolgend zijn, waardoor je problemen kunt krijgen op administratief vlak...

Ik heb zowel goede als slechte ervaringen met een multi master setup van MySQL. Bij ons heeft het jaren goed en stabiel in productie gedraait, bij een anderen daarentegen is het al een paar keer flink mis gegaan. Data-loss, handmatig moeten resetten van bin files, noem maar op.

Toevallig ben ik reeds bezig geweest met MySQL (plus wsrep plugin) en Galera. Tot nu toe bevalt het erg goed. Het is stabiel en alle queries worden letterlijk op beide systemen tegelijk uitgevoerd. Een nadeel is echter dat Galera alleen tabellen met InnoDB ondersteund. Ik weet niet in hoeverre dat belangrijk is bij jullie? Wellicht een idee om er eens naar te kijken!

http://www.bytebot.net/blog/archives...oli-sennhauser

Oorspronkelijk geplaatst door Yourwebhoster

Je bent al op de hoogte van de auto increment problemen bij master-to-master replicaties?

Daarvoor geef je iedere MySQL server natuurlijk een offset (leesvoer http://www.neocodesoftware.com/replication/). Wij hebben probleemloos een Master/Master omgeving draaien, bovendien hebben beide masters ook nog eens een eigen read-only slave voor snelle leesacties (bijvoorbeeld voor backups erg handig). Monitor je servers wel erg goed, je wilt geen volgelopen harde schijven of iets dergelijks. Een cluster goed opzetten is niet moeilijk, maar onderhoud is natuurlijk veel belangrijker. Wij gebruiken Nagios om de replicatie te monitoren (en de rest van de server natuurlijk ook). Af en toe is een server wat druk en loopt de replicatie iets achter, dit herstelt zich meestal vanzelf. Het komt ook wel eens voor dat replicatie stuk gaat doordat er toch een duplicate key is, maar dat is simpel op te lossen door de replicatie een stap te laten skippen (meer leesvoer http://www.howtoforge.com/how-to-rep...ql-replication).

Oorspronkelijk geplaatst door BReady

Ik heb zowel goede als slechte ervaringen met een multi master setup van MySQL. Bij ons heeft het jaren goed en stabiel in productie gedraait, bij een anderen daarentegen is het al een paar keer flink mis gegaan. Data-loss, handmatig moeten resetten van bin files, noem maar op.

Dat ben ik met je eens, maar dat ligt meestal toch aan de beheerder. Maar toegegeven dat het af en toe overmacht is. De fout die ik het meeste heb gezien is dat bij problemen te snel in paniek geraakt wordt en commando's worden uitgeprobeerd om het maar zo snel mogelijk te herstellen. Ik kan alleen maar adviseren om jezelf zoveel mogelijk thuis te laten voelen in de hele materie en wellicht een testomgeving te bouwen om mee te spelen (maak het eens stuk en probeer het eens te fixen)

Vergeet ook niet dan je master/master over het algemeen gebruikt voor redundantie (zodat je bij een storing niet hoeft te gaan kloten met het promoten van slaves), niet om te schalen voor (write) performance.
Je kunt wel iets performancewinst boeken maar niet out-of-the-box. Zolang je een single thread hebt die voor de replicatie zorgt, zal je systeem nooit sneller worden dan die single thread.

Natuurlijk kun je de masters ook gebruiken voor de reads dus op die manier haal je wel iets extra speed, maar ook hierbij heb je hetzelfde probleem als bij een gewone master/slave: schrijven op A en hetzelfde direct lezen op B blijft tricky.

Als je het niet out-of-the-box gebruikt en je code aanpast om goed gebruik te maken van de 2 masters, kun je overigens wel veel profijt hebben van een m/m setup waarbij je lekker zonder downtijd 1 van de 2 kunt downgooien voor even wat onderhoud.

Bedankt voor alle reacties dusver. Nee, performance is echt niet waar wij het voor doen. Dan is een master - master - slave setup misschien nog iets.

We gebruiken 2 master-master setups.
En het bevalt tot op heden goed.

1 van de master-master setups word gebruikt voor een php beheer systeem die zowel online als op locatie bij de klant draait.
beide versies moeten ten alle tijden blijven werken waarbij de klant versie voorang heeft.
De online versie checkt of de klant versie online is. zo niet dan gaat het systeem voor het grootste gedeelte op read-only.
Zodra de klant terug komt dan is de server binnen enkele minuten weer ingelopen en alles loopt weer netjes.

de 2de setup is voor een administratie systeem waarbij we geen downtime willen (en ook nooit hebben gehad) ook niet als 1 van de 2 servers offline gaat.

Maar om alles goed in te stellen is one hell of a job. veel testen en goede monitoring zijn hierbij de keywords.
Het monitoren van de master-master setups doen wij ook met nagios (wat een pracht systeem dat nagios).

Als beschikbaarheid de belangrijkste reden is kun je ook een mysql failover cluster maken met DRBD en heartbeat. DRBD synchroniseert de wijzigingen op disk op blokniveau naar de cluster member, zodat mysql bij failover direct de juiste data heeft. Er zijn op internet aardig wat howtos te vinden om dit te doen. Is erg stabiel en je hoeft je niet druk te maken over problemen met synchronisatie. Eventueel zou je voor backup nog een slave kunnen draaien en daar de backups op doen.