Zwei Systeme abgleichen

[Yeti]

Hallo Forum!

Ich stehe hier gerade völlig auf dem Schlauch mit meinem Problem, habe mich auch schon mit Kollegen beratschlagt, aber keine Lösung scheint befriedigend.

Hintergrund: Wir haben hier zwei Systeme auf PHP/MySQL-Basis, das eine ("System A") läuft im Internet für unsere Außenstellen (nur DSL), das andere ("System B") im Intranet (weil z.B. auch die gesamte Abrechnung darüber läuft). Bisher wurden die Fälle im System A auch in diesem abgerechnet und die Rechnungen dort erstellt. Problematisch ist nur, dass die Funktionalität doppelt vorhanden ist in System A und B und auch entsprechend gewartet werden muss. Zudem läuft der gesamte Webzugriff hier über einen konzernweiten Proxyserver in Frankreich und daher sind besonders zur Mittagszeit (Pausenzeit = Surfzeit) die Antwortzeiten unerträglich.
Daher wollen wir jetzt die Abrechnung komplett in System B vollziehen.

So weit, so gut. Ich habe mir jetzt überlegt, ich ziehe nächtlich einfach die Daten aus System A in System B und lasse abrechnen. Jetzt kommt es aber leider vor, dass die Daten nicht korrekt sind und in System B berichtigt werden müssen. Wie schaffe ich es dann, dass die Daten auch in System A übertragen werden, ohne jedesmal ein Live-Update zu machen (teilweise > 3 Sekunden für jeden Datensatz!)?
Zusätzlich sollen Änderungen in System A die Änderungen in System B nicht überschreiben.

Ich habe mir überlegt, einen Timestamp für jeden Datensatz einzuführen, um mir den letzten Änderungszeitpunkt zu merken. Aber was ist, wenn zufällig in beiden System gleichzeitig Änderungen gemacht werden (z.B. an anderen Feldern), bevor der Abgleich passiert?

Die einzig plausible Möglichkeit, die ein Kollege vorschlug, passt uns allen nicht wirklich. Man müsste für jedes Feld einen eigenen Timestamp haben, damit man die Änderungen nachvollziehen kann.

Was meint ihr dazu?

Der Yeti

[SteBu]

Hallo Forum!

Hallo Yeti

wenn ich deine Frage richtig verstanden habe, brauchst Du ein Diff für MySql-Daten. Ist dem so?
Wenn ja, schau mal hier http://www.mysqldiff.de/index.php.
Das beste ist, es ist Freeware.

SteBu

[Yeti]

Hi SteBu,
danke für den Tipp! So wie es auf den ersten Blick scheint, wird es schwierig sein, das Programm an eine Stelle zu platzieren, von der aus es auf den Internet-Server (via Proxy) und auf den Intranet-Server gleichzeitig zugreifen kann. Außerdem erkenne ich nicht, ob sich das automatisieren lässt. Aber da es auch in PHP geschrieben ist, werde ich mir die Soßen mal anschauen und sehen, ob sich davon etwas für mich verwenden lässt.
Danke!
Der Yeti

[SteBu]

..Aber da es auch in PHP geschrieben ist, .. und sehen, ob sich davon etwas für mich verwenden lässt.

Gerade wegen PHP sollte es sich anpassen lassen. Wenn Du dann noch Cron-Jobs hast(wenn nicht, http://cron-server.de/) sollte das gehen.

SteBu

[Yeti]

Hi,

Gerade wegen PHP sollte es sich anpassen lassen. Wenn Du dann noch Cron-Jobs hast(wenn nicht, http://cron-server.de/) sollte das gehen.

Also der erste Versuch ist wie erwartet fehlgeschlagen, weil ich ins Internet eben nur über den (WWW-)Proxy in Frankreich komme. Wobei ich wahrscheinlich die Verbindung irgendwie anders lösen muss, da ich ja keine Socketverbindung hinbekomme. Da mache ich mich dann morgen dran. ;-)

Cronjobs habe ich zwar nicht, da Windows 2000-Server, aber "Geplante Tasks" machen fast dasselbe. :-) Meine Befürchtungen gingen nur dahin, ob sich dieses Programm automatisieren lässt, da es doch auf den ersten Blick nur "zum Durchklicken" aussah. Aber man kann natürlich einmal die Prozedur durchspielen und schauen, welche Variablen man dem letzten Skript geben muss, damit es loslegt.

Naja, erstmal muss ich den Internetserver erreichen können.

Asta mañana!
Der Yeti

[SteBu]

Moin,

da ich ja keine Socketverbindung hinbekomme.

Weil Du nicht darfst(FW, Admins) oder nicht weißt wie?
Bei 2tem, schau dir mal entsprechende PEAR-Pakete an. Ich nehme aber ersteres an ;-)

Cronjobs habe ich zwar nicht, da Windows 2000-Server, aber "Geplante Tasks" machen fast dasselbe. :-)

Ja, Win hatte schon immer die "blümerigen" Bezeichnungen für altbekanntes ;-)

Ste

[Yeti]

Hi,

Weil Du nicht darfst(FW, Admins) oder nicht weißt wie?
Bei 2tem, schau dir mal entsprechende PEAR-Pakete an. Ich nehme aber ersteres an ;-)

Richtig. Dieser PC ist gar nicht ans Internet angeschlossen, nur über einen WWW-Proxy im Intranet komme ich an Port 80 und 443. :-(

Der Yeti

[fastix®]

Moin!

[...]

Was meint ihr dazu?

Hast Du schon mal was über PHP und Webservices gelesen?

Im wesentlichen musst Du auf beiden Servern entweder via PEAR SOAP oder halt nuSOAP installieren/verwenden.
Datenbankabfragen, die auf dem Server im Web zu Veränderungen führen kannst Du Damit zusätzlich zum Intranetserver übertragen und dort ausführen lassen (Vergiss die Fehlerbehandlung nicht...). Für Sicherheit kannst/musst Du dann sorgen, indem Du entweder den Webserver über ein VPN zugreifen lässt oder mittles ACL auf dem Proxy den Zugriff von der IP-Adresse des Webservers auf ein bestimmtes Verzeichnis des Intranet-Servers erlaubst.

Als Literatur zu Webservices empfehle ich Dir: Web Services mit PHP

MFFG (Mit freundlich- friedfertigem Grinsen)

fastix®

[Yeti]

Hi,

Hast Du schon mal was über PHP und Webservices gelesen?

Ja.

Im wesentlichen musst Du auf beiden Servern entweder via PEAR SOAP oder halt nuSOAP installieren/verwenden.
Datenbankabfragen, die auf dem Server im Web zu Veränderungen führen kannst Du Damit zusätzlich zum Intranetserver übertragen und dort ausführen lassen (Vergiss die Fehlerbehandlung nicht...). Für Sicherheit kannst/musst Du dann sorgen, indem Du entweder den Webserver über ein VPN zugreifen lässt oder mittles ACL auf dem Proxy den Zugriff von der IP-Adresse des Webservers auf ein bestimmtes Verzeichnis des Intranet-Servers erlaubst.

Worin besteht denn da genau der Unterschied, ob ich "live" mittels SOAP abgleiche oder mit meinem selbstgestrickten PHP-Skript die Abfrage ausführe? Das wird doch dann so oder so seine drei Sekunden brauchen und ist damit im Livebetrieb nicht effizient. Allerhöchstens durch einen asynchronen Aufruf (Skript wird "im Hintergrund" gestartet, um den Abgleich vorzunehmen) könnte es bewerkstelligt werden.

Aber danke für die Idee, ich werde das in Betracht ziehen.

Der Yeti

[fastix®]

Moin!

Worin besteht denn da genau der Unterschied, ob ich "live" mittels SOAP abgleiche oder mit meinem selbstgestrickten PHP-Skript die Abfrage ausführe?

Nur noch eine Datenbank... Eventuell kannst Du eine gewisse Rendundanz in Kauf nehmen, indem Du einen Dump einiger Tabellen zeit- oder erignisgesteuert vom "Hauptserver" zum Webserver überspielst und so den "Hauptserver" von nur lesenden Zugriffen auf selten veränderte Tabellen befreist.

Selbstredend kannst Du auch das mittel selbstgestricktem Skript machen. Nur mit SOAP gehts ziemlich bequem.

MFFG (Mit freundlich- friedfertigem Grinsen)

fastix®

[Yeti]

Hi,

Nur noch eine Datenbank... Eventuell kannst Du eine gewisse Rendundanz in Kauf nehmen, indem Du einen Dump einiger Tabellen zeit- oder erignisgesteuert vom "Hauptserver" zum Webserver überspielst und so den "Hauptserver" von nur lesenden Zugriffen auf selten veränderte Tabellen befreist.

Ah, jetzt verstehe ich dein Ansinnen. Das dürfte aber auch nicht effizient sein, wenn alleine schon eine Abfrage vom Stil "SELECT COUNT(*) FROM tabelle" um 20 Uhr (also bei "leerem" Netz) 1,7 Sekunden benötigt. Dann kann ich das System eigentlich direkt so lassen, wie es ist. Der Proxy ist ein Nadelöhr im wahrsten Sinne des Wortes, daher will ich jeden Aufruf der diesen Weg nehmen müsste möglichst vermeiden. Also würde ich eben auch gerne die Änderungen erst nachts übermitteln.

Wir sind jetzt schon soweit, dass wir sagen, die Änderungen in System A werden von den Änderungen in System B überschrieben (allerdings nur in den Feldern, die B auch ändern darf). Da dies nur innerhalb eines 24-Stunden-Zeitfensters passiert, sollte es seltenst vorkommen (und wenn, sind die Daten aus System B ohnehin "korrekter").

Danke für deine Anregung!

Gruß,
Der Yeti

[Sven Rautenberg]

Moin!

So weit, so gut. Ich habe mir jetzt überlegt, ich ziehe nächtlich einfach die Daten aus System A in System B und lasse abrechnen. Jetzt kommt es aber leider vor, dass die Daten nicht korrekt sind und in System B berichtigt werden müssen. Wie schaffe ich es dann, dass die Daten auch in System A übertragen werden, ohne jedesmal ein Live-Update zu machen (teilweise > 3 Sekunden für jeden Datensatz!)?
Zusätzlich sollen Änderungen in System A die Änderungen in System B nicht überschreiben.

Das synchronisieren von Daten zwischen zwei oder mehr Maschinen ist eine durch und durch komplexe Aufgabe, wobei das Problem bösartiger wird, wenn beliebige Aktualisierungsrichtungen möglich sein sollen, und die Sache einfacher wird, wenn man sich in dieser Hinsicht auf eindeutige Richtungen festlegen kann.

Die Sache wird also bedeutend leichter, wenn du deine Datenströme so organisieren könntest, dass diese immer nur in eine Richtung gehen.

Als Beispiel: Auf System A werden neue Adressdaten erfaßt, gehen dann zu System B und werden dort den existierenden hinzugefügt. Dann wird dort was gerechnet, und die Rechnungsdaten gehen dann zurück zu System A. Sowas ließe sich verhältnismäßig simpel programmieren.

Wenn aber die Adresse auf System A nachträglich dort und auch auf System B geändert werden kann, und die Veränderung auf System B wieder zurück nach A soll, dann wird es eben kompliziert. Man kann die Betrachtung dann auf Datensatzebene oder auf Datenfeldebene durchführen (bei Feldbetrachtung multipliziert sich der Aufwand entsprechend):

Ein Datensatz erhält ein Flag "ist synchronisiert", welches auf ja gesetzt wird, wenn ein Abgleich zwischen System A und B erfolgte. Wenn auf einem der beiden Systeme dann eine Veränderung im Datensatz erfolgt, wird auf diesem System das Flag zurück auf nein gesetzt. Bei der nächsten Synchronisierung kommt es dann zu einer von drei Situationen:
1. Beide Systeme haben das Flag gesetzt - nichts wurde geändert.
2. Nur ein System hat das Flag gesetzt - Kopieren der geänderten Daten vom System mit nicht gesetztem Flag.
3. Beide Systeme haben das Flag nicht gesetzt - beide Datensätze wurden parallel geändert, dieser Konflikt muß manuell behoben werden.

Fall 3 ist etwas erleichtert, wenn man nicht den kompletten Datensatz betrachtet, sondern die sync-Flags für jedes Datenfeld vorhält - dann werden die Fälle vermieden, bei denen auf System A die Postleitzahl und auf System B die Telefonnummer geändert wurde. Trotzdem gibt es immer noch die Fälle, bei denen parallel die Postleitzahl geändert wurde.

Wenn beide geänderten Felder den gleichen Inhalt haben, ist das Problem auch leicht gelöst: Es gibt dann doch keinen Konflikt.

Was aber, wenn die zuerst eingetragene PLZ "11111" lautet, und sie auf System A zu "22222" und auf System B zu "33333" geändert wird? Welche Angabe ist jetzt richtig und darf überleben? Oder (wenn es nicht unbedingt um Postleitzahlen geht) ist vielleicht auch ein Mittelwert korrekt, oder sonst ein zu berechnender Wert (beispielsweise wenn es um Bestellungen geht, und man die Anzahl addieren sollte).

In solchen Fällen muß immer manuell nachgearbeitet werden. Wobei in dem skizzierten System folgende Katastrophe passiert ist: Weder auf System A noch auf System B ist die original eingegebene Postleitzahl mehr gespeichert - diese wäre vielleicht für die Entscheidung, welche Postleitzahl denn tatsächlich gültig ist, nicht unwichtig.

Die einzig plausible Möglichkeit, die ein Kollege vorschlug, passt uns allen nicht wirklich. Man müsste für jedes Feld einen eigenen Timestamp haben, damit man die Änderungen nachvollziehen kann.

Ob du nun Timestamps oder nur Flags benutzt, ist für das Ergebnis recht egal: Es ist in jedem Fall möglich, dass parallel dasselbe geändert wird, und dir deshalb deine Synchronisation zusammenbricht. Mit Timestamps hast du die Möglichkeit, die zwei geänderten Felder zeitlich zu sortieren, also eine frühere und eine spätere Änderung herauszufinden - und dann beispielsweise zu entscheiden, dass immer die spätere Änderung gelten soll. Aber mit welcher Berechtigung eigentlich?

Die Alternative zur freien, ungehinderten Bearbeitung auf A und B wäre, dass eine Station, auf der Änderungen durchgeführt werden sollen, eine Sperre auf der anderen Station setzt, die Änderungen dort verhindert. Dies muß aber zwingend "live" geschehen, und die Sperren müssen natürlich auch wieder zurückgesetzt werden. Außerdem bedeutet es, dass beide Systeme sich jeweils gegenseitig erreichen müssen.

Und wenn man schon live Sperren setzen muß, kann man eigentlich auch gleich direkt Datensätze austauschen und eine zentralisierte Datenbank benutzen. :)

- Sven Rautenberg

[Yeti]

Hi,
danke für die Anregungen!

Die Alternative zur freien, ungehinderten Bearbeitung auf A und B wäre, dass eine Station, auf der Änderungen durchgeführt werden sollen, eine Sperre auf der anderen Station setzt, die Änderungen dort verhindert. Dies muß aber zwingend "live" geschehen, und die Sperren müssen natürlich auch wieder zurückgesetzt werden. Außerdem bedeutet es, dass beide Systeme sich jeweils gegenseitig erreichen müssen.

Ich glaube so mache ich es auch. Allerdings nicht live, sondern beim nächtlichen Abgleich. Dort werden alle Datensätze, die bereit zum Abrechnen sind, importiert und gleichzeitig für die Bearbeitung in System A gesperrt. Diese Sperre betrifft aber nur die Felder, die in System B auch geändert werden können (ca. die Hälfte). Beim Abgleich werden nun zunächst die Daten von B nach A geschaufelt (auf die änderbaren Felder begrenzt) und dann von A nach B. Somit ist sichergestellt, dass in beiden Systemen dieselben Daten vorliegen, aber ich muss mir keine komplizierten Synchronisationsregeln ausdenken.

Und wenn man schon live Sperren setzen muß, kann man eigentlich auch gleich direkt Datensätze austauschen und eine zentralisierte Datenbank benutzen. :)

Eben. Am liebsten würde ich ja den Status Quo beibehalten, nur leider ist das durch unsere Netztopologie hier besonders in der Zeit von 11 bis 14 Uhr unerträglich, im Internet zu arbeiten. Da die bei uns aber Nicholas Carr (Interview auf deutsch) huldigen, wird sich daran auch mittelfristig nichts ändern.

Also, ich werde es mal so versuchen. Vielen Dank!

Gruß,
Der Yeti