PDA

Bekijk Volledige Versie : MYSQL 5 master master



davhog
31/07/08, 17:03
Heren Experts,

We hebben een webapplicatie draaien waar high availability erg belangrijk is. Alle data zit in een MYSQL 5 (5.0.32-Debian_7etch5-log) database. De database wordt m.b.v. een master-master setup gerepliceerd. De applicatie server connect altijd met de MYSQL database op localhost. We verbinden met MYSQL via de UNIX socket.

Dit alles draait super lekker totdat er een keer een hikje in de kabel tussen de twee datacentra komt. De mysql slave status geeft dan een connection error. Dit is logisch omdat er geen verbinding is. Minder logisch is dat de applicatie op dat moment errors begint te geven dat er geen verbinding met de socket gemaakt kan worden.

In Google kan ik hier heel weinig over vinden. Heeft iemand van jullie dit probleem wel eens gehad? Is er een oplossing voor?

Wido
01/08/08, 09:36
Gebruik je hiervoor de NBD tabellen of een andere setup?

bami82
01/08/08, 09:56
Gebruik je hiervoor de NBD tabellen of een andere setup? Neem aan dat je NDB bedoeld? Volgens mij is bij master/master of master/slave innodb een must. Zowieso is het af te raden NDB over een WAN te gebruiken.

Je applicatie zou nog gewoon moeten werken en nadat de hickup weg is zou alles weer netjes automatisch moeten repliceren (enzo niet dan is er nog altijd maatkit :-) )

Staat er iets in je mysql log files?

davhog
01/08/08, 11:31
@wido,

Geinig om ook via deze weg ondersteuning te krijgen van onze provider. (we huren een rack bij jullie in PCX ruimte 2)

Het is geen cluser-setup en gebruiken dus niet de NDB engine. We repliceren gewoon alle databases heen er weer. De gebruikte engine is 'plain old' MyISAM.

Logging staat tot op heden uit. (performance killer) Dat wordt inderdaad stap 2 in mijn onderzoek. Daar moet ik binnenkort een nachtje voor gaan zitten.

Ik begin een beetje het vermoeden te krijgen (onderbuik) dat het probleem is opgelost door te connecten naar localhost i.p.v. de socket. Dit zal ik ook testen tijdens deze nacht. De resultaten zal ik hier zeker even posten.

Had stiekem gehoopt dat iemand hier dit probleem al eerder had meegemaakt en had geroepen dat los je zo en zo op... Bij nader inzien is dit probleem hier misschien iets te specifiek voor.

Wido
01/08/08, 11:33
Ik vraag me even af hoe je een Master <> Master setup met MyISAM voor elkaar hebt gekregen, maar ala.

Welke foutmeldingen krijgen de clients zodra de setup down gaat? Table not found of andere spannende errors?

Welke MySQL foutcode is het?

davhog
01/08/08, 12:05
Het maakt MYSQL bij replicatie niet zo veel uit welke table engine er gebruikt wordt. Sterker nog het schijnt mogelijk te zijn op de slave een andere engine te gebruiken dan de master. (durf ik niet aan overigens)

Zie: http://dev.mysql.com/doc/refman/5.0/en/replication-solutions-diffengines.html

Het draait tot nu toe boven verwachting snel en stabiel, op deze vervelende bug na.

MYSQL geeft gelukkig geen vreemde foutmeldingen maar de client kan gewoon geen verbinding maken met de slave als de master even weg is. Omdat beide clients zowel master als slave zijn kan op beide servers de database niet meer bereikt worden.

Wido
01/08/08, 14:00
Dat is apart, wat als je op de console met het mysql commando wil verbinden, wat krijg je dan?

davhog
01/08/08, 15:05
Dat heb ik niet geprobeerd.

Toen de applicatie geen verbindingen kon maken heb ik in blinde paniek een /etc/init.d/mysql restart uitgevoerd.
Dit gaf foutmeldingen die ik niet meer exact weet (waarschijnlijk failed ofzo), maar mysql was hierna wel weer te benaderen.

Ik ga dit binnenkort op een moment dat er geen klanten aan het werk zijn even reproduceren om nader te onderzoeken wat er wel en niet mogelijk is en welke foutmeldingen ik hier krijg.

Ik zal mijn bevindingen hier plaatsen.