[MySQL] Het repliceren van een Master <> Master opstelling

[Verwijderd]

Ik ben een beetje "redundant-minded" aan het worden en heb me dus verdiept in Loadbalancing. Ik moet persoonlijk zeggen dat het LoadBalancing best naar mijn zin gaat met 2 machines, maar je loopt uiteraard vast op het clusteren van 2 mysqlservers die je daar lokaal op zou kunnen draaien.

Ik probeer dit dus, waarbij je zou kunnen zeggen dat je het beste één DB-server in zou kunnen richten met een "slave". Uiteindelijk kun je dus ook zeggen dat je op één van de 2 servers de master draait en op de andere de slave.

Dit is een goed idee ! Echter erg tricky qua failover tussen beide machines. Mijn idee was dus om te kijken of het veel besproken "master<>master" idee nu echt zo zou kunnen werken in de praktijk als men denkt.

Ik heb wat voorbeelden kunnen vinden via Google waarbij het mensen gelukt is, het is dus mogelijk, echter twijfel ik een beetje. Ik gebruik zelf nu MySQL 4.0.26 (ja moet geupdate worden) en bij MySQL 5 is het mogelijk om 2 masters + 1 Slave te gebruiken.

Ik wil geen slave, maar ik wil master<>master Nu kwam ik een idee van iemand tegen die een master<>master-replicatie opstartte met een 3e server en wanneer het cluster draaide, de 2e wegnam. OK, het is een idee, maar verre van handig natuurlijk. Als er iets even hapert heb je al een probleem en kun je weer overnieuw beginnen.

Ik heb tot nu toe de handleiding gevolgd op MySQL.org: http://dev.mysql.com/doc/refman/4.1/en/replication.html

Dit is allemaar best duidelijk, alleen heb ik een probleem met mijn "REPLICATION SLAVE ON" waar ik gewoon "GRANT ALL" van met maken wil ik wat kunnen, maar dit is even een bijzaak.

Ok, hiermee kun je dus een master-slave opstelling maken. Je kunt ook een master-master maken door beide servers elkaar clients te maken. (hier wordt het tricky naar mijn idee).

Aangezien dit "ticky" is dacht ik aan het volgende:

Je maakt een Master-slave opstelling met HeartBeat wat een script start dat de slave een master wordt en hier ook naar geschreven kan worden op het moment dat de master uit zal vallen.

Ook weer zijn nadelen denk ik. Een master<>master lijkt mij gewoon het makkelijkste waar er op beide systemen naar haar eigen MySQL-server wordt geschreven. De DB's dan onderling syncroniseren lijkt me dan de mooiste oplossing.

Ik begreep hier op het forum dat de mannen van Parse hier ook een probleem hebben met het redundant uitvoeren van een MySQL-DB. op Linux-HA.org hoop ik nog wat extra informatie te vinden, maar wil hier ook eigenlijk de vraag wel stellen of iemand hier goede ervaringen mee heeft.

[Verwijderd]

Op werk zijn wij nu ook aan het kijken naar de clustering mogelijkheden met MySQL... De standaard NDB clustering die in MySQL 5.0 zit is voor ons totaal niet interessant, voornamelijk doordat de database in-memory zijn op de storage nodes. Met een stuk of 50 databases die 10Gb kunnen worden hebben we dan enorm veel geheugen op de storage nodes nodig, of zo veel storage nodes dat het gehele plaatje ineens wel erg duur word.

Daarom zijn we nu aan de slag gegaan met het bouwen van een cluster op basis van replicatie. Helaas is de replicatie van MySQL erg beperkt waardoor we ook weer tegen een hoop problemen aanlopen.

Officieel ondersteund MySQL alleen one-way replicatie; single master - multiple slave. Echter willen we natuurlijk geen single master in een cluster. Daarom hebben we tussen 2 servers een two-way replicatie opgezet (beide servers zijn master en slave van elkaar). Dit word eigenlijk niet door MySQL ondersteund maar het werkt opzich prima.

Een risico waar je tegenaan loopt bij deze opstelling is dat theoretisch data overschreven kan worden als er schrijf bewerkingen op beide servers plaatsvinden, bijvoorbeeld als user1 een update query doet op server-A op een record en user2 doet tegelijkertijd een andere update query op hetzelfde record maar dan op server-B dan is 1 van de users zijn data kwijt. Hierdoor kan er maar op 1 server in de cluster insert/updates gedaan worden. Beide server kunnen wel tegelijkertijd gebruikt worden voor lees queries...

De cluster is voorzien van heartbeat met daarop 2 resource ip adressen, 1 adres word gebruikt voor de insert/updates zodat deze alleen op de master node uitkomt. Het tweede resource ip adres hangt aan de backup node en via IPVS word MySQL geloadbalanced tussen beide servers, op dit adres mogen dus alleen lees (SELECT) queries uitgevoerd worden. Update/insert etc. queries moeten op het andere ip adres plaatsvinden zodat schrijfbewerkingen maar op 1 database tegelijkertijd uitgevoerd worden.

Indien de master dus offline gaat neemt de backup node het 'write ip address' over zodat schrijf bewerkingen op de databases op de backup node gaan plaatsvinden. Als de master weer online komt word alle data gerepliceerd en word de master weer de actieve node voor schrijfbewerkingen.

Op deze manier hebben we failover en zijn de lees bewerkingen op de databases ge-loadbalanced, in ons geval zijn de zwaarste bewerkingen toch lees bewerkingen waardoor het niet erg is dat schrijfbewerkingen niet geloadbalanced zijn.

[Verwijderd]

Zeer duidelijk verhaal, mijn dank.

Het probleem dat ik echter ga krijgen wanneer ik het op jullie manier ga doen is dat ik vastloop op het feit dat er nog steeds een slave is, waarom ?

Ik draai op beide machines dezelfde applicaties die beide naar localhost connecten. Ik kan dus moeilijk van Reource-IP gaan wisselen met HeartBeat.

Bij mij zou heartbeat dus de ini-files van de applicaties om moeten zetten van zodat server 2 die naar server 1 als master connecte (1=master dan) ineens naar Localhost gaat connecten.

Ik laat het even bezinken.. kan vast wel