|
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? |
AW: Firebird Shadow Netzwerk
Hätte man bei inkrementellen Backups die Möglichkeit, beim restore die Zieldatenbank nicht ganz neu zu erstellen sondern nur den Teil des letzten Backups anzuhängen.
So wie ich das verstanden habe, wird beim restore von inkrementelle Backups auch immer die Datenbank komplett neu aufgebaut. Vorteil wäre ja nur, dass man die Backupzeit bzw. den Backupintervall im Gegensatz zu einem Vollbackup reduzieren kann. Versteh ich das richtig? |
AW: Firebird Shadow Netzwerk
Das inkrementelle Backup ist eine Read-Only-Version der Datenbank, auf die im laufenden Betrieb im Read-only-Modus zugegriffen werden kann. Entweder mit der gleichen Instanz des IBServers oder einer zweiten.
Diese sog. Online-Dmps der Datenbank sind nicht mit einem regulären Backup zu vergleichen, eher als eine physikalische Kopie der Datenbank, welche nicht auf File-Ebene erzeugt wird, sondern durch den IBServer selbst erfolgt und somit die Konsistenz der Datenbank erhalten bleibt. Nützlich um z.B. AdHoc eine Kopie der Datenbank zu erzeugen, sei es um irgendwelchen Fehlern ausserhalb des Produktivsystems nachzugehen oder um irgendwelche statistischen Auswertungen über die Instanz eines anderen Servers durchzuführen. Aber natürlich auch, um eine Kopie der Produktivdatenbank vorzuhalten. Um einen online Dump in eine produktive Datenbank umzuwandeln benötigt es hier lediglich der Umstellung vom Read-Only-Mode in den Read-Write-Mode, entweder über die IBConsole oder gfix.exe. Insofern, angenommen, die Aktualisierung des primären Dumps erfolgt jede Minute, würde sich hier die Downzeit im Fehlerfall deutlichst reduzieren, da kein Restore der Datenbank notwendig ist. Am Ende des Tages ist m.E.n weder eine Replikation noch die Verwendung der online Dumps als alleinige Absicherung gegen Ausfall als DIE Methode zu betrachten, vielmehr kann es nur ein zusätzliches Mittel sein, um die Down-Zeit im Disaster-Fall zu reduzieren. Ein regelmäßiges Backup ist aus meiner Sicht unabdinglich. BG |
AW: Firebird Shadow Netzwerk
Da Änderungen an der Datenbank ja nicht nur am Ende sondern verteilt stattfinden, funktioniert das mit dem Anhängen natürlih nicht. Eine inkrementelles Backup beschleunigt den Backupvorgang, verlangsamt aber die Rücksicherung, da nun ja wiederum mehrere Backupbestände zusammengeführt werden müssen. Willst Du eine (quasi zeitverlustfreie) arbeitsfähige Kopie auf einem anderen Server haben, ist eine Repliktion die Methode der Wahl, sei es durch eingebaute Mittel des DBMS, Fremdlösungen oder selbstgestrickt (nicht als abwertend gemeint).
|
AW: Firebird Shadow Netzwerk
es gäbe mehrere Wege Ausfallsicherung herzustellen oder auch aus Skalierungsgründen mehr als einen Server
zu haben, auf dem ausreichend aktuelle Daten synchron gehalten werden Anderes Beispiel aus der Praxis: IBExpert hat einen Funktion tools-table data comparer, geht auch mit der script funktion ibec_CompareTables (dort sogar noch flexibler als in der IDE) Wir haben für einen Kunden, der das schon lange benutzt, einige Restriktionen für seine DB vorgegeben die er einhält und daher auf diesem Weg in nahezu Realtime minütlich daten synchronisiert auf mittlerweile glaub ich 3 backuppsserver. Die Restriktionen bzw Empfehlungen: -Jede abzugleichende Tabelle hat einen immer gleich benanntes Primärschlüssel feld, wir nehmen als Feldname immer ID und das ist immer ein Bigint. Es müsste zwar gar nicht immer gleich lauten weil die ibe table data compare funktion das auch mit anderen Feldnamen und typen kann, aber besser sagen: mach es immer so als zu sehen, das es immer anders gemacht wird. Wirklich aber wichtig: Jede Tabelle hat einen Primärschlüssel! -Aus Vereinfachungsgründen werden alle Primärschlüsselwerte immer aus einem zentralen generator für alle Tabellen geholt (also nicht einer pro Tabelle, sondern alle benutzen den gleichen). Auch diese Restriktion ist eher ein Empfehlung, weil für den Abgleich nicht erforderlich, aber generell immer gut (wer angst hat das ein 64bit integer nicht reicht: wer 4 Milliarden Generatorwerte pro Sekunde abruft, kommt damit ca 130 Jahr hin, ohne das ein wert doppelt vergeben wird. das sollte für alle Anwendungen ausreichen ...) -Nun die erste echte Restriktion: In jeder Tabelle gibt es ein Timestamp (nennen wir zB R$TS Timestamp in dem bei jedem Insert, Update oder Delete der zeitstempel aktualisiert wird. Berechtigte Frage: Wieso beim Delete? -Nun die nächste Restriktion: Datensätze werden niemals gelöscht sondern durch einen Zeitstempel in einer weiteren Spalte in jeder Tabelle sozusagen unsichtbar geschaltet und erst viel später gelöscht wenn die synchronisation durch ist. Nehmen wir dafür mal als Feldname R$DEL Timestamp an. Wenn Ihr als irgendwelche SQLs vom Server haben wollt, setzt ihr also generell für jede beteiligte Tabelle "where tab1.r$del is null and tab2.r$del is null ... " Wenn da ein Index drauf ist, geht das ausreichend schnell. -Ob Ihr den Abgleich nun selber macht oder mit ibec_CompareTables ist realtiv egal, aber in der script Funktion geht so was als ergänzung ibec_CompareTables(MasterDB, SubscriberDB, 'TAB1,TAB2', 'TAB1,TAB2', 'E:\CompRes.sql','OmitDeletes; Where="WHERE R$TS>DATEADD(MINUTE,-1,CURRENT_TIMESTAMP)"', cbb); d.h. alle Tabellen in der erste Master tbl liste werden mit den hoffentlich gleichartig stukturierten Tabellen in der Subscriber DB verglichen, wenn der Zeitstempel r$ts innerhalb der letzten minute geändert wurde. Wenn Ihr nun auch noch folgendes macht: Einen User nur für die Synchroniation anlegen zB R$ und mit diesem User, der natürlich an allen relevanten Tabellen schreib+Lese rechte haben muss, und alles was in jeden eurer Trigger folgende erste Zeile direkt nah dem begin einsetzt if (current_user='R$') then exit; damit nicht in der synchronen Subscriber Version was passiert, das im Master schon lief. Je nach Anzahl der Tabellen läuft das Script mehr als ausreichend schnell durch und kann mit der ibescript.exe (gibt es auch gesodnert als servertools oder oem zu unlimited distribution, alternativ auch auch 32bit dll) und die db ist minütlich auf dem stand der Dinge, in der online doku zu sind auch ncoh spezielle sparameter beschrieben, am besten auf dem funktionsnamen in ibexpert editor stehen und f1 drücken oder gleich hier https://www.ibexpert.net/ibe/pmwiki....cCompareTablesSyncOnline: sobald irgendeine differenz gefunden wird, legt der mit der ausführung im zweiten thread los udn wartet nicht bis alles fertig ist UseHashFunc: blobs werden nicht komplett von beiden datenbanken geholt und verglichen sondern nur deren Hash (so eine art quersumme, die dann traffic minimiert). UpdateOrInsert: wenn ein record in der master db gerade geändert wurd, im subscriber aber zuletzt vor eine stunde, wäre der im abgleich nicht dabei, durch den dann erzeugten update or insert ist das egal, weil der dann ggf änderungen und auch den neuen r$ts und r$del zeitstempel über den pk mitbekommt-. Und wenn ihr sicher seit, das alle Synchronisationsziele abgeglichen sind könnt ihr dann einfach mal alle records in allen Tabelle löschen, bei denen zB R$DEL älter als die Minute ist, ein puffer ein wenig größer mit zB 10 Minuten zu setzen wäre nicht schlecht. hilfreich sind dabei dann übrigens fks mit cascaded deletes damit ihr nicht selber die Abhängigkeiten abklappern müsst.. Das o.a. Prinzip geht zuverlässig nur als Master-Multislave, Multimaster (also mehrere Standorte schreiben ggf sogar auf gleichen Records kann dabei seltsame Ergebnisse bringen, frei nach der Devise, wer zuletzt synchronisiert hat, hat gewonnen) machen wir eben anders, aber das Konzept wie hier beschrieben ist mit einer dafür enworfenen Datenbank (oder passenden Zusatzfeldern in einer bestehenden) schnell umsetzbar und auch flexibel, weil man theoretisch im Master gar nicht löschen muss, sondern einfach alles drin lässt, wenn der Client das eben soweiso nicht anzeigen würde und wenn die Subscriber DB zB seit gestern abend offline war, startest du den sync halt mit ibec_CompareTables(MasterDB, SubscriberDB, 'TAB1,TAB2', 'TAB1,TAB2', 'E:\CompRes.sql','OmitDeletes; Where="WHERE R$TS>DATEADD(MINUTE,-720,CURRENT_TIMESTAMP)"', cbb); so das der alle records der letzten 12 Stunden abgleicht .... Ich nenne das Verfahren nicht replikation, sondern Synchronisation, ist aber sicherlich für einige ein denkbarer weg, das auch so ähnlich zu machen, bietet weit mehr Sicherheit als ein Backup von gestern abend einzuspielen. Auf datenpage ebene machen übrigens nbackup das vergleichweise ähnlich, nur das du damit auf der Gegenseite bis zum Restore nix anfangen kannst. Bei dem o.a. Verfahren kannst du wie beim dem beschriebenen Kunden für seine komplexen datawarehouse/BI reports eigene Hardware anschaffen, auf denen die machen können, was die wollen, aber damit nicht die Anwender auf der Master DB in den Wahnsinn treiben, weil jemand da wieder bescheuerte SQLs in 10 parallelen Sessions gestartet hat und jeder auf den warten muss ... Und wenn die Server an unterschiedlichen Standorten stehen und die Leistung dazwischen recht lahm ist, dann kommt das System auch durchaus mal an Grenzen, weil für den Abgleich alle Server recordstände auf alle seiten abgeglichen werden müssen, replikation weiss selber schon, was sie senden soll ohne die andere seite erst zu fragen, was der alles nicht weiss. Aber vielelicht hilft das ja einigen als Idee .... |
| Alle Zeitangaben in WEZ +1. Es ist jetzt 18:28 Uhr. |
Powered by vBulletin® Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024 by Thomas Breitkreuz