Folgendes Szenario:

Eine Maschine stellt eine Datei xyz.txt bereit.
Zwei Suse-Rechner greifen darauf per WebDav zu und sollen die Datei xyz.txt verarbeiten.
In xyz.txt stehen Daten, die auf beiden Susen in eine MySQL-DB importiert werden müssen.

Problem: Wenn sich die erste Suse die xyz.txt schnappt, hat ja die 2. Suse ein Problem oder umgekehrt.

Wie kann ich es hinbekommen, dass so etwas nicht passiert?!
Datenbank auf eine andere Maschine auslagern ist leider keine Lösung!!!!!

Hat hier jemand eine gute Lösung?

Gast+2008-08-20 08:49:20--

Problem: Wenn sich die erste Suse die xyz.txt schnappt, hat ja die 2. Suse ein Problem oder umgekehrt.

warum?

Na, wenn z.B. per Cronjob beide Susen alle 5min. suchen, ob die xyz.txt da ist, dann schnappen sie sich, arbeiten den SQL-Import ab und löschen die xyz.txt, schauen wieder nach 5min, ob eine neue da ist u.s.w.

D.h., wenn die erste Suse sieht, Ja, Datei ist da gehts los.
Wenn die 2. Suse dann 1 sek. später schaut, gibts keine xyz.txt mehr.

Damit würden die Datenbanken auseinander laufen ...

Das ist das Problem

Eine Lösung wäre z.B., die verarbeitete Datei erst später zu löschen, wenn beide Rechner sie garantiert verarbeitet haben.

mmmh ...

ja - schon klar, aber eines darf dann nicht passieren:

Die xyz.txt wird ja von einem dritten Rechner den beiden Susen bereitgestellt.

Was passiert, wenn genau während der Verarbeitung eine neue von dem dritten Rechner bereitgestellt wird?

Dann würde es ja auch Ärger geben ...

also so eine richtige Lösung habe ich noch nicht dazu ...

Wie wärs wenn du mit Zeitstempel arbeitest, die Lösung in Pseudocode:

Script eins:

Holt Zeitstempel von xyz.txt
Wenn /tmp/<script1bezeichner><zeitstempelderdatei>.txt nicht vorhanden
Script eins kopiert xyz.txt nach /tmp/xyz<zeitstempelderdatei>.txt
führt txt aus
löscht alle alten /tmp/<script1bezeichner><altezeitstempel>.txt

Script zwei ähnlich, nur halt mit einem anderen Bezeichner.

Hi,
wie wär's mit:

der generierende Rechner teilt den beiden SuSE Rechnern mit, dass es eine neue xyz.txt gibt, die sie verarbeiten können. Jeder verarbeitende Rechner meldet an den generierenden Rechner die erfolgreiche Verarbeitung und erst, wenn alle sich zurückgemeldet haben, kann eine neue xyz.txt abgelegt werden.

Erfolgt innerhalb von X Zeiteinheiten keine erfolgreiche Rückmeldung, so wird eine Fehlerbenachrichtigung ausgelöst.

Mit einer Namend-Pipe (fifo) könnte man es auch machen.
Das Script, das die "xyz.txt" datei erzeugt legt stattdessen eine Benannte Pipe an. Wann immer ein Anderes Programm die vermeintliche Datei (die Pipe) ausließt weiß es das Script und kann die neuesten Daten liefern. Ein löschen der Datei wird unnötig.

dasa+2008-08-20 10:33:44--

Wie wärs wenn du mit Zeitstempel arbeitest, die Lösung in Pseudocode:

Script eins:

Holt Zeitstempel von xyz.txt
Wenn /tmp/<script1bezeichner><zeitstempelderdatei>.txt nicht vorhanden
Script eins kopiert xyz.txt nach /tmp/xyz<zeitstempelderdatei>.txt
führt txt aus
löscht alle alten /tmp/<script1bezeichner><altezeitstempel>.txt

Script zwei ähnlich, nur halt mit einem anderen Bezeichner.

Hm, das scheint mir nicht so ganz ausgereift zu sein, aber so aehnlich wuerde ich es auch machen:

1. Verschiebe Datei nach xyz.txt.tmp.$random
2. Fuehre die Datei aus
3. Loesche die Datei (also xyz.txt.tmp.$random)

Wenn man dagegen abgesichert sein will, dass das Script abstuerzt, und die Datei zwar schon umbenannt ist aber nicht bearbeitet, kann man vielleicht als 0. Schritt einführen:

0. Dateien *.tmp.*, welche eine atime von mehr als ein paar Minuten (je nach dem, wie lange das Script typischerweise läuft) haben, werden wieder so umbenannt, dass das .tmp.* nicht mehr am Ende ist.

Alles steht und fällt mit dem Atomarsein von rename(): Es darf nichts anderes passieren zwischen dem Prüfen auf Existenz der Datei und Umbenennen der Datei.

Bei Linux ist rename() afaik hinreichend atomar dafür. Ob das in WebDAV ausgenutzt werden kann, weiß ich nicht.

($random kann natürlich sinnvollerweise aus Zeitstempel und PID und Rechnername bestehen.)

Erster Ansatz wäre, in den Daten einen Zeitstempel einbauen und die Datei nie löschen oder zeitweise kürzen. So könnten/müssten die Zielsystem selber entscheiden, welche Daten neu sind.

Ein zweiter Ansatz wäre, pro Zielsystem einen eigenen Ordner/Datei mit den Daten anlegen. So hätte man das gegenseite Löschen-Problem umgangen.

Dritter Ansatz wäre, das Quell-System schreibt neue Daten in jeweils eine neue Datei und löscht diese in regelmäßigen Abständen. Die Zielsystem müssten dann selber entscheiden, welchen Dateien neu sind.

Vierter Ansatz wäre (ähnlich wie der von topeg), es wird ein Skript aufgerufen, welche die Daten übergibt. Als Parameter wird an das Skript eine ID des Zielsystems angegeben. An Hand der ID werden die entsprechenden Daten ausgegeben.

... oder die (neuen) Daten gleich per Email verschicken :-)