nicht angemeldet
Partielles Backup: Geänderte DB-Datensätze erkennen
0 0 
Auge
Partielles Backup: Geänderte DB-Datensätze erkennen
Hallöle,
parallel zu meinem Problem, neuere Dateien auf einen Ersatz-Server zu übertragen (Zeitstempel bei Dateien) möchte ich auch neuere Datensätze von einer Quellen-DB zur Ziel-DB übertragen.
Jeder Datensatz hat ein Feld last_modified (ON UPDATE CURRENT_TIMESTAMP).
Nun hole ich mir pro Tabelle den aktuellsten last_modified aus beiden Datenbanken und weiss, ob ich ins Detail gehen muss oder eine Übetragung überflüssig ist.
Das Konzept klappt nur, wenn die Ziel-Datenbank nicht berührt wird. Sie ist für den Fall vorgesehen, dass der Hauptserver ausfällt.
Wie könnte ein Konzept aussehen, wenn auch auf der Ziel-DB gearbeitet wurde?
Wie funktioniert eigentlich die "Synchronisation" von Dateien im PC, wenn ich einen USB-Stick einstecke?
Wird da ganz plump die aktuellste Datei zum "Partner" übertragen und dessen ältere Änderungen zerschossen? Bedeutet Synchronisation, den Älteren platt zu machen?
Lieben Gruß, Kalle_B
-
Hallo Kalle,
Das Konzept klappt nur, wenn die Ziel-Datenbank nicht berührt wird. Sie ist für den Fall vorgesehen, dass der Hauptserver ausfällt.
Wie könnte ein Konzept aussehen, wenn auch auf der Ziel-DB gearbeitet wurde?Replikation nutzen.
Wie funktioniert eigentlich die "Synchronisation" von Dateien im PC, wenn ich einen USB-Stick einstecke?
Wird da ganz plump die aktuellste Datei zum "Partner" übertragen und dessen ältere Änderungen zerschossen? Bedeutet Synchronisation, den Älteren platt zu machen?
das hängt von der verwendeten Software und gegebenenfalls den konfigurierten Optionen dieser Software ab.
Freundliche Grüße
Vinzenz
-
Hallo Vinzenz,
Replikation nutzen.
Mache ich wohl schon. Der Ersatzserver sagt dem Hauptserver sein letztes last_modified, und der Hauptserver sendet alle IDs, die er hat. Und zu den neueren auch die Daten.
So kann der Ersatzserver erkennen, welche Sätze er löschen muss (er hat eine ID, der Hauptserver aber nicht) und welche zu übernehmen sind.
Klappt soweit ganz gut, auch mit Zeitdifferenzen kein Problem (wie bei den DAteien), weil der last_midified bisher ja immer vom Hauptserver stammt.
Wenn auf dem Ersatzserver auch gearbeitet werden darf, kommt die verflixte Zeitsynchronisation dazu, die ich bisher nicht lösen konnte. Wenn schon filemtime von Dateien Probleme macht (Zeitstempel bei Dateien), was weiss ich denn, was Server in das Feld last_modified eintragen.
Wikipedia:
"Von synchroner Replikation spricht man, wenn eine Änderungsoperation an einem Datenobjekt nur dann erfolgreich abgeschlossen werden kann, wenn sie auch auf den Replikaten durchgeführt wurde. Um dies technisch umsetzen zu können, ist ein Protokoll zur Gewährleistung der Atomarität (Unteilbarkeit) von Transaktionen anzuwenden, das Commit-Protokoll."Eigentlich eine gute Idee, aber wenn einer der beiden Server ausgefallen ist, kann man auch auf dem anderen nicht mehr arbeiten, die Abhängigkeit wird um 100% grösser.
Klar, da muss man dann wieder die Ausnahme programmieren, geht mir aber im Moment zu weit.
Kalle
-
Hallo Vinzenz,
weisst du, ob ich mich darauf verlassen kann, dass ON UPDATE CURRENT_TIMESTAMP _nicht_ greift, wenn ich dem Feld last_modified einen Wert (vom Hauptserver) zuordne?
Oder wird dieser Wert durch die aktuelle Zeit ersetzt?
Bisher war der "alte", also kopierte Wert drin. Aber das kann ja auch Zufall der derzeitigen MySQL-Version sein. Oder gibt es da eine klare Regel?
Kalle
-
-
-
Hallo
Hallöle,
parallel zu meinem Problem, neuere Dateien auf einen Ersatz-Server zu übertragen (Zeitstempel bei Dateien) möchte ich auch neuere Datensätze von einer Quellen-DB zur Ziel-DB übertragen.
Jeder Datensatz hat ein Feld last_modified (ON UPDATE CURRENT_TIMESTAMP).
Nun hole ich mir pro Tabelle den aktuellsten last_modified aus beiden Datenbanken und weiss, ob ich ins Detail gehen muss oder eine Übetragung überflüssig ist.
Soweit, so logisch.
Das Konzept klappt nur, wenn die Ziel-Datenbank nicht berührt wird. Sie ist für den Fall vorgesehen, dass der Hauptserver ausfällt.
Wenn die Zieldatenbank auf dem Sekundärserver nur dazu da ist, als Backup zu dienen, also im Bedarfsfall die Daten zurück zu spielen, sollten dort, außer bei den Backups selbst, keine Änderungen anfallen. Wird der Sekundärserver mitsamt der dortigen Datenbank aber in Benutzung genommen, falls der Primärserver ausfällt, können dort die Datensätze verändert sein, also einen aktuelleren Stand als die auf dem Primärserver haben (wie auch dein nächster Absatz nahe legt).
Wie könnte ein Konzept aussehen, wenn auch auf der Ziel-DB gearbeitet wurde?
Sowohl der Primär- als auch der Sekundärserver könnten mit einer Synchronisationstabelle ausgestattet werden. Dort würden die Synchronisationszeitpunkte, Datenbank- und Tabellennamen und Datensatz-IDs, die von einer Synchronisation betroffen sind, hinterlegt. Bei einer neuen Synchronisation können nun diese Daten mit den in den Datensätzen hinterlegten Zeitpunkten der letzten Aktualisierung verglichen werden.
Werden Aktualisierungen von Datensätzen *nur* auf einem der beiden Server vorgenommen, was bei deinem Szenario der Normalfall sein dürfte, liegt auf dem betreffenden System der Aktualisierungszeitpunkt später (oder nicht) als der Synchronisationszeitpunkt und es steht eine erneute Synchronisation des Datensatzes an (oder nicht). Dabei könnte allenfalls dein automatisch gesetztes Aktualisierungsdatum stören ("bei Aktualisierung Datum neu setzen" bedeutet auch, bei Synchronisationen das Datum neu zu setzen).
Sollte der Fall auftreten, dass eine Aktualisierung nach der letzen Synchronisation, aber vor dem Ausfall des Primärservers vorgenommen wird und zudem, während des Ausfalls des Primärservers, auf dem Backupsystem (Sekundärserver) ebenfalls eine Aktualisierung vorgenommen wurde, sind natürlich beide Aktualisierungszeitpunkte jünger als der letzte Synchronisierungszeitpunkt. Das wäre, um den Vergleich zu ziehen, in einem Versionierungssystem ein Konflikt, der gemeldet und händisch aufgelöst werden müsste.
Tschö, Auge
--
Verschiedene Glocken läuteten in der Stadt, und jede von ihnen vertrat eine ganz persönliche Meinung darüber, wann es Mitternacht war.
Terry Pratchett, "Wachen! Wachen!"
Veranstaltungsdatenbank Vdb 0.3-
Hello,
mit Transaktionszeitpunkten zu arbeiten ist immer kritisch.
Besser ist es, ein vollständiges Transaktionslog zu führen (was MySQL z.B. mit seinem Binary Log schon unterstützt) und eindeutige Transaktionsnummern zu vergeben. Dabei muss es zwangsweise einen Master und einen Slave geben, wobei sich die Rolle aus der Transaktionsnummer ergibt. Derjenige Server, der die höhere Transaktionsnummer führt, ist der Master. Soll auf dem Slave eine Transaktion durchgeführt werden, muss dieser erst die fehlenden Transaktionen nachholen.
Erst, wenn er dies durchgeführt hat, darf er eigene Transaktionen zulassen, die dann wiederum tunlichst vom anderen Server nachgeholt werden müssen.
Durch Mutex-Flags (das von einer dritten Stelle geführt werden könnte) wird sichergestellt, dass beide Serversysteme dieselben Regeln berücksichtigen.
Am einfachsten lässt sich solch ein System (mit MySQL) bereitstellen, wenn man alle (datenverändernden) Transaktionen ausschließlich über stored Procedures abwickelt und den APIs überhaupt keinen (datenverändernden) Direktzugang auf die Datenstrukturen ermöglicht.
Liebe Grüße aus dem schönen Oberharz
Tom vom Berg
-