[MySQL] Sync databases via open source oplossing

[gepebril]

Hallo,

We hebben de volgende uitdaging. We draaien een Linux platform met Asterisk (telefonie) en Open Source (A2)billing software. We beginnen te groeien en willen een hogere uptime bereiken. Onze budgetten zijn helaas niet te groot en moeten daarom roeien met de riemen die we hebben. We willen nu een hot standby gaan realiseren. Een van de zaken die dan gerealiseerd dient te worden is het synchroniseren van de lokale master DB, welke MySQL is. Daar we gebruik maken externe software zoeken we naar een oplossing die de huidige database kan syncen met een client DB (hot standby) zodat we in geval van nood snel over kunnen.
Heeft iemand ervaring met een Open source pakket dat dit via command line zou kunnen doen. Eventuele betaalbare alternatieve oplossingen zijn ook welkom.

Alvast bedankt,

Albert

[xiD]

Dit is gewoon mogelijk in MySQL zelf. Database Replication heet dat.

[gepebril]

Super bedankt. Ga gelijk lezen. Veel ge-Googled, maar kwam dit niet tegen.

[cariolive23]

Weet je zeker dat jouw database-server het grootste risico is? En weet je zeker dat je met jouw beperkte budget en replicatie dat probleem kunt oplossen? Replicatie is leuk, maar kost het veel tijd (en dus geld) om een goed werkend systeem op te zetten. Het is namelijk veel meer dan alleen een 2e database server die luistert naar zijn master, de slave moet ook automatisch de nieuwe master worden wanneer de oude master ermee stopt. Kunnen jouw applicaties deze nieuwe master automatisch vinden? Zo niet, dan heb je niets aan replicatie.

De ervaring leert mij dat 9 van de 10 replicatie-opstellingen niet werken wanneer de poep de ventilator raakt. Wanneer je denkt dat dit bij jou niet het geval is, trek de master database-server dan maar eens op een slecht moment uit het rack en zie de gevolgen. Kleine kans dat gekoppelde applicaties zonder problemen doorwerken.

En wat dacht je van stroom- en/of netwerkstoringen? Zolang je de server op hetzelfde stroom- en/of netwerk hebt zitten, is replicatie ook niet dé oplossing.

Wanneer je maar een beperkt budget hebt, zou ik eerst eens gaan kijken naar goede hardware en de belangrijkste onderdelen dubbel gaan uitvoeren. Database replicatie komt dan later wel.

Ps. Het gebruik van MySQL is al een risico op zich, deze wil zichzelf nog wel eens corrumperen (zie de functie REPAIR, al kan die ook niet alles herstellen). Met een beetje pech werkt dat zelfs door op replica's, dan heb je er al helemaal niets aan. En ja, er bestaan betere databases voor dezelfde licentie-kosten.

[gepebril]

@Cariolive

Bedankt voor je aanvullingen. Ik kan me heel erg vinden in je op en aanmerkingen. Hoewel we onze oplossing hier HOT standby genoemd hebben is het niet zo hot dat het in een paar milisec/minuten over zal gaan, en zeker niet automatisch (helaas), dat zal nu nog onmogelijk zijn. Ik kom uit de IVR wereld dus ik weet wel hoe je uptime vergroot en dat secuur werken een MUST is . We gaan uiteraard met een draaiboek werken en een aantal keren testen. Dat MySQL faalt is mij onbekend, echter we kunnen daar wel iets omheen bouwen denk ik, elke nacht een backup o.i.d. Uiteraard is MySQL niet heilig. Heb wel gezien dat Oracle er ook een potje van kan maken, dus er is geen techniek die 100% werkt, en die zal er denk ik ook wel nooit komen.

Uiteraard zijn er mooie out of the box oplossingen voor een tonnetje, maar dat is nu even net iets te veel van het goede.... En elke 1U unit in een datacenter is ook niet gratis. Maar als je een goed voorstel heb, staan we daar open voor. Roept u maar!

[burne]

cariolive23 schreef op donderdag 05 november 2009 @ 08:38:
Weet je zeker dat jouw database-server het grootste risico is? En weet je zeker dat je met jouw beperkte budget en replicatie dat probleem kunt oplossen? Replicatie is leuk, maar kost het veel tijd (en dus geld) om een goed werkend systeem op te zetten. Het is namelijk veel meer dan alleen een 2e database server die luistert naar zijn master, de slave moet ook automatisch de nieuwe master worden wanneer de oude master ermee stopt. Kunnen jouw applicaties deze nieuwe master automatisch vinden? Zo niet, dan heb je niets aan replicatie.

Dat is triviaal op te lossen met een goedkope machine als loadbalancer. Als je daar geen vertrouwen in hebt kun je er twee neerzetten met HRSP op een switch. Kosten in de orde-grootte van 1500 euro voor twee machines en een switch, of 500 euro voor de enkele machine. En niets weerhoudt je er van oude kantoormachines opnieuw te gebruiken, voor het echte budget-werk.

De ervaring leert mij dat 9 van de 10 replicatie-opstellingen niet werken wanneer de poep de ventilator raakt. Wanneer je denkt dat dit bij jou niet het geval is, trek de master database-server dan maar eens op een slecht moment uit het rack en zie de gevolgen. Kleine kans dat gekoppelde applicaties zonder problemen doorwerken.

Ik heb jaren en jaren ervaring met bovenstaande oplossing. Twee MySQL-servers, twee loadbalancers en een switch. En een tweede systeem van 7 mysql-servers die cyclische replicatie deden. Het opzetten is even uitzoeken, maar eenmaal in de lucht is het kogelvrij.

Ps. Het gebruik van MySQL is al een risico op zich, deze wil zichzelf nog wel eens corrumperen (zie de functie REPAIR, al kan die ook niet alles herstellen). Met een beetje pech werkt dat zelfs door op replica's, dan heb je er al helemaal niets aan. En ja, er bestaan betere databases voor dezelfde licentie-kosten.

Die twee geload-balanced dozen deden tussen de 50 en 500 queries per seconde. Of kijk naar de MySQL-stats van t.net zelf. Zelfs met zulke hoeveelheden queries is corruptie uiterst zeldzaam. Met 2500 databases en in totaal 16Gbyte aan data is me dat in jaren twee keer overkomen. 1 keer bij een verhuizing (waarbij de machine niet goed down gebracht is) en een keer toen er een harddisk doodging en er vlak voor de crash corrupte data gerepliceerd is. Beiden waren in een paar seconden te repareren met verlies van 1 enkel record.

Oh, en MySQL is gratis, net zoals linux. Alleen als je zelf een applicatie of systeem gaat verkopen wat MySQL als component gebruikt moet je betalen. Of als je support wilt.

gepebril:

http://www.howtoforge.com/mysql_database_replication

Als je tweede machine klaar staat moet het een eitje zijn. Als je intern DNS gebruikt is overschakelen van de een naar de ander ook op te lossen. Je noemt je machines bijvoorbeeld mysql1 en mysql2, en maakt in je DNS een CNAME van mysql naar mysql1, met een ttl van 60 seconden. Als je over wilt schakelen naar de ander pas je de CNAME aan zodat 'ie mysql CNAME'd naar mysql2. Een minuut later ben je weer in de lucht.

Als je 'echte' HA wilt zul je naar http://www.linuxvirtualserver.org/ moeten kijken.

Hou in de gaten dat je altijd 1 van de 2 servers gebruikt. Er is geen locking voor replication, dus je kunt verschillen tussen de twee databases vinden op het exacte moment van een insert op je master.

[cariolive23]

@Burne: Tuurlijk, het is allemaal met budget-machines op te lossen, maar of daarmee nu echt de risico's mee laat afnemen? Een server met dubbel uitgevoerde onderdelen (denk aan voeding, schijven, geheugen, netwerkkaarten, etc) kan veiliger zijn en minder kosten. Voor 1500 euro heb je geen replicatie, voor dat geld heb je de manuren nog niet eens betaald. En dan heb je de servers en routers nog niet eens besteld, laat staan betaald.

En misschien is het voor jou triviaal om op te lossen, ik heb niet de indruk dat Gepebril hier ervaring mee heeft. Zo triviaal is het dan niet, het gaat dus meer tijd kosten. Zowel het uitvinden van de juiste opzet, daadwerkelijk opzetten en vervolgens ook nog eens goed testen. Overigens moet je niet vergeten ook de applicatie server dubbel uit te voeren, je hebt er niets aan dat je database keurig is gerepliceerd maar niet kan worden gebruikt omdat de applicatie server op zijn gat ligt. Dan is de replicatie voor niets geweest en heb je een hoop geld verbrand zonder enig rendement er voor te krijgen. Vandaar dat het (zeker met een beperkt budget) handiger is om eerst de basis goed te krijgen en dan pas te gaan kijken naar replicatie. Zonder fatsoenlijk budget, 10k is niets, ga je er weinig mee bereiken.

16GB data klinkt jou wellicht in de oren als veel data, ik heb indexen binnen een database (PostgreSQL) die al van deze orde zijn. En voor 500 queries per seconde hoef je voor een webbased applicatie geen twee servers te nemen, dat kan één server ook wel aan. En dat hoeft echt geen zwaar geschut te zijn.

[burne]

cariolive23 schreef op vrijdag 06 november 2009 @ 20:21:
@Burne: Tuurlijk, het is allemaal met budget-machines op te lossen, maar of daarmee nu echt de risico's mee laat afnemen? Een server met dubbel uitgevoerde onderdelen (denk aan voeding, schijven, geheugen, netwerkkaarten, etc) kan veiliger zijn en minder kosten.

Ik ben nu een jaar of twaalf bezig met hosting. Ik heb in die tijd van alles in m'n handen gehad, van klanten met ikea-stellingen vol met 2de hands bureaumachines tot rack na rack met Sun Netra's in dure datacenters. Gek genoeg scoren bureau-pc's niet veel slechter dan dure hardware. Iedere enkele machine gaat stuk, dus moet je je redundancy niet halen uit dubbele voedingen of dubbele netwerkkaarten. In 12 jaar heb ik een paar (minder dan 5 elk) stukke voedingen en NIC's gezien, en honderden stukke harddisks, RAM en tientallen CPU's.

Voor 1500 euro heb je geen replicatie, voor dat geld heb je de manuren nog niet eens betaald. En dan heb je de servers en routers nog niet eens besteld, laat staan betaald.

Ik ben met opzetten van mysql-replicatie hooguit twee uur bezig. Als de klant de hardware levert kan 'ie voor 300 euro klaar zijn. Als het grote databases zijn is de replicatie dan nog lang niet af, maar, de klant krijgt een mailtje als dat gebeurt is en ik hoef daar niet voor te blijven zitten.

Voor 1500 euro heeft 'ie twee Supermicro's met elk twee harddisks, en een mooie HP switch met HSRP. Als 'ie handig genoeg is om Asterisk aan de praat te krijgen is MySQL replicatie geen probleem, enkel het verwerven van wat nieuwe kennis. Support genoeg, zelfs als je jezelf 'beperkt' tot GoT.

En misschien is het voor jou triviaal om op te lossen, ik heb niet de indruk dat Gepebril hier ervaring mee heeft. Zo triviaal is het dan niet, het gaat dus meer tijd kosten. Zowel het uitvinden van de juiste opzet, daadwerkelijk opzetten en vervolgens ook nog eens goed testen.

Als 'ie de howtoforge-howto volgt heeft 'ie na afloop gewoon replicatie. Het is feitelijk echt zo simpel als een handvol mysql-commando's.

Overigens moet je niet vergeten ook de applicatie server dubbel uit te voeren, je hebt er niets aan dat je database keurig is gerepliceerd maar niet kan worden gebruikt omdat de applicatie server op zijn gat ligt.

Ik zie niets wat je niet met een tweede machine en rsync op kunt lossen, zeker als een paar minuten downtijd geen probleem is. Voor HA is er het eerder genoemde linuxvirtualserver.org maar dan begin je al een behoorlijk parkje te krijgen. Twee loadbalancers, twee asterisk-dozen, twee mysql-dozen, een switch.

Dan is de replicatie voor niets geweest en heb je een hoop geld verbrand zonder enig rendement er voor te krijgen. Vandaar dat het (zeker met een beperkt budget) handiger is om eerst de basis goed te krijgen en dan pas te gaan kijken naar replicatie. Zonder fatsoenlijk budget, 10k is niets, ga je er weinig mee bereiken.

Als je de consultant-route gaat ben je sneller door je geld heen. Gek genoeg zie ik nooit een klein bedrijfje eerst een consultant inhuren en dan alsnog succesvol worden. Succesvol worden doe je door bovenop je weinige kapitaal te blijven zitten. Genoeg voorbeelden. Gepebril's insteek is de juiste. Twee aftandse P4's zijn samen betrouwbaarder dan een Dell van 50K€ en kosten evenveel als de DRAC voor je dure Dell.

16GB data klinkt jou wellicht in de oren als veel data, ik heb indexen binnen een database (PostgreSQL) die al van deze orde zijn. En voor 500 queries per seconde hoef je voor een webbased applicatie geen twee servers te nemen, dat kan één server ook wel aan. En dat hoeft echt geen zwaar geschut te zijn.

16G die gelijktijdig in gebruik is door 2500 klanten, vooral. Da's iets heel anders dan 8G logfile in SQL met een 16G index eronder die sporadisch ingekeken wordt. (En de output van mysqldump is een stuk compacter dan dezelfde database 'live', bijvoorbeeld omdat alle indexen ontbreken.)

Natuurlijk, ik kan zo een oplossing uit m'n mouw schudden die €85.000 euro kost en pas over een paar maanden 'klaar' is, met tientallen vergaderingen waar een stel consultants eindeloos zit te emmeren over de kleur van de website, maar dat is niet wat Gepebril zoekt. Die wil iets simpels, iets wat 'ie zelf kan in een paar uur en wat het overgrote deel van z'n problemen oplost. Dat kan, en het is eenvoudiger en goedkoper dan jij nu doet voorkomen.

En fors met geld strooien levert ook niet altijd het gewenste resultaat op. Ik heb meegemaakt dat een duur, landelijk bekend consultancy- en beheers-bureau de database-servers voor een groot, landelijk bedrijf beheerde. Op een dag komt men erachter dat er nog nooit getest is of de failover wel werkt, dus er gaat een briefje naar de klant. De betreffende medewerker was op vakantie, dus die brief bleef liggen. Vervolgens 'test' men de failover zonder toestemming van de klant. En je raadt het al: het werkt niet, en erger: beide database-servers overleven de test niet intact. Harddisk in de ene, CPU in de ander, na het nodige gepower-cycle. Later die dag is er nieuwe hardware en vervolgens lukt het niet om de laatste backup terug te zetten, dus men moet terugvallen op de voorlaatste volledige backup. In een database waarin 30 procent van de entries in een week veranderd, dus enorme problemen en kosten die pas na maanden opgelost waren. En meer dan 2.5 dag downtijd. Waarvoor ruim meer dan een miljoen per jaar betaald werd, en wat met 99.999% garanties geleverd werd.

[cariolive23]

Ik ben met opzetten van mysql-replicatie hooguit twee uur bezig. Als de klant de hardware levert kan 'ie voor 300 euro klaar zijn.

Nou, neem contact op met Gepebril en regel het voor hem! Is hij voor weinig geld klaar en heb jij een leuk klusje erbij.

Op een dag komt men erachter dat er nog nooit getest is of de failover wel werkt, dus er gaat een briefje naar de klant. De betreffende medewerker was op vakantie, dus die brief bleef liggen. Vervolgens 'test' men de failover zonder toestemming van de klant. En je raadt het al: het werkt niet, en erger: beide database-servers overleven de test niet intact.

En dit is precies wat ik al vele malen heb gezien, replicaties die niet leiden tot grote uptime. Men denkt een goed systeem te hebben, maar de eerste de beste fout laat pijnlijk zien dat e.e.a. niet werkt zoals het zou moeten werken. Zelfs als er is getest blijkt dat er is uitgegaan van een ideale situatie, de situatie die je natuurlijk niet in de praktijk aantreft. Vandaar mijn grote bedenkingen bij "even replicatie introduceren", de praktijk valt vies tegen. Hopelijk kun jij wel leveren wat je belooft, ik heb het nog maar zelden aangetroffen.

En ja, ik ga ook al even mee in de IT, zowel beheer, testen als dba-werkzaamheden behoren/behoorden tot mijn werkzaamheden. Mijn ervaring: failover werkt slechts zeer zelden zoals je dat in gedachten had.

16G die gelijktijdig in gebruik is door 2500 klanten, vooral. Da's iets heel anders dan 8G logfile in SQL met een 16G index eronder die sporadisch ingekeken wordt.

16G die in gelijktijdig in gebruik is door 2500 klanten, staat grotendeels in RAM. Dat is razendsnel en niets bijzonders.

Overigens wel bijzonder dat jij weet hoe onze indexen worden gebruikt, tot voor kort was mijn huidige opdrachtgever daar niet eens van op de hoogte!

[GlowMouse]

burne schreef op vrijdag 06 november 2009 @ 22:49:
[...]

Ik heb meegemaakt dat een duur, landelijk bekend consultancy- en beheers-bureau de database-servers voor een groot, landelijk bedrijf beheerde. Op een dag komt men erachter dat er nog nooit getest is of de failover wel werkt, dus er gaat een briefje naar de klant. De betreffende medewerker was op vakantie, dus die brief bleef liggen. Vervolgens 'test' men de failover zonder toestemming van de klant. En je raadt het al: het werkt niet, en erger: beide database-servers overleven de test niet intact. Harddisk in de ene, CPU in de ander, na het nodige gepower-cycle. Later die dag is er nieuwe hardware en vervolgens lukt het niet om de laatste backup terug te zetten, dus men moet terugvallen op de voorlaatste volledige backup. In een database waarin 30 procent van de entries in een week veranderd, dus enorme problemen en kosten die pas na maanden opgelost waren. En meer dan 2.5 dag downtijd. Waarvoor ruim meer dan een miljoen per jaar betaald werd, en wat met 99.999% garanties geleverd werd.

De server voor T-mobiles belstatus?

Recent is hierover een artikeltje verschenen: http://www.mysqlperforman...-%E2%80%93-the-questions/

[burne]

cariolive23 schreef op vrijdag 06 november 2009 @ 23:14:
En dit is precies wat ik al vele malen heb gezien, replicaties die niet leiden tot grote uptime.

Maar hier is wel precies gedaan wat je voorstelt. Er is fors met geld gesmeten, er zijn een stel dure Sun dozen, met een Sun SAN eronder, met een taperobot, met Oracle MAA, met dure admins, aangestuurd door dure consultants die jaren werk geleverd hebben. En toch is het resultaat nul.

Twee hardware failures en een corrupte backup (die keurig als 'failed' gemeld was, maar niet opgemerkt) in een omgeving die zo intensief gebruikt wordt dat meer dan een paar uur downtijd een serieus probleem is.

En alle fouten zijn met -in verhouding tot de kosten- relatief kleine investeringen en procedures te ondervangen.

Men denkt een goed systeem te hebben, maar de eerste de beste fout laat pijnlijk zien dat e.e.a. niet werkt zoals het zou moeten werken. Zelfs als er is getest blijkt dat er is uitgegaan van een ideale situatie, de situatie die je natuurlijk niet in de praktijk aantreft. Vandaar mijn grote bedenkingen bij "even replicatie introduceren", de praktijk valt vies tegen.

12 jaar harde praktijk. Ik heb een brand in m'n datacenter nog niet meegemaakt, maar verder kun je het zo gek niet verzinnen en ik ken het uit ervaring. Soms is een duidelijke handleiding en twee gelabelde kabeltjes beter dan 10k€ overmaken op de bankrekening van een consultancy-boer. (in mijn kringen vaak 'insultancy' genoemd)

Pragmatiek is een stuk handiger dan met geld smijten en er maar het beste van hopen.

[cariolive23]

burne schreef op zaterdag 07 november 2009 @ 00:12:
Maar hier is wel precies gedaan wat je voorstelt.

Is dat zo? Ik stel het hele idee van replicatie ter discussie, ik stel niet voor om met grof geld te gaan smijten. Dat je het voor een appel en een ei niet gaat redden, dat mag ook duidelijk zijn, ook uit jouw voorbeeld: Er moet budget zijn om e.e.a. goed en volledig te testen.

En toch is het resultaat nul.

Precies, dat heb ik al veel te vaak gezien. En of je er nu veel of weinig geld tegenaan gooit, zorg eerst maar eens voor een goede basis en ga dan nog eens denken aan zoiets als replicatie.

Soms is een duidelijke handleiding en twee gelabelde kabeltjes beter dan 10k€ overmaken op de bankrekening van een consultancy-boer. (in mijn kringen vaak 'insultancy' genoemd)

Uiteraard zijn goede handleidingen noodzakelijk, die horen zelfs bij beheer en dus ook bij replicatie.

En waarom jij verwijst naar een consultancy-boer, geen idee, dat is niet mijn idee en levert in elk geval geen complete oplossing.

Moraal van mijn verhaal: Replicatie is niet dé oplossing voor een betere beschikbaarheid. Zorg eerst voor een stabiele basis, zoek je zwakke schakels en ga deze dan één voor één versterken. En dan kan het zijn dat er een database moet worden gerepliceerd, maar dat zal zelden de eerste stap zijn. Ook niet wanneer het mode lijkt te zijn om aan databasereplicatie te doen.

[ Voor 15% gewijzigd door cariolive23 op 07-11-2009 07:22 ]

[gepebril]

Hartelijk dank heren voor jullie mening!. Heerlijk toch dat je oplossingen krijgt vanuit verschillende perspectieven. En zo lekker ver uit elkaar, prachtig.
Heb het idee dat iedereen zijn Hypo moet betalen en daarvoor verschillende strategieën bewandelt
Heb het beste gevoel, gezien o.a. de situatie met de ideeën van Burne. Houdt wel van zijn ongezouten mening. Dat zouden meer mensen moeten doen.
- Replicatie is een van de onderdelen die moet gebeuren, daarnaast ook veel bewaking middels mijn geliefde Perl. Wat is het toch heerlijk om robotjes te programmeren die de boel monitoren. En netjes gaan werken.

Ga het allemaal even rustig doorlezen en dan mijn conclusies trekken.

[gepebril]

@Burne,

Nog bedankt voor het advies. We hebben besloten de Master MySQL database te gaan replicaten. Echter wat we ook doen bij

code:

LOAD DATA FROM MASTER;

Blijven we steeds de volgende foutmelding krijgen:

code:

ERROR 1218 (08S01): Error connecting to master: Master is not configured

Googlen hierop leverde geen geen oplossing, we hopen dat er een tweaker raad gaat weten.

[Boudewijn]

Tijd voor configjes tonen ... Met name die van de master .

[cariolive23]

gepebril schreef op dinsdag 01 december 2009 @ 02:21:

code:

LOAD DATA FROM MASTER;

Weet je zeker dat je op het goede pad zit? Dit kom ik tegen in de handleiding:

This feature is deprecated and should be avoided. It is subject to removal in a future version of MySQL.

Je bent dus bezig met functies die verdwijnen, straks werkt het dus niet meer.

Een ander probleem is het volgende:

It works only for MyISAM tables.

Als er één engine is die de neiging heeft om corrupt te raken... Wanneer jouw data zo onbelangrijk is, waarom zou je dan eigenlijk met replicatie willen gaan werken?

Gebruik mysqldump voor het laden van data, werkt voor alle engines en is niet achterhaald.

[gepebril]

@ Cariolive,

Bedankt voor de tips. Ik zal het gaan proberen met de MySQL dump. Op papier leek de load data from master een mooie functie.......
Data is wel belangrijk, maar ja met een dergelijke uitspraak begint de hele discussie opnieuw. We hebben een weg ingeslagen en die volgen we voorlopig even. Als we meer klanten krijgen gaan we het nog beter doen.