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