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

[IBExpert]

incremental backup heisst bei firebird nbakup, ist ein extra binary und gibt es seit
fb20, also ca 2006.

Da wir im allgemeinen blobs gar nicht erst in Unmengen in der production db
drin lassen, sondern per trigger und execute statement on external in extra
blob datenbanken übertragen, deren ältere versionen dann je nach datenvolumen
jährlich oder monatlich readonly geschaltet werden, sind bei vielen Kunden Production
datenbanken vielleicht 10-20 gb groß und ob dann in den blobs 500GB archiviert sind ist
egal, weil die gar nicht täglich oder auch wochenweise gesichert werden müssen, denn die
werden nur nach der Umstellung auf Readonly ein letztes mal gesichert.

Die Inhalte holen wir dann entweder über views oder direkt per sp jeweils wieder mit execute
statement on external auch den archivdatenbanken, es kann dabei auch ein ganz anderer server
sein, auf dem die liegen. Geändert oder gelöscht werden die großen (pdf, docs, emails, etc)
Inhalte eh nicht mehr, daher vermeiden wir auf dem weg das wir endlos lang laufende Backups
haben. Und auf den von uns vertrieben IFS Firebird Servern braucht ein Backup für eine 20GB
Datenbank realistisch 30-45 Sekunden, warum sollen wir dann inkrementell sichern und im
Restore Fall erst mal wieder sämtliche Inkremente zusammensuchen und wenn nur eines fehlt
kann ich alles wegwerfen. Wir nutzen auch nicht nbackup, aber wer da vielelicht andere
Strukturen hat oder langsamere Server, why not.

Changeviews kenn ich vom Namen und von der Idee dahinter nur begrenzt, weil ich auch das
nicht brauch. Mit der Art der Replikation, wie wir die machen, haben wir zum Beispiel
bei einem mittelständischen Betrieb mit ca 60 Mitarbeitern alle datensätze in allen
Tabellen als redo und undo sql in einer extra log db, die mittlerweile in Richtung
600GB geht, aber auch auf mehrere verteilt ist. Durch aufruf einer SP mit einer
Transaction ID können wir dabei alles was in dieser Transaktion passiert ist, wieder
als reverse undolog aufrufen und auf dem Weg sogar wie in einem Fall mal erforderlich
eine versehentlich gelöschte Baumstruktur mit weit mehr als 10000 Records in über 30
Tabellen wieder herstellen, nachdem wir im gleichen Log nachgesehen haben, mit welcher
Transaktionsnummer der verdächtige User das zu welcher Uhrzeit in etwa als delete befehl
im Redolog ausgelöst hat (obwohl da im Front end noch mehrere Sicherheitsabfragen kamen).

Wenn ich das richtig verstehe, könnte ich bei Interbase nun mit changeviews Tabellen
ganz oder teilweise deklarativ mit einem ähnlichen Protokoll ausstatten, nach meinem
Kenntnisstand wäre dann aber die 600GB Teil der production db, weil Interbase das nicht
extern kann bzw execute stament on external auch mit blobs eh nicht kann.

Alles was wir da machen und wie wir das machen ist mit FB25 bordmitteln transaktionssicher
innerhalb der Datenbank also kombination von triggern und SPs umgesetzt, es ist also nicht
so das Firebird da vielleicht irgendwas nicht kann,

In einem meiner IBExpertise Video hatte ich das ja mal genauer gezeigt, falls jemand
weitere details braucht.

Zur ursprünglichen Frage: Ich glaub nicht annähernd das man mit change views in irgendeiner
weise 200 replizierte Datenbankstandorte in verschiedenen Städten organisieren kann, wie wir das
ja machen, aber vielelicht weiss ich darüber nur zu wenig. d.h. Replikation ist nun mal
was komplett anderes, change views machen aus meiner sicht logging

Und zur anderen Frage: Incremental Backup? geht, brauch ich aber nicht und will ich auch gar
nicht machen müssen, liegt aber eben auch daran, das wir nicht eine Datenbank als großen Mülleimer
für alles benutzen, sondern schon zeitnah prüfen wie man die Inhalten automatisiert
mit Bordmitteln verteilt speichern kann, ohne das der Programmierer da wirklich was
am Front End dazu umbauen muss.

[lxo]

Zitat von 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

Aber das ist ja nur ein Backup, dass dann noch wiederhergestellt werden muss oder nicht?

Oder kann ich direkt mit dem "Incremental Backup" wie mit einer normalen Datenbank weiterarbeiten?

• Wäre das dann nicht das gleiche wie Shadows bei Firebird ?

Vorteil hätte ich natürlich damit, dass es nicht so viel Datenverlust gibt als wenn ich in größeren Abständen Vollbackups mache.
Zeitlich würde dies beim wechseln auf den "Ersatz/Backup"-Datenbankserver aber kein weiteren Vorteil haben oder?