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.

[Amanda]

https://www.ibexpert.net/ibe/uploads...eplication.pdf

[IBExpert]

oder (relativ neu von uns) out of the box
https://ibexpert.net/cms/ibexpert-re...nterprise-iber
damit kannst du die tabelle dann rausfiltern, die so einen mumpitz macht, ich geh davon aus das es für dein replikat begrenzt wichtig ist

[Blup]

Zitat:

Zitat von Kostas (Beitrag 1540464)

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.

Wahrscheinlich ändert sich nicht jeder Wert alle 5min.
Jeder Datensatz den man nicht schreibt, spart Zeit.
Also besser jeden Record erst berechnen, mit dem alten Wert vergleichen und dann erforderlichen Falls aktualisieren.

Handelt es sich um eine Folge von Werten, bei der aufeinander folgende Werte häufig gleich sind?
Dann würde es vieleicht reichen nur die Datensätze zu schreiben, die sich zum Vorgänger ändern.
Muss man zwar beim Lesen der Daten berücksichtigen, aber weniger Daten spart Zeit beim Schreiben und Lesen.

[Kostas]

Wir versuchen jetzt einen anderen Weg über Backup/Restore. Die DB ist klein. Das Backup File kann gut komprimiert werden. Die Idee ist nun, der Server mach ein Backup, zipt und sendet über VPN das File auf dem WebServer. (Windows Maschine) Auf dem WebServer läuft ein Dienst der den Restore durchführt. Anschließend beendet die Node.js Anwendung die Connection, ersetzt die DB und startet wieder. Die down time der DB wäre damit 2-3 Sekunden. Da die Web-Anwendung über Next.js Statuslos ist, sollte es kaum Probleme geben. Das wollen wir so mal versuchen.

[Blup]

Alternativ die Übertragung der betreffenden Tabelle vom Client starten.
Damit sollten alle Datensätze in einem Block übertragen werden und die Latenzzeit für jeden einzelnen Datensatz entfällt.

Code:

insert into tabelle
  (id, ...)
select  (id, ...) from server.tabelle

[Blup]

Man könnte auch auf dem Client immer zwischen zwei DB umschalten.
Eine die gerade übertragen wird und eine für die Abfragen.

[Kostas]

Wir bauen gerade so einen Versuch auf. Mal sehen wie die Webseite reagiert.