Firebird Master/Slave Replikation

[Kostas]

Hallo Zusammen,

die Frage vorab: 120MB FB 3.0 Datenbank replizieren ohne Trigger und Log-Table, oder Backup-/Restore Variante?

ich habe ein Projekt mit einer Firebird 3.0 DB auf einem Server laufen. Im LAN funktioniert alles perfekt. Jetzt soll für ein Event für drei Wochen, von einer Webanwendung zugegriffen werden. Dieser Event wird jedes Jahr wiederholt. Die Web-Anwendung haben wir in Next.js umgesetzt, die über ein Node.js Projekt auf die Firebird DB zugreift. Wenn die Webanwendung über diesen Weg auf die DB zugreift, könnte es wegen der vielen Userzugriffe zu Problemen führen da die Internetleitung nur eine SDSL 100MBit Leitung ist.

Jetzt ist die Idee entstanden die Datenbank zu replizieren und zwar NUR vom Master zum Slave. Die zweite DB hat NUR die Aufgabe irgendein Blödsinn auf eine Webseite darzustellen also NUR lesender Zugriff. Mit Replikation habe ich mich noch nicht beschäftigt. Aus früheren Jahren habe ich mal gelesen, dass Firebird die Replikation so macht, dass jede Änderung in einer Tabelle über Trigger geschrieben wird und diese Daten werden dann abgeglichen. Dieses Konzept wäre nicht so gut geeignet da alle 5min. ca. 50000 Records gelöscht, berechnet und wieder geschrieben werden. Dieselbe Menge würde dann auch auf dieser Log-Tabelle geschrieben werden müssen. Der Vorgang die 50000 Records zu generieren und zu schreiben über SPs dauert übrigens ca. 1.2min. Meine Versuche in diesem Zeitraum die Daten im LAN über die Webanwendung darzustellen schafft FB spielend und die Webseite reagiert in Echtzeit. Nur die 100MBit SDSL-Leitung die ein Upload von ca. 30MBit hat, wird vermutlich ein Problem werden.

Gibt es mit FB 3.0 eine andere Form der Replikation die komplett ohne Trigger und Log-Tabelle auskommt? Ich meine gelesen zu haben, FB 3.0 kann so etwas wie ein inkrementelles oder so ähnlich Backup erzeugen. Gibt es eine Möglichkeit im laufenten Betrieb ein Restore gekapselt in einer Transaktion durchzuführen oder muss die DB zu diesem Zeitpunkt down sein? Die DB ist übrigens ca. 130MB groß nach einem halben Tag ohne Backup und Restore. Nach einem Restor wird die DB sicherlich ca. 50MB groß sein wegen den gelöschten Records.