Replikation FireBird 2.5.x

[Daniel]

Moin,

aus eins mach zwei - ich sehe mich gerade mit dem Wunsch / der Anforderung konfrontiert, eine in Betrieb befindliche FireBird-Datenbank zu replizieren. Ziel ist die Redundanz bei Ausfällen. Wenn der primäre Server nicht mehr tut, sollen die Clients auf einen anderen Server umgeschwenkt werden und dort eine Datenbank vorfinden, die "so aktuell wie möglich" ist.

Dass die integrierte Replikation erst mit FB4 kommt, ist mir bekannt - trotz der guten Reputation der Vorabversionen von FireBird ist ein Software-Stand, der mit Beta #1 betitelt ist, nicht meine erste Wahl für einen produktiven Betrieb. ;-)

Nun werden für FB 2.5.x diverse Produkte angeboten, die eine Replikation versprechen.
Hat jemand Erfahrungswerte, die er teilen mag?

[Bernhard Geyer]

Ich würde eine (Bidirekionale) Replikation außerhalb der Funktion des DBMS vermeiden.
Haben damit schon sehr schlechte Erfahrungen gemacht.

Sin die Anwendungen den überhaupt Repliationsfähig? Nicht jede Anwendung kommt damit zurecht wenn z.B. IDs "ungünstig" selbst in der Anwendung generiert werden.

[Daniel]

Wir bräuchten es lediglich unidirektional. Das Replikat würde im Idealfall nie genutzt - erst dann, wenn die primäre DB ausfällt.
Vor diesem Hintergrund hatte ich gehofft, das System so gestalten zu können, dass die Anwendung wenig davon mitbekommt.

[Neutral General]

Nur im voraus: Ich weiß nicht wirklich wovon ich rede (hab sowas noch nie gemacht/gebraucht), aber vielleicht ist das ja was für dich?

Incremental Backups mit nbackup

Das könnte als Replikation durchgehen wenn man sich da was einrichtet was nbackup regelmäßig aufruft oder?

Edit: Alles Schwachsinn, weil die Datensicherung ja im Notfall dann erstmal zurückgespielt werden müsste.. :wall:
Ich sag ja - Ich weiß nicht wovon ich rede :X

[lowmax_5]

Hi,

dass könnte man z.B. mit nbackup realisieren. Dann liegen die Sicherungen gestaffelt auf einer separaten Maschine Das ganze läuft meiner Erfahrung nach auch unter Last sehr gut. Wenn man es korrekt aufbaut, z.B. Stunden/Tages/Wochenraster, hat man den Vorteil mittels Script zu jedem Zeitpunkt der Stunde/Tag/Woche zurückzukehren. Mittels eines Rücksicherungscriptes setzt man sich dann die Pakete zusammen, um die gewünschte Sicherung wieder herzustellen.

Der schlechteste Fall wäre dann bei einem Stundenraster max. eine Stunde Verlust. Weiterhin lassen sich so verschiedene zeitliche Zustände der DB rekonstruieren. Die Probleme entstehen ja nicht immer in der letzen Sekunde...:wink:

Beim echten Spiegeln ist dann ja oftmals auch das Problem selbst gespiegelt...


Beispiel:

Code:

ECHO TAEGLICHE INK-SICHERUNG - LEVEL 1 ==> -B 1 anpassen !!!

SET DBNAME=D:\DATEN.FDB
SET DASINAME=E:\DASI_INK\DAY\INK_DAY_%date:~0,2%%date:~3,2%%date:~-4%_LV1.NBK

"C:\Programme\Firebird\Firebird_2_5\bin\nbackup" -B 1 %DBNAME% %DASINAME% -u SYSDBA -p unknown

PS:Auf dem Sicherungsserver kann dann ergänzend eine fertig zusammengesetzte DB liegen. So braucht man im Notfall nur den Pfad anpassen...

[hstreicher]

Replicationslösungen für Firebird kenne ich von IBPhonix.com CopyCat.fr meta.com.au und von IBExpert habe ich auch mal was gelesen dass sei eine haben

mfg Hannes

[Nathan]

Hallo

Hatte mal mit Firebird Spiegelung bzw. Shadow funktion von Firebird experimentiert.
Schau mal unter: http://www.ibexpert.net/ibe_de/index...atenbankShadow
War eigentlich ganz praktikabel, kam leider nie bei uns zum Einsatz. Sollte aber so wie ich es verstehe möglich sein direkt auf das Shadow File zu wechseln, sollte es mal Probleme geben.
Das Konzept von Shadow sollte aber Ersatz für ein Backup sein.

[Frickler]

Vom IBExperten gibts nen Video, wo er beschreibt, wie man ein sehr schnelles Backup mit einem Shadow hinbekommt: https://www.youtube.com/watch?v=zotsqajEjEM
Tonqualität ist grausam, aber man sieht, wies geht.
Das Ganze in regelmäßigem Zeitabstand auf den 2. Server kopieren, und im Fall des Falles verliert man wenig Zeit.

[hoika]

Hallo,
wenn es das native FB-Shadow ist (habe das Video noch gesehen), ist das dahingehend "schlecht",
weil fehlerhafte DB-Befehle sofort auch in das Shadow wandern.

[Daniel]

Vielen Dank zunächst - inhaltlich fehlerhafte Daten sind jetzt weniger unsere Sorge.
Die DB hält grob gesagt Bewegungsdaten und Zustände von Objekten fest. Es handelt sich um ein verteiltes Softwaresystem und wenn wir in einen Zustand kommen, in dem die unterschiedlichen Programmteile abweichende Vorstellungen davon haben, wo Objekte sind und in welchem Zustand sie sich befinden, wird es .... ein wenig lästig.

nbackup und Shadow sehe ich mir mal an, dankeschön.