Database synchronisatie

[Verwijderd]

Ik heb een probleem.

Ik heb een server met een MySQL database waar online clients gebruik van maken. Deze clients moeten ook offline kunnen functioneren. Echter wanneer de clients niet meer op het internet zitten kunnen zij uiteraard niet meer gebruik maken van deze database, wat wel nodig is.

Zelf zat ik te denken aan een tool die constant updates stuurt naar een locale database op de clients. Wanneer een client dan offline gaat beschikt die over een redelijk recente versie.

De client moet, ook als hij offline staat, gegevens kunnen toevoegen aan de database. Als de client dan weer online komt, zou hij de nieuwe gegevens moeten overzetten naar de server zonder dat er duplicaten ontstaan.

Watvoor tool/applicatie/oplossing kan ik hier het best voor gebruiken?

Alvast bedankt!

[Xanland]

Replicatie, dat zit standaard ingebouwd in MySQL (dacht ik). Is genoeg informatie over te vinden op de website van MySQL.

[cariolive23]

@Xanland: Standaard replicatie gaat hierbij niet helpen, je hebt met multi-master te maken en dus een split brain op het moment dat niet kan worden gerepliceerd. De uitdaging zit hem in het ontdekken van conflicten (record A die zowel op master X als master Y is bijgewerkt maar 2 verschillende waardes heeft) en het maken van de juiste keuzes bij de beslissing welke waarde nu de juiste waarde is.

Ik ken geen tools die dit probleem oplossen.

[urk_forever]

Je zou eens naar het Microsoft Sync Framework kunnen kijken.

Ik weet alleen niet of dat ook met MySQL werkt en of het beschikbaar is voor de taal die je gebruikt.

[Verwijderd]

De client moet bij het toevoegen leidend zijn. Zijn gegevens moeten over de gegevens van de server heen.

Het probleem is ook dat ik met id's werk als primary key. Voor bijvoorbeeld de tabel student loopt dit id door (auto increment) als er een student door een andere online client toegevoegd wordt. Wanneer er dus offline ook een student toegevoegd wordt en deze client komt online dan moet de toegevoegde student een nieuw id krijgen van de server.

[Verwijderd]

Ik ga btw naar Microsoft Sync Framework en Replicatie kijken.

Alvast bedankt voor de tips!

[EvilWhiteDragon]

De ID's maken op zich niet echt uit toch?
Dus dan kan je die gewoon neit mee copieren, dat wordt dan door de auto increment wel opgelost.

[Tjolk]

Dat op zich wel, maar als er in tussentijd verwezen wordt naar die ID's (in links bijvoorbeeld), komen die verkeerd uit.

[Janoz]

Verwijderd schreef op dinsdag 21 juli 2009 @ 12:47:
De client moet bij het toevoegen leidend zijn. Zijn gegevens moeten over de gegevens van de server heen.

Het probleem is helemaal niet dat de cleitn leidend moet zijn, maar welke client leidend moet zijn.

Ik heb het gevoel dat je de werkelijke problemen die op gaan treden nog lang niet allemaal onderkent hebt. Ik wil je daarom dan ook aanraden om nu nog niet gelijk de technische oplossing in te duiken, maar eerst eens de functionele eisen op gaat stellen. Probeer eerst eens verschillende situaties te bedenken en bepaal vervolgens hoe die situaties afgehandeld zouden moeten worden.

[Janoz]

EvilWhiteDragon schreef op dinsdag 21 juli 2009 @ 12:53:
De ID's maken op zich niet echt uit toch?
Dus dan kan je die gewoon neit mee copieren, dat wordt dan door de auto increment wel opgelost.

Nooit je ID's gaan aanpassen. Daarmee haal je je meer problemen op de hals dan dat je oplost.

Wat veel handiger is is om elke client een range kandidaat ID's te geven waaruit ze hun ID mogen halen. Op die manier kun je nooit conflicten krijgen.

[cariolive23]

Voor bijvoorbeeld de tabel student loopt dit id door (auto increment)

Dat gaat mogelijk problemen opleveren, verschillende databases zullen dezelfde id's uitgeven voor verschillende records.

Tip: Gebruik een UUID, die is ook over meerdere databases uniek.

[Verwijderd]

Janoz schreef op dinsdag 21 juli 2009 @ 12:57:
[...]

Het probleem is helemaal niet dat de cleitn leidend moet zijn, maar welke client leidend moet zijn.

Ik heb het gevoel dat je de werkelijke problemen die op gaan treden nog lang niet allemaal onderkent hebt. Ik wil je daarom dan ook aanraden om nu nog niet gelijk de technische oplossing in te duiken, maar eerst eens de functionele eisen op gaat stellen. Probeer eerst eens verschillende situaties te bedenken en bepaal vervolgens hoe die situaties afgehandeld zouden moeten worden.

Ik wilde alleen eerst een klein vooronderzoek doen naar de technische mogelijkheden. Ik ga idd nog de verschillende mogelijke situaties uitschrijven en hoe deze afgehandeld moet worden.

[Verwijderd]

Janoz schreef op dinsdag 21 juli 2009 @ 12:59:
[...]

Wat veel handiger is is om elke client een range kandidaat ID's te geven waaruit ze hun ID mogen halen. Op die manier kun je nooit conflicten krijgen.

Lijkt me ook een mooie oplossing.

[Verwijderd]

cariolive23 schreef op dinsdag 21 juli 2009 @ 13:01:
[...]

Dat gaat mogelijk problemen opleveren, verschillende databases zullen dezelfde id's uitgeven voor verschillende records.

Tip: Gebruik een UUID, die is ook over meerdere databases uniek.

Ik ga ernaar kijken, dank!

[Janoz]

Dan werk je verkeerd om. Hoe kun je immers de technische randvoorwaarden opstellen wanneer je nog niet eens weet wat je functioneel verwacht?

[FragFrog]

SFB schreef op dinsdag 21 juli 2009 @ 12:55:
Dat op zich wel, maar als er in tussentijd verwezen wordt naar die ID's (in links bijvoorbeeld), komen die verkeerd uit.

Dat kun je deels met foreign keys oplossen, maar ook dan blijft het een heel erg naar en vervelend probleem; stel de server ligt er even uit, alle clients gaan vrolijk door met updaten, server komt weer online en vervolgens krijg je twee clients die tegelijkertijd hetzelfde record willen wijzigen. Nu voorkomt je engine dat dit fout gaat, maar stel client A doet een update waarna er een nieuw ID gecreerd wordt. Die client gebruikt dit als ID voor een andere insert. In de tussentijd doet client B ook een update waardoor het ID weer veranderd en de net geinserte entry van client A verwijst ineens naar een rogue ID. Bij enkel inserts zal dit goed gaan als je guid's gebruikt of elke client een eigen range geeft, maar als je een relationele table gaat updaten kon dit nog wel eens erg naar worden.

Een mogelijke oplossing is je gehele database te locken aan het begin van de transactie zodra een client update - als je zorgt dat de gehele update eerst beschikbaar is op de server is dit nog te doen. Bouw in je clients een check in dat ze offline blijven werken totdat ze aan de beurt zijn om de server te updaten dan valt de wachttijd ook mee, al zal elke update wel voor haperingen gaan zorgen bij de reeds online clients. Gooi je een replicated slave aan je master DB vast voor selects valt ook dat weer te overzien, afhankelijk van hoeveel updates / inserts er gaan zijn.

Overigens is dat alles een behoorlijke zut werk, afhankelijk van de applicatie kun je ook overwegen een ander datamodel te hanteren - als de client ook tevreden is met enkel lokale data, of er slechts een enkele tabel gedistribueerd hoeft te worden zou je het een stuk simpeler kunnen aanpakken door bijvoorbeeld een master zonder ID's en met wat unique keys te gebruiken

[Janoz]

cariolive23 schreef op dinsdag 21 juli 2009 @ 13:01:
[...]

Dat gaat mogelijk problemen opleveren, verschillende databases zullen dezelfde id's uitgeven voor verschillende records.

Tip: Gebruik een UUID, die is ook over meerdere databases uniek.

Een UUID zou ik pas overwegen wanneer er vanuit de requirements echt geen centraal orgaan is. Persoonlijk vind ik dat er veel te snel naar UUID's gegrepen wordt terwijl er vaak ook betere oplossingen beschikbaar zijn. Zeker in het geval van de topicstarter, waarbij er nog steeds een duidelijke centrale server is en enkel het probleem opgevangen moet worden van clients die af en toe geen verbinding hebben, zijn er veel efficiëntere methoden denkbaar.

[cariolive23]

Zeker in het geval van de topicstarter, waarbij er nog steeds een duidelijke centrale server is

Klopt, maar de diverse clients (aantal = onbekend) zijn leidend. Hoe wil je dan veilig id's gaan reserveren? Zonder duidelijke beschrijving van de situatie kan ik alleen maar concluderen dat een auto_increment onbruikbaar is. Een UUID is dan een goed en bruikbaar alternatief, ook wanneer dit niet de ideale oplossing is. Het kost wat extra opslagruimte, maar daar ga je niet aan dood.

Af en toe geen verbinding, ik vraag het me af wanneer ik bovenstaand verhaal lees.

De TS zal eerst een goed beeld moeten krijgen van de functionele eisen, dan kunnen er pas goede en vooral bruikbare oplossingen bij worden gezocht.

[Koopmans]

http://symmetricds.codehaus.org/ is een opensource tool die ook zoiets doet.

[leuk_he]

FragFrog schreef op dinsdag 21 juli 2009 @ 14:06:
[...]

Dat kun je deels met foreign keys oplossen, maar ook dan blijft het een heel erg naar en vervelend probleem; stel de server ligt er even uit, alle clients gaan vrolijk door met updaten, server komt weer online en vervolgens krijg je twee clients die tegelijkertijd hetzelfde record willen wijzigen. Nu voorkomt je engine dat dit fout gaat,
... verhaal over ID....

Even afgezien me nog niet duidelijk is WELKE engine...(heeft topic starter wel een op replicatie/clusteropslosisngen gegoogled?) Je zult toch regels moeten maken wat er gebeurd als 2 clients een conflicteerend record gaan updaten. Dit zul je in code/applicatie moeten bouwen. Je kunt ook stellen dat de laatste leidend is en/of dit niet zal voorkomen is maar je kunt er van op aan dat de gebruiker niet dat gedrag verwacht.

8 van de 10 keer zie je hier ook een zelfgebouwde oplossing voor, al dan niet aan de hand van een framework.

[Janoz]

cariolive23 schreef op dinsdag 21 juli 2009 @ 14:31:
[...]

Klopt, maar de diverse clients (aantal = onbekend) zijn leidend. Hoe wil je dan veilig id's gaan reserveren? Zonder duidelijke beschrijving van de situatie kan ik alleen maar concluderen dat een auto_increment onbruikbaar is. Een UUID is dan een goed en bruikbaar alternatief, ook wanneer dit niet de ideale oplossing is. Het kost wat extra opslagruimte, maar daar ga je niet aan dood.

Er zijn meer dan twee keuzemogelijkheden. Zoals ik eerder al aangaf kun je elke client ranges geven waaruit de ID's gehaald kunnen worden. De enige zorg die je dan nog hebt is om elke client genoeg beschikbare ID's te laten hebben zodat ze kunnen 'overleven' tot ze weer verbinden. Bij UUID is de kans op collisions oneindig klein, terwijl de kans bij deze implementatie 0 is.

[Janoz]

leuk_he schreef op dinsdag 21 juli 2009 @ 14:40:
Je zult toch regels moeten maken wat er gebeurd als 2 clients een conflicteerend record gaan updaten. Dit zul je in code/applicatie moeten bouwen. Je kunt ook stellen dat de laatste leidend is en/of dit niet zal voorkomen is maar je kunt er van op aan dat de gebruiker niet dat gedrag verwacht.

En dit is nu precies wat ik bedoel met het nog niet de techniek in duiken, maar eerst eens functioneel bepalen wat je nu eigenlijk verwacht. Wil je gewoon de laatste wijziging leidend laten zijn. Wil je een conflict foutmelding en het handmatig op laten lossen (niet in de DB, maar een GUI die laat mergen).

Maar wat dacht je bijvoorbeeld van het verkopen van een item? Moet 1 verkoop order ongedaan gemaakt worden? Maar wat als er nu nog wel vooraad is en er dus gewoon een ander geleverd kan worden?

Allemaal vragen die eerst beantwoord moeten worden voor er ook maar een letter code in een IDE getikt mag worden.

[FragFrog]

leuk_he schreef op dinsdag 21 juli 2009 @ 14:40:
Even afgezien me nog niet duidelijk is WELKE engine...(heeft topic starter wel een op replicatie/clusteropslosisngen gegoogled?) Je zult toch regels moeten maken wat er gebeurd als 2 clients een conflicteerend record gaan updaten.

Zowel MyISAM als InnoDB locken in dat geval de database (MyISAM de gehele table, InnoDB enkel de row die je gaat updaten), dus als twee clients dezelfde row willen updaten zal de een op de ander wachten. De TS gaf aan MySQL te gebruiken, voor zover ik weet zijn MyISAM en InnoDB de meest gebruikte engines hiervoor en ik ga er stiekem vanuit dat de andere engines ook wel een dergelijk mechanisme hebben

MySQL replicatie is geen optie voor de TS: dat werkt enkel als de slave niet veranderd (aangezien het feitelijk een dump + geparsed transactie-log is). Voor zover ik weet ondersteunt MySQL geen echte clustering als MSSQL / Oracle to name a few, of althans niet zover dat je het in een productie-omgeving wilt toepassen, al kan ik dat mis hebben

[ Voor 19% gewijzigd door FragFrog op 21-07-2009 15:18 ]

[cariolive23]

Bij UUID is de kans op collisions oneindig klein, terwijl de kans bij deze implementatie 0 is.

Klopt, je krijgt er alleen andere problemen voor in de plaats. Het is dan afhankelijk van de situatie welk probleem de minste gevolgen heeft, een collision of een client die niet meer door kan werken.

Tot zover de theorie laat ze eerst maar eens de functionele eisen opstellen.

[leuk_he]

FragFrog schreef op dinsdag 21 juli 2009 @ 15:16:
[...]

Zowel MyISAM als InnoDB locken in dat geval de database

Ik dacht dat je over replicatie engine (~framework) had. ... nu al over storage enigen gaan praten heeft geen meerwaarde.

MySQL replicatie is geen optie voor de TS: dat werkt enkel als de slave niet veranderd

Ja, in de meest standaard situatie heb je gelijk. echter met filtering zou je toch verder kunnen komen dan je denkt.

[FragFrog]

leuk_he schreef op dinsdag 21 juli 2009 @ 15:28:
Ik dacht dat je over replicatie engine (~framework) had. ... nu al over storage enigen gaan praten heeft geen meerwaarde.

offtopic:
Ben ik met je eens, daarom had ik het er ook niet expliciet over en noemde het slechts in passing

[Janoz]

cariolive23 schreef op dinsdag 21 juli 2009 @ 15:18:
[...]

Klopt, je krijgt er alleen andere problemen voor in de plaats. Het is dan afhankelijk van de situatie welk probleem de minste gevolgen heeft, een collision of een client die niet meer door kan werken.

Eens, ik wilde alleen aangeven als een mogelijkheid, niet de mogelijkheid. Er zijn meer wegen die naar rome leiden met elk zo hun voor en nadelen.

Tot zover de theorie laat ze eerst maar eens de functionele eisen opstellen.

Eens

[Hydra]

Janoz schreef op dinsdag 21 juli 2009 @ 14:49:
Er zijn meer dan twee keuzemogelijkheden. Zoals ik eerder al aangaf kun je elke client ranges geven waaruit de ID's gehaald kunnen worden. De enige zorg die je dan nog hebt is om elke client genoeg beschikbare ID's te laten hebben zodat ze kunnen 'overleven' tot ze weer verbinden. Bij UUID is de kans op collisions oneindig klein, terwijl de kans bij deze implementatie 0 is.

Waarom is dit efficienter dan een GUID? Hedendaagse databases maakt 't echt geen fluit uit of je met een GUID (2^128) of een long int (2^64) werkt. Bovendien zit de functionaliteit om die te genereren in elke database en platform ingebakken. GUIDs zijn precies voor dit soort zaken bestemd.

[Janoz]

(Vanaf) hier is er wel een aardige discussie over de GUID/UUID

[MySQL]Auto increment recount

Waarbij ik wel op wil merken dat het toepassen van GUID in dat topic, itt het probleem in het huidige topic, complete onzin is.