Datenabgleich zw. Servern

[Schlofu]

Hallo zusammen.

Zum "Problem":
Ich habe eine Website mit Loginbereich auf einem externen Server und ein Auftragsbearbeitungssystem auf einem internen Server.
Das hat mehrere Gründe, unter anderem der, daß wir intern viel Daten "bewegen", wodurch der interne Server unerläßlich ist. Zum anderen ist dieser aber von ausserhalb nicht erreichbar, wodurch wiederum die HP auf einem externen Server laufen muss. Daran soll und will ich auch nix ändern.

Nun sollen aber im Loginbereich aktuelle Daten aus dem internen System auftauchen - und das nahezu "live". Umgekehrt können gewisse Daten im Loginbereich geändert werden. Dies ist aber selten und muss nicht Zeitnah geschehen - kann daher in den Überlegungen vernachlässigt werden.

Lange Rede kurzer Sinn. Spontan fallen mir 3 Möglichkeiten ein:

1. Ich lasse die interne DB auf den HP-Server replizieren
2. Ich generiere XML Dateien die ich auf den HP-Server schiebe
3. Ich erlaube den externen Zugriff auf die interne DB

Die 3. Mgl. ist zwar die einfachste, aber aus Sicherheitsgründen, würde ich diesen Weg aber nicht gehen wollen.

Mgl. 2 hat den Nachteil, daß ich die XML-Dateien erst "auswerten" müsste...

und 1... tja... unsere DB ist groß... Sicherheit spielt auch 'ne Rolle (gibt es "Teil-Replikationen"?)

Daher wollte ich mal fragen, was ihr so dazu meint.

Sicherheitstechnisch / Performance / Datendurchsatz etc.

Welche Lösung ist die Beste, gibt es Bessere?
Erfahrungsberichte?

Achja: PHP / MySQL

[Hopsel]

Hi Schlofu!

3. Ich erlaube den externen Zugriff auf die interne DB
   Die 3. Mgl. ist zwar die einfachste, aber aus Sicherheitsgründen, würde ich diesen Weg aber nicht gehen wollen.

Bietet MySQL keine Möglichkeit an, Benutzer mit eingschränkten Rechten zu definieren?

MfG H☼psel

[Schlofu]

Hi H☼psel

Bietet MySQL keine Möglichkeit an, Benutzer mit eingschränkten Rechten zu definieren?

Das ja, aber wie schon erwähnt ist der interne Server von aussen eigendlich nicht zu erreichen - keine feste IP und so weiter... ich könnte es einrichten, wollte aber erstmal die anderen Möglichkeiten... öhm... durchsprechen ;)

[Vinzenz Mai]

Hallo,

3. Ich erlaube den externen Zugriff auf die interne DB
   Die 3. Mgl. ist zwar die einfachste, aber aus Sicherheitsgründen, würde ich diesen Weg aber nicht gehen wollen.

@Schlofu
dafür habe ich volles Verständnis. Diesen Weg solltest Du in jedem Fall vermeiden.

Bietet MySQL keine Möglichkeit an, Benutzer mit eingschränkten Rechten zu definieren?

@all
Wo ein Weg ist, da ist eine Lücke. Wo kein Weg ist, da muss die Lücke erst geschaffen werden. Es ist gar keine gute Idee, einen internen Server (egal welcher Art), der sensible Daten beherbergt, von außen zugänglich zu machen.

In meinen Augen ist der gezielte Abgleich *genau der* Daten, die außen zur Verfügung stehen müssen, der richtige Weg. Welche Wege möglich sind, das hängt von den Umständen ab.

Sehr schick wäre der Abgleich über Trigger (MySQL 5.0.2 und neuer, Standard) sowie Zugriff über die Federated Storage Engine (MySQL 5.0.3 und neuer, *kein* Standard).

Freundliche Grüße

Vinzenz

[Hopsel]

Hi Vinzenz!

Ich stimme mit dir überein und freue mich, dass du dich in diesen Thread einklinkst. So bekommt Schlofu wenigstens eine kompetente Antwort. =)

Bietet MySQL die Möglichkeit, einen View auf dem externen Server zu definieren, der seine Daten vom internen Server bekommt?

Ist sowas überhaupt mit anderen "großen" DBM-Systemen möglich?

Das würde die redundate Datenhaltung oder Definition von Triggern (und damit die aufwändigere Wartung) doch vermeiden. Ich kann mir nicht vorstellen, dass sowas nicht gehen sollte.

MfG H☼psel

[Vinzenz Mai]

Hallo,

Bietet MySQL die Möglichkeit, einen View auf dem externen Server zu definieren, der seine Daten vom internen Server bekommt?

Die Federated Storage Engine bietet das. In der von Dir angesprochenen Konfiguration wäre aber die unerwünschte Öffnung nach außen nötig - ist doch logisch. Sicherlich wäre der Paketfilter so konfiguriert, dass er nur Pakete von dem externen Server zuließe - aber mir wäre bei dieser Öffnung unwohl. Ich möchte in einem solchen Fall nur die Daten nach außen geben, die für die externe Anwendung nötig sind. Das Konzept sollte wohlüberlegt sein. Die Triggerlösung hat den Charme, dass die Datenhaltung hübsch an einer Stelle bleibt: Erfolgt die Änderung an der einen Stelle, dann auch an der anderen, ohne dass die Anwendungen selbst etwas über den Abgleich lernen müssen.

Ist sowas überhaupt mit anderen "großen" DBM-Systemen möglich?

was verstehst Du darunter? MS SQL-Server kann das, sowas nutze ich nahezu täglich (ok, beide betroffenen Server stehen bei uns im Haus und sind von außen nicht erreichbar :-)). Ich bin mir sicher, dass Oracle, DB2 und Co. dies erst recht können. Mit diesen Systemen habe ich beruflich (leider) nichts zu tun, so dass ich nicht aus eigener Erfahrung sprechen kann. Da benutze ich nur gelegentlich die Express Edition, um 'ne Forumsfrage zu beantworten :-)

Freundliche Grüße

Vinzenz

[Hopsel]

Hi Vinzenz!

Ich möchte in einem solchen Fall nur die Daten nach außen geben, die für die externe Anwendung nötig sind.

Ja, das meinte ich mit dem View.

Die Triggerlösung hat den Charme, dass die Datenhaltung hübsch an einer Stelle bleibt: Erfolgt die Änderung an der einen Stelle, dann auch an der anderen, ohne dass die Anwendungen selbst etwas über den Abgleich lernen müssen.

Naja gut. Trigger scheinen ja auch wirklich gut dafür zu sein.
Aber ich brauche da jetzt noch ein Beispiel um vollends dahinter zu steigen. =)
Also:
Externe Server hat ein DBMS installiert.
Interner Server hat Zugriff auf den Externen Server, genauer: auf das DBMS.
Interner Server aktualisiert, angestoßen von einem Trigger, den externen Server.
Das heißt also, dass der externe Server keinen Zugriff auf den internen hat, über den umgekehrten Weg aber die Daten aktualisiert werden.
Ist damit die Sicherheit noch gegeben und habe ich die Struktur richtig dargestellt?

Ist sowas überhaupt mit anderen "großen" DBM-Systemen möglich?
was verstehst Du darunter?

Oracle, MSSQL und DB2. =)

[...] sowas nutze ich nahezu täglich [...]

Ja, wenn man die Erfahrung hat, mag das mit den Triggern wirklich gut funktionieren. Ich selbst müsste wahrscheinlich erstmal wochenlang testen, lernen, usw.

MfG H☼psel

[Schlofu]

Erstmal vielen Dank euch beiden für die Anregungen!

... das mit den Triggern, hähä, müßte ich mir auch erst anlesen, klingt aber auf jedenfall nach der Lösung die ich mir wünsche ;)

Kurze Frage dazu: Update / Insert / Delete könnte ich mit einem Trigger "belegen" (soweit ich das noch weiß), aber klappt das auch evt. mit Select?

Beispiel:
Der User hat im Loginbereich die Möglichkeit seine Adresse zu ändern.
Nu würde ich im internen System BEVOR ich die lokale DB auslese gerne die Adressen von extern abgleichen...
Oder wäre es in dem Fall sinnvoller einfach in mein System (welches sich ja eh noch in der (Weiter)Entwicklung befindet) dieses "mal gucken" einbauen?

Bzw. würde ich jetzt ganz einfach meine DB-Klasse dahingehend erweitern, das sie das tut - statt mich ins Triggern zu bringen %) - kurzfristing. Langfristig werde ich's mir erlernen...

[Hopsel]

Hi Schlofu!

... das mit den Triggern, hähä, müßte ich mir auch erst anlesen, klingt aber auf jedenfall nach der Lösung die ich mir wünsche ;)

Trigger sind nicht schwer. Aber ihre Verwendung kann komplizierte Strukturen und Beziehungen nach sich ziehen. Deshalb ist es Plficht, alles genau und einheitlich zu dokumentieren.

Kurze Frage dazu: Update / Insert / Delete könnte ich mit einem Trigger "belegen" (soweit ich das noch weiß), aber klappt das auch evt. mit Select?

1. Du kannst einerseits mit Stored Procedures arbeiten, die die Steuerung der richtigen Abfolge für dich übernehmen. Allerdings bedeutet das wiederum einen Mehraufwand bei der Datenbankverwaltung.

2. Inwiefern MySQL das Konzept der Views unterstützt, weiß ich nicht. Aber mit einem View könntest du eine Quasi-Tabelle erzeugen, die die Daten der lokalen DB und die aktuellen Daten enthält. Auf dem View kannst du dann im Programm wie auf einer Tabelle operieren. [1]

Oder 3. Einfach vor der Abfrage aus der lokalen DB, neuere Einträge aus der externen DB aktualisieren. Das kann dann auch durchaus eine gespeicherte Prozedur sein.

Denkbar wäre auch eine Mischform. Du arbeitest mit dem View und einem Cronjob. Der Cronjob aktualisiert alle paar Stunden die interne DB (z. B. über den Aufruf einer Stored Procedure) und garantiert somit, dass der View nicht Massen an aktuellen Daten bereithalten muss.

Du bekommst hier Antworten von einem der sich selbst bestenfalls als interessierter Fortgeschrittener bezeichnen würde. Aber vielleicht geben ein paar genannte Punkte dir oder Vinzenz die entscheidende Anregung.

Bzw. würde ich jetzt ganz einfach meine DB-Klasse dahingehend erweitern, das sie das tut - statt mich ins Triggern zu bringen %) - kurzfristing. Langfristig werde ich's mir erlernen...

Wie gesagt, die Trigger sind nicht schwer, so lange man sauber dokumentiert und diese Dokumentation bei Problemen auch konsultiert. =)

[1] Ob dieses Konzept wirklich so funktioniert... Ich weiß es nicht... =)

MfG H☼psel