Synchronisation zwischen Datenbanken - Ideen?

[Sir Rufo]

Der Hashwert ist zwar ganz nett, aber dann muss jeder Client die gesamten Hashwerte vom Server laden, vergleichen und dann den passenden Datensatz nochmals vom Server holen.
Das mag bei wenigen Datensätzen und Clients funktionieren ... aber wenn die Anzahl Datensätze/Clients zunimmt kann man sich auch schön die Bandbreite damit verhageln.

Hier meine Vorschläge zur Synchronisation mit minimalem Overhead:

Zeitstempel

Der Client fragt beim Server alle Datensätze ab, die neuer als der letzte Zeitstempel sind.
Von diesen Daten wird der aktuellste Zeitstempel (vom Server vergeben) als letzter Zeitstempel beim Client gespeichert (nicht die Uhrzeit der letzten Abfrage!)

Hauptproblem bei der Synchronisierung via Zeitstempel bleibt aber die Auflösung des Zeitstempels.
Ein MySQL Server schafft ja (je nach Hardware) mehr als einen Datensatz pro Millisekunde zu speichern.
xxx1 Client A schreibt Datensatz
xxx2 Client B bekommt die Datensätze geliefert (höchster Zeitstempel xxx)
xxx3 Client A schreibt Datensatz
Bei der nächsten Abfrage bekommt Client B aber nicht den 2. Datensatz von A geliefert, denn dieser Datensatz hat ja auch den Zeitstempel xxx obwohl er nach der Abfrage von Client B geschrieben wurde.

Somit müsste also die Abfrage nicht Zeitstempel > xxx lauten, sondern Zeitstempel >= xxx.
Damit bekommt man aber wieder ein entsprechenden Overhead, den man evtl. vermeiden möchte/muss.

Ein Ausweg aus diesem Zeitstempel-Dilemma geht dann nur über

Update-Liste pro Client

In einer Update-Tabelle werden alle Änderungen der Haupt-Tabelle auf dem Server (per Trigger) in diese Update-Tabelle eingetragen. Der Client fragt mit dieser Tabelle die Datensätze ab und löscht dann die verarbeiteten Sätze aus der Tabelle.

Dadurch hat man dann auch das Weitergeben von Löschsätzen charmant gelöst, denn diese können sofort aus der Haupttabelle entfernt werden.
Müssen mehrere Tabellen synchronisiert werden, dann eben den Tabellen-Namen mit in die Update-Tabelle, oder eine UUID als ID verwenden.

Code:

ClientID PK
RecordID PK
DeleteFlag

[BUG]

Noch eine Zeitstempel-Variation:

Die Daten werden nur mit einem Server synchronisiert und damit kann der eine "Zeit" festlegen: Die Anzahl der bereits erfolgten Synchronisationen.

Angenommen der Server hat eine Zeit von 1337 und der Client wurde zuletzt bei 17 synchronisiert.

• Wenn ein Datensatz (z.B. ein Eintrag auf der Löschen-Liste) auf dem Client angelegt wird, wird sein Zeitstempel auf Null gesetzt (daher: nicht synchronisiert).
• Nun lädt der Client alle Datensätze von Server herunter, die einen größeren Zeitstempel als 17 haben.
• Die mit Null beschrifteten Datensätze sendet er nun an den Server und sie bekommen auf Client wie Server den Zeitstempel 1338.
• Der Server hat nun die Zeit 1338 und der Client ist auch auf Stand von 1338.

Nett wäre hier, wenn nicht ein anderer Client gleichzeitig auch versucht zu synchronisieren.

[gmc616]

Hmm ... das "Update-Liste pro Client"-Konzept ist auch eine Lösung.
Allerdings muß hier geklärt sein, welche DB die Master-DB stellt.

Wenn ich den TO richtig verstanden habe, wird auf beiden DBs aktiv gearbeitet.
Die Synchronisation muß also in beiden Richtungen stattfinden. Und da kommt man an einem Zeitstempel nicht vorbei. Allzumal die Synchronisation nicht zeitgleich passiert sondern mit Sicherheit in bestimmten zeitlichen Intervallen.

Wie soll man verhindern, das z.B. Online ein Termin gelöscht und gleichzeitig (im gleichen Zeitintervall) der selbe Termin lokal nur verschoben wird. Oder auch umgekert. Das sind zwei unterschiedliche Vorgänge auf ein und die selbe Information (sprich Datensatz)!

Selbst ein Mischen und Sortieren der Updatelisten beider DBs kann zu Datenverlust führen.

Löschen von Datensätzen, die mit anderen DB's Synchronisiert werden sollen, halte ich daher immer für einen schlechte Idee. Eine Löschmarkierung ist hier der bessere Weg.

Ich glaube grundsätzlich kann man sagen, dass das Synchronisieren von zwei (oder mehreren) DBs immer ein Problem darstellt und sollte immer von Anwendungsfall zu Anwendungsfall neu überdacht werden.

Meines Erachtens ist es das wichtigste, das Termine (Datensätze) auf allen DBs einen eindeutigen ID besitzen, damit man sie jederzeit identifizieren kann.

Zitat von BUG:

Nett wäre hier, wenn nicht ein anderer Client gleichzeitig auch versucht zu synchronisieren.

Das definitiv.

[Sir Rufo]

Die Update-Liste braucht man eigentlich nur auf dem Server, da dort die ausstehenden Änderungen pro Client gespeichert sind.
Gut so eine Tabelle kann der Client auch führen, dann ist das Handling der gelöschten Sätze einfacher.

Einen Timestamp sollte man bei der Haupttabelle haben.

Ein Löschen kann generell nicht verhindert werden, wenn das Löschen möglich sein muss.
Wie wäre denn der Fall, wenn alle an einem Server arbeiten?
Der Datensatz ist weg.

Selbiges gilt für das Ändern von Datensätzen, da gewinnt die letzte Änderung.
Um die herauszufinden benötigt man den Timestamp vom Client.

Und da wartet schon die nächste Hürde:
Am Client wird die Uhrzeit 3h vor gestellt und schon würden alle jetzt gemachten Änderungen gewinnen.

Das ist aber auch schon fast ein anderes Thema.
Hier ging es ja zunächst um die Sicherstellung, dass alle Objekt repliziert werden

[FredlFesl]

Für eindeutige IDs würde ich eine GUID nehmen. Ohne die geht es nicht.

Die Tabelle der durchgeführten Änderungen (eingefügt, gelöscht, verändert) als Basis für den Synchronisationsprozess ist schon richtig.
Wenn Du dann noch Konflikte behandelst (Änderungen widersprechen sich), bist Du fertig.
Ein Konflikt tritt z.B. dann auf, wenn der eine einen Datensatz löscht, ein Anderer den gleichen DS zwischenzeitlich jedoch verändert hat.
Oder beide verändern ein und das selbe Feld eines DS.

Du kannst hier entweder nach dem Prinzip "Last one wins" vorgehen, oder Du implementierst eine Konfliktbehandlung ("DS xy wurde von Schulze am BLABLA verändert, aber von Ihnen am BLABLUB gelöscht"). Da beim ersten Fall Datenänderungen unbemerkt verschwinden können, würde ich eine Konfliktbehandlung ("reconcile") implementieren. Das ist übrigens das sog. "briefcase model".

Um solche Konflikte sicher erkennen zu können, könntest Du dir merken, "wann" (und vom wem) ein Feld zum letzten Mal geändert wurde. Liegt dieser Zeitpunkt NACH deinem letzten Abgleich (und du hast diesen DS/Feld) verändert, liegt ein Konflikt vor.

Konfliktbehandlungen bekommst Du auch in den Griff, wenn Du dir eine Kopie der DB ("Original") nach erfolgter Synchronisation erstellst und vor der nächsten Synchronisation die Daten mit dieser DB-Version vergleichst: Hat sich ein zu ändernder Datensatz (Von 'A' nach 'B') zwischenzeitlich verändert, war die Änderung nicht exklusiv, es liegt dann also ein Konflikt vor. Du vergleichst also jeden DS VOR dem Abgleich mit dem Original. Damit erkennst Du zwar Konflikte, nicht jedoch, WER der Konfliktpartner ist.

Ich würde den ersten Weg wählen: Man hat auch eine sehr mächtige Änderungshistorie, was bei Geschäftsdaten nicht unerheblich ist. Du kannst dann auch Fragen beantworten, wie: "Wer hat denn damals den Ansprechpartner von Fa. Halmackenreuther geändert".