Firebird Shadow Netzwerk

[lxo]

Hallo zusammen,

ich setze mich aktuell mit dem Thema Shadows in Firebird auseinander.
Da gibt es auch schon gute Informationen von
IBExpert (https://www.ibexpert.net/ibe_de/pmwi...atenbankShadow)

Ich versteh nur noch nicht genau, wie sollte man da am besten vorgehen?

Mein Gedankengang ist wie folgt.

• 1 x Hauptserver (Firebird Hardwareserver)
• 1 x Backupserver (Firebird Virtuellerserver)

Für die Datenbank auf dem Hauptserver würde ich ein Shadow anlegen, mit Ziel auf dem Backupserver.
Also in etwa so:

• Datenbankpfad \\Hauptserver\Datenbank.FDB
• Shadow \\Backupserver\Datenbank.SHD

Meine Fragen dazu ...

• Ist das übers Netzwerk überhaupt zuverlässig ?
  • Damit das Shadowing übers Netzwerk überhaupt möglich ist, muss ich auch "RemoteFileOpenAbility" aktivieren. Da wird aber von Firebird vor gewarnt.
• Bremse ich damit den Hauptserver aus ?
• Wäre es evtl. eine Option Shadow lokal zu machen und das dann zu kopieren auf den Backupserver?
  • Nur da hätte ich ja evtl. hohen Datenverlust je nach Intervall des kopieren auf den Backupserver und bei einer großen Datenbank mit 20-30GB würde das glaub ich auch nicht so effektiv sein immer die ganze Datenbank zu kopieren.

Mein Ziel ist es schnellstmöglichen Wechsel auf den Backupserver, sowie geringstmöglichen Datenverlust bei Ausfall des Hauptservers zu erreichen.

Hat da jemand Erfahrung mit, bzw. wie würdet ihr da am besten vorgehen?

[mkinzler]

Da wäre m.E. Replikation besser geeignet.

[IBExpert]

wenn du es schaffst, das dein server (z.B. weil firebird.exe als applikation läuft und nicht als service)
auf das netzwerklaufwerk zugreifen kann, was in dem fall gehen würde, dann wäre damit der erste
Teil des Problems gelöst. Alternativ ginge auch irgend protokoll was physikalische netzwerklaufwerke
als lokale erscheinen lässt (iSCSI zB)

Mit dem Einrichten des Shadows gibt es noch parameter AUTO/CONDITIONAL/MANUAL die ganz unterschiedlich reagieren
falls das shadow nicht erreichbar ist, der default (oder AUTO) hängt das shadow einfach ab wenn es nicht mehr erreichbar
ist, vorteil, die db kann weiter benutzt werden, nachteil, die db wird weiter benutzt ohne shadow

bei MANUAL ist die db nicht mehr benutzbar wenn das shadow nicht erreichbar ist, beim Betrieb über das Netzwerk
gibt es da viele gründe warum das so sein könnte.

Und ganz wichtig: mit aktivem Shadow wird beim commit alles was an pages geschrieben werden muss in die db und
auch in alle shadows geschrieben.

Solltest du nun zB einen sehr schnellen nvme ssd based server mit 2gb read/write pro sekunde und 200000 iops
über ein netzwerk deiner wahl an einen gleich schnellen als shadow partner anbinden, dann wirst du sehen,
wie lahmarschig netzwerke im vergleich zu ram/mainboard/cpu/pci/nvme

da ist es auch völlig egal ob du 1gbit oder 10gbit leitung hast, die latenz für den schreibvorgang
ist dabei das problem (die leben bei der performance davon, das man große pakete über den draht
schickt und nicht wie bei fb eher sehr viele sehr kleine pakete).

wenn die bei ausführen eines sqls in ibexpert zB die performance analyse anzeigt das der schreibvorgang
zB 100000 reads und 10000 writes ausgelöst hat, dann kannst du davon ausgehen, das die 100000 reads nicht
das problem sind, weil lesende pages werden immer aus der lokalen db geholt und nicht aus dem shadow,
die 10000 writes brauchen aber nu nicht nur einfach per dma o.ä. vom ram via mainboard chipsatz in die
ssd kopiert werden, sondern wandern zusätzlich durch den ganzen OS Overhead tcp/ip socket, werden dann
durch ein kabel in anderen strom/spannung verwandelt und dabei serialisiert (so viel drähte hat dein
netzwerk ja nicht wie pins am ram modul sind), dann kommt je nach kabellänge noch einstein ins spiel
mit lichtgeschwindigkeit eiert aber evtl noch mal durch einen router oder switch
und auf der gegenseite macht dann wieder ein OS und der treiber aus dem Strom wieder daten,
überlegt sich, welcher Prozess dafür gerade zuständig ist, der Prozess selber überlegt sich, ob
er gerade zeit und lust zum schreiben hat, übergibt das wieder aus dem ram and das mainboard, von da an
die lokale ssd usw. usw.

ich weiss, ich schweife ab, aber als Zusammenfassung

Wenn du eine sehr geringe Schreiblast auf einer kleineren DB hast, dann könntest du ein Shadow im Netz
mit MANUAL auf einem möglichst schnellen server in einem eigene netzwerksegment mal antesten ,
es wird aber garantiert auch dann alles deutlich langsamer was schreibvorgänge sind bis hin zur blockade
wenn der shadow rechner gerade kein bock hat, warum auch immer. Im Auto Modus wird das shadow schneller
abgehängt sein als du denkst und dann ist das ganz gefährliche pseudo sicherheit, weil es sein kann,
das dir das shadow zwar bis zu den datapages alles sauer geschrieben wurde, die transaktioninventory
page dann aber nicht mehr. Mit MANUAL passiert das nicht, weil du ab dem Fehlerhaften Schreibvorgang
eh nicht wieter arbeiten kannst und damit der Schreibvorgang da auch nicht abgeschlossen ist.

Und mehr infos als die Systemtabelle rdb$files hast du nicht um auf fehlersuche zu gehen

Eine Replikation (was wir ja nun schon seit jahren machen und da nur per sql zwischen
den datenbanken sachen repliziert) wird so wie wir das machen niemals irgendwelche
pages halb übertragen.

bei fb4 wird es ja eine replikation geben, was ich davon halten soll ewiss ich noch nicht, weil das
was wir brauchen und praktisch einsetzen weit über das hinaus geht, was auch nur für fb5 geplant ist,
das mag aber für deinen anwendungsfall anders sein.

Ein replikationsersatz ist ein shadow aber garantiert nicht

[IBExpert]

noch ein tip als idee

wenn du eine externe nvme oder schenlle sata ssd an einem server anschliesst und darauf den shadow betreibst,
dann wird das auch die performance beeinträchtigen, aber nicht so schlimm wie über das netzwerk.

Und der weg hätte auch mit MANUAL den vorteil, das alles was in deinem Server committed ist, auch ziemlich
zügig auf dem Sahdow ist.

Und wenn dann nun das Worst case Szenanrio eintritt und der Server sich komplett verabschiedet und
auch durch power off/on nicht wieder zum Leben erweckt werden kann (was bei firebird mit forced writes
aktiv fast immer unproblematisch ist, ob das OS das abkann ist ein anderes problem und bei vms
kommt noch deren caching dazu, also noch mehr möglichkeitem das alles in dem Fall nach hinten los geht)
dann nimmst du dir die ssd im hot plug rahmen, steckst die in den vorgesehenen backup server
und hast da die komplette db im letzte möglichen zustand, weil nichts anderes ist das shadow.

wenn ex aber ein maximales worst case szenario ist (stichwort server und backup server im WTC 9/11)
dann ist das Verfahren zwar auch ungeeignet, aber offensichtlich das geringste Problem. Eine
woanders laufende asynchrone aber nahzu realtime replikation ist da weit vorteilhafter.

Es ist auch immer wichtig, mal dem verantwortliche vorzurechnen, was ein Ausfall des Systems
bedeutet und wenn dann die einzige chance ist, das backup von gestern einzuspielen, dann
kann das durchaus in vielen Branchen neue Budgets und Prioritäten frei machen.

generell ist es möglich, das wir jede Firebird Datenbank um eine replikation erweitern, wenn das
Datenmodell nicht völlig dilletantisch erstellt wurde

[lxo]

Vielen Dank für die ausführliche Antwort.
Hat mir schonmal deutlich weitergeholfen die Thematik zu verstehen.

[Frickler]

Zitat von IBExpert:

bei fb4 wird es ja eine replikation geben, was ich davon halten soll ewiss ich noch nicht, weil das
was wir brauchen und praktisch einsetzen weit über das hinaus geht, was auch nur für fb5 geplant ist,
das mag aber für deinen anwendungsfall anders sein.

Wie schlägt sich denn die Replikation in Interbase mit den "Change Views" im Vergleich?

Letztens mal wieder in die Interbase Doku reingeschaut. Mal abgesehen von "Change Views" und "truncate table" befindet sich Interbase-SQL auf dem Stand von Firebird 1.5....

[TurboMagic]

Dafür kann es DBs AES verschlüsseln was FB m.W. erst seit V3.0 kann und da auch nur mit Anbindung eines externen Moduls.

[knuut21]

Ein sehr interessantes Feature on Interbase ist hier das incremental Backup.. Das ist im Grunde genommen nichts anderes als eine Online Kopie der Datenbank, welche durch wiederholtes Ausführen mit gleichem Ziel lediglich die Pages aktualisiert und eine Datenbank im Read-Only-Modus erstellt. Wir setzen es für unsere 230 GB große DB ein. Bei ca. 2 - 2,5 Mio. Transaktionen pro Tag braucht eine Aktualisierung der DB - bei entsprechender Hardware - 2 -3 Minuten. Für das "primäre" online Backup keine 30 Sec. Wenn es regelmäßig ausgeführt wird ist die Aktualisierung der sekundären Backups innerhalb von 1-2 Minuten fertig.

BG