Entwickler-Ecke

Datenbanken - firebird Replikation


Josef-B - Di 02.02.10 16:34
Titel: firebird Replikation
Hallo,

wir bekommen plötzlich eine Filiale :-)

Ich hab die Aufgabe, eine Filiale an unsere Firebird-Datenbank anzubinden.

Hat jemand Erfahrung, wie man das am besten macht?

Ist Replikation das richtige Stichwort?

Filiale und Zentrale sollen möglichst ne gespiegelte Datenbank haben.


kkausp - Di 02.02.10 17:36

Hallo,

vielleicht reicht eine Anbindung per VPN-Tunnel?

Vorteil: nur eine DB, Nachteil: Performance,Stabilität,Aussfallsicherheit


Sinspin - Di 02.02.10 21:07

Auch bei einer gespiegelten Datenbank musst du in irgend einer Form eine Synchronisation der beiden DBs hinbekommen. Also brauchst du eine Verbindung über die die Daten jeweils in die anderen DB geschrieben werden können.
Bei einer Spiegelung sind ja beide DBs eigentlich identisch. Denn eine Spiegelung dient häufig nur der Erhöhung der Ausfallsicherheit.
Beachtest du die Synchronisation der fernen DB nicht kann es unter Umständen zu Konsistenzproblemen kommen. Also das du Datensätze in deine lokale DB scheibst die du in die anderen nicht reinbekommen hättest da ein uniquer Key schon vorhanden ist. Oder lass es einfach ein AutoInc Wert sein der dann doppelt vergeben ist. Das heißt dann auch das ein nachträgliches synchonisieren nicht wirklich möglich ist.

Mir fallen fürs erste zwei Lösungen ein:


Josef-B - Di 02.02.10 22:03

Danke für eure Beiträge,

ich suche nach einer Möglichkeit, die recht schnell umsetzen kann.

Die Probleme, die ihr schildert, sind natürlich einleuchtend. Wenn ich einfach per VPN auf die Datenbank zugreife ->
wird das nicht zu langsam? Denn ich habe bisher keine Stored Procedures verwendet. Da werden doch dann viele Daten hin und hergeschickt, nämlich die kompletten SQl-Abfragen, oder?

Mein Gedanke war, wenn ich die Datenbank spiegele, dass dann eben nur die geänderten Daten übermittelt werden und somit weniger Daten auf die Reise geschickt werden.


UGrohne - Di 02.02.10 22:22

Eine "relativ" einfach zu implementierende Möglichkeit wäre: Alle AutoInc-Werte und deren Trigger so zu modifizieren, dass auf der einen Seite nur gerade und auf der anderen nur ungerade Zahlen verwendet werden, so gibt es keine ID-Konflikte. Die Synchronisation basiert dann einmal auf dem Abgleich der IDs für neue Werte auf der jeweils anderen Seite und die Modified-Daten eines jeden Datensatzes. Nur Modifikationen des gleichen Datensatzes auf beiden Seiten führt dann zu Problemen, weil entweder der letzte gewinnt oder Du einen Merge-Prozess einbauen musst, der wieder mehr Arbeit kostet. Die Synchronisation würde jedenfalls auch einen längeren Ausfall der Verbindung recht gut überstehen.

Das wäre mir jetzt spontan eingefallen, was schnell gehen würde. Nur: Schnellschüsse rächen sich meistens ziemlich schnell.


Josef-B - Di 02.02.10 23:03

hmm, UGrohne: aber das funzt auch nur bei einer Filiale, wenn da mehrere angebunden werden, gibts wieder ein Problem. Wie machen das die Profis mit solchen Filialketten?


Sinspin - Di 02.02.10 23:06

user profile iconUGrohne hat folgendes geschrieben Zum zitierten Posting springen:
Eine "relativ" einfach zu implementierende Möglichkeit wäre: Alle AutoInc-Werte und deren Trigger so zu modifizieren, dass auf der einen Seite nur gerade und auf der anderen nur ungerade Zahlen verwendet werden, so gibt es keine ID-Konflikte.
...
Das wäre mir jetzt spontan eingefallen, was schnell gehen würde. Nur: Schnellschüsse rächen sich meistens ziemlich schnell.

Das ist auch eine Idee. Ehrlich gesagt für den Anfang sogar eine recht gute. Aber nicht mehr wenn dann die nächste Filiale kommt.

Also lieber ein bisschen mehr Zeit und Geld investieren und eine bessere Lösung nehmen. Also das Firmennetzwerk via Internetanschluss und VPN oder was ähnlichem auf die Filiale ausweiten und auf die gleiche DB zugreifen. Ein SQL Script läuft ja eh immer auf dem Server. Die Ergebnismenge oder Tabelleninhalte sollte man aber so abfragen das immer nur die gerade sichtbaren Daten geladen werden müssen. Selbst wenn via VPN nur 50KB/s übrig bleiben sollten ist das für normale DB abfragen immer noch schnell genug. Außer du schleppst rießige Blob Felder durch die Gegend.

ADS (Advantage Database Server) (den verwenden wir) verfügt zum Beispiel über drei Verbindungsarten (Lokal, also via direkten Zugriff auf die Dateien; Remote, via direkte TCP/IP Connection übers Firmennetzwerk; Internet, wie Remote nur das der Server übers dem Internet erreichbar sein muss. Dabei ist dann Verschlüsselung und Kompression der Daten gleich mit dabei, so das man sich einen Tunnel sparen kann.)


Nersgatt - Mi 03.02.10 08:27

Der Klassiker für Filialanbindung ist doch einfach einen Terminalserver hinzustellen, auf dem die Filiale dann arbeitet, oder? Dann musst Du keine Verrenkungen mit der Datenbank machen, weil es für die so ist, als wäre es ein ganz normaler Client.
Und Du kannst Updates einfacher einspielen. Auf jeden Fall wäre das für mich die Lösung der Wahl.

Ich habe schon oft solche Lösungen gesehen. Auch Filialen im Ausland, die so an den Firmensitz angebunden werden. Das läuft recht problemlos.


Lemmy - Mi 03.02.10 09:09

Hi,

schau mal:
http://www.firebirdfaq.org/faq249/

Nebenbei: die Geschichte mit der ID setzt mind. eine der Lösungen um (das hier wars glaube ich http://www.meta.com.au/).

Und noch was: Wie ist das mit der Filiale: Ist es absehbar, dass in nächster Zeit eine weitere Filiale aus dem Boden gestampft wird? Wenn ja, dann musst Du dich gleich nach was entsprechendem umschauen. Wenn nicht: Warum komplizierter und teurer machen als die Anforderungen sind? Klar kannst Du dir auch dafür eine Alternative überlegen, stell aber dann auch die Kosten zusammen und entscheide dann was Du umsetzt - außer natürlich Du hast Zeit und Geld im Überfluss zur Verfügung ;-)

ach und noch was: Die Lösung mit der ID funktioniert auch mit mehreren Filialen :-) Wie verrate ich jetzt aber nicht, da solltet ihr aber eigentlich schnell selbst drauf kommen...

GRüße
Lemmy

P.S.: Eben fällt mir ein: Firebird hat ein echtes Problem beim Zugriff über ein langsames Netz (wie das Internet): Es schickt einfach zu viele "unnötige" Informationen hin und her (da gehts um Internas des Firebird-Protokols http://www.firebirdfaq.org/faq53/). Allerdings hat sich da einer was überlegt: Er setzt vor den eigentlichen Firbird-Server einen Dienst, der die SQL-Anfragen des Clients entgegen nimmt, diese an den Server weiter reicht und die Ergebnismenge dann als "einfachen" Stream wieder an den Client zurückschickt. Geht angeblich sau schnell. Ich such mal nach der entsprechenden Internetseite


mkinzler - Mi 03.02.10 09:25

Derartigen Programem wären
ZeDeBee [http://www.winton.org.uk/zebedee/] oder stunnel [http://www.stunnel.org/]