Firebird Shadow Netzwerk

[lxo]

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?

[knuut21]

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

[mkinzler]

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).

[IBExpert]

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....cCompareTables

SyncOnline: 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 ....