|
Datenbank: Firebird • Version: 3.0.7 • Zugriff über: UniDac
Firebird Shadow Netzwerk
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.
Für die Datenbank auf dem Hauptserver würde ich ein Shadow anlegen, mit Ziel auf dem Backupserver. Also in etwa so:
Meine Fragen dazu ...
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? |
AW: Firebird Shadow Netzwerk
Da wäre m.E. Replikation besser geeignet.
|
AW: Firebird Shadow Netzwerk
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 |
AW: Firebird Shadow Netzwerk
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 |
AW: Firebird Shadow Netzwerk
:thumb: Vielen Dank für die ausführliche Antwort.
Hat mir schonmal deutlich weitergeholfen die Thematik zu verstehen. |
AW: Firebird Shadow Netzwerk
Zitat:
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.... |
AW: Firebird Shadow Netzwerk
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.
|
AW: Firebird Shadow Netzwerk
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 |
AW: Firebird Shadow Netzwerk
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. |
AW: Firebird Shadow Netzwerk
Zitat:
Oder kann ich direkt mit dem "Incremental Backup" wie mit einer normalen Datenbank weiterarbeiten?
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? |
| Alle Zeitangaben in WEZ +1. Es ist jetzt 15:58 Uhr. |
Powered by vBulletin® Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024 by Thomas Breitkreuz