[php] Eine Shell über SSH öffnen für Datenübertragung

[Andi Voss]

Hi Lutz,


Lutz Zetzsche schrieb:
> Hi Andi,
> 
> Am Mittwoch, 1. Juni 2005 16:19 schrieb Andi Voss:
> 
>>Hi,
>>
>>ich habe ein Projekt am Laufen, einen Online-Shop in ein
>>Warenwirtschaftsprogramm zu integrieren. Das Warenwirtschaftsprogramm
>>läuft mit einer Firebird Datenbank in einer Firma lokal. Der
>>Online-Shop basiert auf genau der selben DB, die das Wawi benutzt und
>>liegt auf unserem root-Server im Internet. Zur Zeit wird täglich eine
>>Kopie der Wawi DB durchs Netz geschaufelt (ca. 50 mb gepackt und im
>>Backupmodus, originale Größe ca. 400 mb), um den Online-Shop aktuell
>>zu halten.
>>
>>Meine Idee ist es jetzt, mit PHP-CLI über eine gesicherte SSH
>>Verbindung http://us2.php.net/manual/de/function.ssh2-shell.php eine
>>Shell zu öffnen und durch diese dann immer die Änderungen der lokalen
>>DB ins Internet zu übertragen. Die Firebird DB unterstützt TRIGGER
>>und STORED PROCEDURES, womit die geänderten Datensätze direkt nach
>>einem INSERT,UPDATE oder DELETE in eine eigene Tabelle geschoben
>>werden könnten. Diese extra Tabelle wollte ich dann mittels PHP-CLI
>>auslesen und Datensatz für Datensatz über die Shell Verbindung in der
>>entfernten DB wieder eintragen (auf dem entfernten Rechner dann auf
>>der Shell mittels isql (Kommandozeile von firebird)).
>>Um das möglichst flexibel/schnell/zeitnah zu halten, wollte ich ein
>>Skript in eine Endlosschleife setzen und in dieser ständig die extra
>>Tabelle mit den Datensatzänderungen abfragen (vielleicht alle 5
>>sec.). Sobald dann ein Eintrag enthalten ist, kann der sofort
>>ausgelesen und übertragen werden und die Online-Shop DB aktualisiert
>>werden. Irgendwie muss das PHP-Skript ja wissen, dass neue Einträge
>>in der extra Tabelle vorhanden sind, daher die Idee mit der
>>Endlosschleife.
>>
>>Jetzt meine Bedenken:
>>- Ein PHP-Skript in einer Endlosschleife, wie wirkt sich das auf die
>>Performance des einsetzenden Rechners aus? Man kann doch den
>>Ressourcenverbrauch eines Skriptes einstellen oder? Gäbe es da
>>irgendwelche vorhersehbaren Probleme?
>>
>>- Alle ca. 5 sec. eine einfache Abfrage auf eine Tabelle sollte das
>>DB-System auch nicht in Verlegenheit bringen...oder?
>>Hardwaretechnisch ist auf beiden Seiten alles im grünen Bereich.
>>Sollte halt auch in kritischen Situationen (viele Änderungen auf
>>beiden Seiten) nicht den "normalen" Betrieb beeinflussen.
>>
>>Was haltet Ihr von diesem allgemeinen Lösungsansatz?
>>Würde mich freuen, wenn sich jemand dazu äußern könnte.
>>Ideen, Kritik und Vorschläge sind natürlich willkommen.
> 
> 
> ehrlich gesagt, gefällt mir der Ansatz nicht so.
> 
> 1. Muß das alle 5 Sekunden sein? Reicht nicht auch jede Minute oder alle 
> 5 Minuten? Wenn einer kurz Kaffee holen geht, bevor er den geänderten 
> Datensatz speichert, gehen ja auch ein paar Minuten ins Land. ;-)

Eigentlich sollten die Änderungen sofort übertragen werden. Hier stellt 
sich aber das Problem, wie bemerkt werden soll, dass eine Änderung 
vorliegt. Daher die ca. 5 sec. mit der Endlosschleife, damit es recht 
zügig geht. Aber Du hast schon recht, dass wahrscheinlich alle 5 min. 
genügen mit der Option, dass man die Aktualisierung auch manuell 
anstoßen kann, sodass trotzdem die Möglichkeit besteht Änderungen SOFORT 
zu übertragen.

> 
> 2. Ich würde versuchen, das stärker auf Betriebssystemebene zu lösen, 
> d.h. anstatt einem PHP-Skript in einer Endlosschleife würde ich ein 
> Shellskript nehmen, welches von einem Cronjob regelmäßig angestoßen 
> wird.

Das hatte ich auch erst überlegt, aber da der DB-Server ein 
Windows-Rechner ist und alles möglichst plattformunabhängig sein soll, 
hatte ich an PHP gedacht. Sobald allerdings ein Linux-Rechner im 
Netzwerk vorhanden wäre, wäre die Shellskript-Lösung wohl ein besserer 
Ansatz.

> 
> 3. Du mußt noch einen Lock-Mechanismus vorsehen, vor allem wenn Du sehr 
> kurze Aktualisierungsabstände im Sekundenbereich anstrebst. Die Lösung, 
> die Du skizziert hast, wird nämlich durchaus länger als 5 Sekunden 
> brauchen, um die Aktualisierung vorzunehmen. Und wenn dann 5 Sekunden 
> später die nächste Aktualisierung angestoßen wird, kann es in 
> Abhängigkeit von der programmiererischen Umsetzung Probleme geben.

Da hab ich noch nicht dran gedacht gehabt. Würde ja aber auch wegfallen 
beziehungsweise nicht so kritisch sein, wenn der Updatezyklus vergößert 
werden würde.
Ansonsten wäre das ja recht einfach mit einem extra Feld in der Tabelle 
zu lösen, welche mit dem Inhalt 1 gesperrt ist und 0 freigegeben ist. Da 
nur "mein" Programm darauf zugreift, würde diese Sicherung wohl genügen 
denke ich.

> 
> 
> Viele Grüße
> 
> Lutz

Danke Gruss Andi