[MySQL] Replicatie (twee weg)

[Pinkelmans]

Wij zitten met een probleem:

We hebben een masterdatabase waarmee meerdere programma's werken. Om de uptime te garanderen , zullen de gegevens uit deze database ook lokaal opgeslagen worden in een database; mocht de server er uit vallen (wat niet onwaarschijnlijk is in deze omgeving met veel stroomstoringen), kunnen de clients nog door werken.

Het probleem is alleen als volgt:

De gegevens van de server naar de client krijgen is 'eenvoudig' via een replicatie. Het echte probleem zit hem alleen in:

Stel, de server is een week er uit, en de klanten voegen nieuwe gegevens toe. Deze worden lokaal opgeslagen. Als de server online komt, moeten deze weer naar de server gaan. Ik zag een oplossing staan door middel van circulaire replicatie, maar aangezien het (niet/nooit) duidelijk is op welke clients de software draait en waar deze berijkbaar is, lijkt me dit niet mogelijk.

Een oplossing die wel zou kunnen werken, is, lokaal de veranderingen bij te houden en deze "handmatig" door de aplicatie terug te laten schrijven. Is dit de enige oplossing of heeft iemand een idee van iets anders?

Door de snelle verandering van het aantal clients die op elk moment kan gebeuren, vind ik (tot nu toe) nog geen bijpassende oplossing op GoT, mysql.com of via google. De oplossing van het handmatig doorvoeren zou kunnen werken, maar geniet niet de voorkeur..

[The Eagle]

Eigenlijk heel simpel, maar wel doeltreffende: zorgen dat clients alleen inserts kunnen doen en geen updates als de server niet in de lucht is. Betekent wel dat je hier met je clientsoftware rekening mee moet houden en dat iig (een stuk van) de metadata van de DB op de client aanwezig moet zijn ivm datamodel. Wanneer de DB dan weer on line komt, kunnen alle inserts gedaan worden. Gebruik er desnoods temptables op de DB zelf voor. Evt daaruit voortvloeiende transacties kun je dan m.b.v. de mastertabellen op basis van de temp tables alsnog uitvoeren.
Ik weet echter niet of de clientsoftware al geschreven is, en of dit dus nog tot de mogelijkheen behoort

[Pinkelmans]

The_Eagle schreef op vrijdag 08 september 2006 @ 17:27:
Eigenlijk heel simpel, maar wel doeltreffende: zorgen dat clients alleen inserts kunnen doen en geen updates als de server niet in de lucht is. Betekent wel dat je hier met je clientsoftware rekening mee moet houden en dat iig (een stuk van) de metadata van de DB op de client aanwezig moet zijn ivm datamodel. Wanneer de DB dan weer on line komt, kunnen alle inserts gedaan worden. Gebruik er desnoods temptables op de DB zelf voor. Evt daaruit voortvloeiende transacties kun je dan m.b.v. de mastertabellen op basis van de temp tables alsnog uitvoeren.
Ik weet echter niet of de clientsoftware al geschreven is, en of dit dus nog tot de mogelijkheen behoort

De clientsoftware moet nog volledig ontwikkeld worden; we zijn druk bezig met het ontwerpen van de modellen en lopen (daardoor) tegen dit soort problemen aan. Opzich klinkt deze oplossing al erg logisch en hadden we al een oplossing voor de auto_inc gevonden; via de auto_increment_increment en auto_increment_offset, welke goed implementeerbaar moet zijn.
Bedankt in ieder geval, en zodra het niet werkt (of juist wel ) zal ik het laten weten.

[LauPro]

De MySQL-replicatie is een beetje bout. En dan spreek ik het nog zacht uit. Er zijn natuurlijk wel mogelijkheden alleen met de master-slave setup is er niet echt een garantie dat de slaves sync blijven. Indien een slave niet sync meer is (hij was uit oid) dan moet je de complete master-database opnieuw 'downloaden' naar de slave. Wat dus zeer veel traffic/load tot het gevolg heeft. Daarnaast worden de binlogs bij veel traffic ook zeer groot (+extra diskaccess). Soms kan je vanaf de laatste binlog de slave syncen, maar die binlogs kan je niet eeuwig bewaren over het algemeen.

De circulaire replicatie is ook niet echt handig imo. Dit is naar mijn idee een meer theorische vorm. Stel je hebt een pool van 4 databaseservers. Dan kan je met deze circulaire de data tussen de servers exchangen. Bijkomend probleem is dat elke databaseserver een andere offset moet aanhouden voor auto_increment. Voor zover ik weet zijn er op dit moment geen goede tools beschikbaar om dit in goede banen te leiden en dit is niet iets wat je handmatig bij wil gaan houden, trust me. Min of meer verplicht is wel dat alle databaseservers dezelfde specs hebben en ook allemaal een goede verbinding tussenling (als in: liefst in hetzelfde rack/op dezelfde switch).

Op dit moment zie ik de meeste mogelijkheden in 1 hele goede databaseserver. Waarvan de hardware dermate goed is dat deze niet zomaar uit valt. Afhankelijk van de capaciteit die je nodig hebt, bijv dual of quad core server met een goed disksystem (en minimaal 1 spare disk). Kost wel wat maar dan heb je wel een machine waar je op kan bouwen. (Maar ook dat ligt aan de eisen die je hebt, storage etc.)

Natuurlijk met je hardwareleverancier een contract afsluiten dat als er iets door fikt ze binnen x minuten ter paatsen zijn, afhankelijk van hoe 'enterprisy' het is. Maar dan zou ik ook meteen naar MySQL stappen voor professionele support.

[ Voor 4% gewijzigd door LauPro op 08-09-2006 18:03 ]

[Pinkelmans]

LauPro schreef op vrijdag 08 september 2006 @ 18:01:
Indien een slave niet sync meer is (hij was uit oid) dan moet je de complete master-database opnieuw 'downloaden' naar de slave. Wat dus zeer veel traffic/load tot het gevolg heeft. Daarnaast worden de binlogs bij veel traffic ook zeer groot (+extra diskaccess). Soms kan je vanaf de laatste binlog de slave syncen, maar die binlogs kan je niet eeuwig bewaren over het algemeen.

Dit zal dus inderdaad het grootste probleem zijn; aangezien de clients misschien 3 uur per dag connectie zullen hebben...

Op dit moment zie ik de meeste mogelijkheden in 1 hele goede databaseserver. Waarvan de hardware dermate goed is dat deze niet zomaar uit valt. Afhankelijk van de capaciteit die je nodig hebt, bijv dual of quad core server met een goed disksystem (en minimaal 1 spare disk). Kost wel wat maar dan heb je wel een machine waar je op kan bouwen. (Maar ook dat ligt aan de eisen die je hebt, storage etc.)

Natuurlijk met je hardwareleverancier een contract afsluiten dat als er iets door fikt ze binnen x minuten ter paatsen zijn, afhankelijk van hoe 'enterprisy' het is. Maar dan zou ik ook meteen naar MySQL stappen voor professionele support.

De hardware is momenteel aanwezig en is ruim voldoende. Ook is het het één en ander qua UPS aanwezig. Helaas is het elektriciteitsnetwerk hier (Curaçao) vrij gevoelig, waardoor regelmatig dingen doorbranden of uitvallen. Laatst was internet voor 2 weken weg ivm een doorgebrande modem; reserve onderdeel moest overgevlogen worden uit de USA.... Zou voor het systeem niet echt al te prettig zijn, mocht niemand er meer mee kunnen werken. Vandaar dat we dus het liefst lokaal ook een kopie opslaan, maar zo te horen geeft dit veel problemen.

[LauPro]

Oke, maar is het dan niet verstadiger om de applicatie bijv. in de VS of in NL te hosten? Dan moet je ervoor zorgen dat er op elke locatie 2 verbindingen aanwezig zijn. Kijk en voor het energieprobleem zijn natuurlijk oplossingen met accu's en een aggregaat. Maar dat ligt er allemaal aan wat het mag kosten. Of zijn de problemen meer bij de toeleveranciers van connectivity? Want van een SPOF-corerouter zou ik er altijd nog 1 op de plank willen hebben of een back-up verbinding (tenzij de fabriekant bepaalde garanties heeft).

[Pinkelmans]

LauPro schreef op vrijdag 08 september 2006 @ 19:13:
Oke, maar is het dan niet verstadiger om de applicatie bijv. in de VS of in NL te hosten? Dan moet je ervoor zorgen dat er op elke locatie 2 verbindingen aanwezig zijn. Kijk en voor het energieprobleem zijn natuurlijk oplossingen met accu's en een aggregaat. Maar dat ligt er allemaal aan wat het mag kosten. Of zijn de problemen meer bij de toeleveranciers van connectivity? Want van een SPOF-corerouter zou ik er altijd nog 1 op de plank willen hebben of een back-up verbinding (tenzij de fabriekant bepaalde garanties heeft).

Veel opties zijn inderdaad mogelijk, maar het budget is erg beperkt. Even wat achtergrondinformatie: wij zijn twee stagairs die vrijwillig werken voor een organisatie die de hulpverlening in Curaçao probeert te organiseren enzo. Het is wel handig dat de informatie 24/7 aanwezig is, mits dit met de aanwezige midellen (en misschien kleine uitbreidingen) mogelijk is. Vandaar dat we dachten aan een lokale database op elke pc; dit kost qua aanschafkosten niks extra. De server en het netwerk hier is ook meer dan we hadden kunnen verwachten, alleen de conectiviteit naar buiten toe en de stroomvoorzieningen zijn erg varierend.

[LauPro]

Met een database zou ik erg oppassen als er veel power blackouts zijn. Mijn ervaring met MySQL is dat MyISAM en InnoDB daar nogal slecht mee om gaan omdat die veel in het geheugen cachen.

Als het echt low-budget moet blijven zou ik zeggen download elke nacht de database naar het lokale werkstation. En zorg ervoor dat in je applicatie een scheiding maakt tussen UPDATE/DELETE/INSERT en SELECT-queries. Dus eigenlijk tussen read en write. Afhankelijk van of de centrale (externe) database beschikbaar is kan je dus wel updaten en anders alleen gegevens bekijken.

Maar ook dan zou ik in het belang van de integriteit van de gegevens er toch voor pleiten om die centrale database iig extern te hosten bij bijv. een Nederlandse provider.

Er zijn niet echt veel 'out-of-the-box' tussenoplossingen beschikbaar voor hetgeen jij zoekt. Je wil eigenlijk een gespreide database met transacties die je elk moment weer kan mergen. Ik zou bijna zeggen kijk eens naar subversion aangezien je dat wel 'offline' kan gebruiken. Maar dat is natuurlijk geen database maar een filebase.

[Verwijderd]

Ik wil hier even op inhaken.

Toch blijkt met auto_increment_offset het best goed te werken, backups maak je van beide machines dus dat is best op te lossen.

Je kunt de auto_increment_offset prima handmatig managen volgens mij... je zet het namelijk 1x per machine en je moet gewoon een logische manier van offset houden. Server1 = 10/1 en Server2 = 10/2... etc.

Je kunt het beter wel doen dan maar backuppen en weer terug zetten. Die backups maak je toch wel en je kunt beter online blijven dan plat gaan Dan maar even plat wanneer je de boel moet syncen, anders wat je helemaal uit de lucht geweest.


Zo, dit typte is snel en was moe... ik sta niet voor de gevolgen in