Replikation, d.h. Abgleich von verschiedenen Datenbeständen, ist ein komplexes Thema. Am besten vermeidet man Replikation ganz, z.B. durch den Einsatz zentraler Datenbanken. In Wide Area Networks (WAN) sind jedoch nicht immer alle Verbindungen verfügbar. Dann ist ein Off-Line Betrieb einzelner Teile des WANs sinnvoll. Werden dann alle Server wieder miteinander verbunden, ist ein Abgleich notwendig.
Der InterBase Replication Demon ist ein System von Programmen, das den Abgleich von InterBase Servern ermöglicht.
Zuerst werden die Neuerungen der neuen Version beschrieben. Dann erfolgt die Beschreibung verschiedener Replikationskonzepte und deren Realisierung mit dem InterBase Replication Demon, anhand des Konfigurationswerkzeuges des InterBase Replication Demon. Abschließend werden die weiteren Tools beschrieben. Im Anhang finden Sie eine Beschreibung der Konfigurationstabellen des Replikationsdatenbankschemas. Damit ist es möglich, das System über SQL zu konfigurieren.
Da die Einrichtung einer Replikation sehr stark von den individuellen Bedürfnissen der jeweiligen Anwendung abhängt, können in diesem Handbuch nicht alle Aspekte berücksichtigt werden. Wenn in Ihrem speziellen Fall Fragen offen bleiben, wenden Sie sich bitte an uns info@sdctec.de.
Am Ende einer Replikation werden statistische Daten protokolliert, so dass an Hand dieser Information eine bessere Anpassung an die konkrete Situation durchgeführt werden kann.
Zu dem können Mails an verschiedene Empfänger je nach Abschluss einer Replikation versandt werden. Das Netzwerk muss dafür Zugriff zu einem SMTP-Server haben.
In der Version 1 des InterBase Replication Demon wurde die gesamte Replikation von einem Demon aus zentral durchgeführt. Dieser nahm Kontakt mit allen verfügbaren Servern auf.
In der neuen Version des InterBase Replication Demon wurde die Replikation dezentralisiert, d.h., auf jedem Server befindet sich ein Demon. Dieser kann nun, insbesondere bei einer Sternreplikation, die Daten unabhängig von anderen Demons abgleichen. Dabei ist sichergestellt, dass im Falle eines Rollbacks der Transaktion, die anderen Server weiter arbeiten können. Natürlich ist es bei entsprechenden Anforderungen an die Transaktionssicherheit möglich, die Konstellation gemäß Version 1 zu konfigurieren und die Replikation zentral durchzuführen.
Die Dezentralisierung des Systems verlangt eine gute Unterstützung des Administrators bei seiner Arbeit.
Das neue System stellt einen InterBase Replication Guardian zur Verfügung, dieser überwacht die Ausführung des InterBase Replication Demon und startet ihn ggf. neu. Er handelt also analog zum InterBase Guardian. Zu dem bildet der InterBase Replication Guardian, die Schnittstelle für das InterBase Replication Terminal.
Das InterBase Replication Terminal ermöglicht die Überwachung aller im Netz befindlichen Guardians. Das Terminal zeigt den aktuellen Status eines Servers an. Bei Problemen kann so gezielt eingegriffen werden. Das Terminal erlaubt den Restart eines Demon und ggf. auch den Austausch. Dies ist z.B. bei einem Update des Systems notwendig.
Unter Replikation versteht man das Abgleichen und Synchronisieren der Inhalte von verschiedenen räumlich verteilten Kopien einer Datenbank. Dabei stehen die verschiedenen Kopien der Datenbank miteinander im Zusammenhang und deren Datensätze können verändert werden.
Mit der Replikation werden vorgenommene Änderungen der verschiedenen Datenbankkopien verglichen und ausgetauscht, so dass alle eingebundenen Datenbankkopien anschließend wieder über einen konsistenten Datenbestand verfügen.
Für eine erfolgreiche Replikation müssen alle Änderungen in den angeschlossenen Kopien der Datenbank festgehalten werden. Dazu wird häufig das Transaktionslogfile ausgewertet. In dieser Datei werden die Datenbank Operationen für die jeweilige Datenbank protokolliert. Die Operationen werden dann für die Replikation auf der Zielplattform wiederholt. In den meisten Produkten, die serienmäßig einen Replikationsmechanismus anbieten, wird diese Technik verwendet. Sie wird bei Informix, Sybase und MS SQL eingesetzt.
Bei InterBase kann diese Technik nicht zum Einsatz kommen, da InterBase auf Grund seiner Multigenerationsarchitektur kein Transaktionslogfile benötigt und daher einer Replikation dieses auch nicht zur Verfügung steht. Bei InterBase müssen Datenbank-Trigger benutzt werden, um Datenänderungen im Moment des Auftretens in eine Protokolltabelle für die Replikation zu sichern. Dieses Verfahren ist wesentlich flexibler und kann Plattform übergreifend implementiert werden, da mit der prozeduralen Sprache der Serverplattform gearbeitet wird. InterBase Trigger arbeiten sehr schnell, so dass das für diese Art des Protokolls übliche Gegenargument, der mangelnden Performance, nicht greift.
Die Programmierung der Trigger kann bereits Regeln für die zu replizierenden Daten beinhalten. Dieses Verfahren wird ebenfalls bei den Replikationsprodukten von Ingres und Oracle benutzt und ist beim InterBase Replication Demon für InterBase implementiert worden.
Die Übertragung der geänderten Daten erfordert ein Replikationsprogramm, den InterBase Replication Demon, der das Änderungsprotokoll auswertet. Dieser Demon verbindet sich mit den über ein LAN oder WAN an der Replikation beteiligten Datenbank Servern und führt die Änderungen durch.
Eine bidirektionale Replikation erfordert ein Management zur Verarbeitung von Änderungen, die gleichzeitig an denselben Datensätzen vorgenommen wurden (Konfliktmanagement). Die Applikation muss in der Lage sein, Änderungskonflikte zu erkennen und eine geeignete Verarbeitung zur Verfügung zu stellen. Dies kann z.B. durch benutzerdefinierte Verarbeitungsregeln geschehen. Je häufiger die Replikation durchgeführt wird, desto weniger Änderungskonflikte sind zu erwarten.
Der InterBase Replication Demon bietet die Möglichkeit, Ihr individuelles Konfliktmanagement zu integrieren. In der normalen Ausführung ist ein "last write wins" Algorithmus implementiert, der der letzten Änderung an einem Datensatz den Vorrang gibt. Über nicht akzeptierte Änderungen wird in einer Konflikttabelle informiert. Werden andere Konfliktlösungsverfahren benötigt, können diese in den InterBase Replication Demon als individuelle Erweiterung integriert werden.
Viele Replikationsprogramme brauchen einen numerischen Schlüssel, der lediglich in einem Feld verwaltet wird. Mit dem InterBase Replication Demon kann ein mehrteiliger Schlüssel verwendet werden, der auch aus alphanumerischen Werten bestehen kann, um einen Datensatz eindeutig zu identifizieren.
Die Replikation ist direkt auf der InterBase API programmiert. Somit wird nicht auf ODBC oder die Borland Database Engine (BDE) zugegriffen. Durch den Verzicht auf diese Zwischenschichten wird unnötiger Overhead verhindert.
Nicht nur "normale" Datenfelder, sondern auch der Inhalt von BLOB Feldern (Binary Large Objects), dies sind üblicherweise große Textdokumente, Bilder oder Videos können repliziert werden.
Alle für die Replikation notwendigen zusätzlichen Datenbankstrukturen werden neben Ihre Datenbankstrukturen gestellt. Ihre Anwendung bleibt unverändert.
Sind bei einem Replikationslauf einzelne Server nicht zu erreichen, kann die Replikation trotzdem durchgeführt werden. Die betroffenen Server erhalten die entsprechenden Daten später, z.B. mit dem nächsten Replikationslauf.
Über das Konfliktmanagement können Sie entscheiden, welche vorgenommenen Änderungen den Vorrang beim Abgleich bekommen. Eine automatische Lösung wird von den meisten Replikationssystemen abgelehnt.
Wir bieten Ihnen passend zu Ihren individuellen Anforderungen die Implementation von individuellen Konfliktlösungsstrategien.
Den InterBase Replication Demon können Sie individuell nach Ihren Anforderungen konfigurieren. So können Sie z.B. festlegen, welche Server oder welche Tabellen und welche Felder eines Datensatzes repliziert werden sollen.
InterBase Generatoren liefern innerhalb eines Servers eindeutige Werte. Zur Sicherstellung einer eindeutigen Vergabe von Generatorwerten im ganzen Netzwerk, wird von globalen Generatoren mit Hilfe des InterBase Replication Demon an die einzelnen Server ein jeweils eindeutiger Nummernbereich vergeben.
Der InterBase Replication Demon benötigt einzig TCP/IP-Verbindungen zwischen den Servern. Daher besteht ohne weiteres die Möglichkeit der Einsatz im Internet bzw. Intranet Ihres Unternehmens.
Insbesondere ist bei einer großen Anzahl von Servern eine zentrale Konfiguration notwendig. Dabei kann eine neue Konfiguration an einem Server (zentral) erstellt werden und dann automatisch an alle anderen Server übertragen werden.
Der InterBase Replication Guardian und das InterBase Replication Terminal ermöglicht die Überwachung des Status des InterBase Replication Demons und den Austausch der Demonen auf den einzelnen Servern im Falle eines Updates.
Bei der Beschreibung der Installation gehen wir davon aus, dass Sie an einem "zentralen" System arbeiten und sich alle anderen Server auf "entfernten" Systemen befinden. Das zentrale System der Konfiguration muss nicht (sofern es überhaupt existiert), der zentrale Server der Replikation sein. Am zentralen System der Konfiguration werden das InterBase Replication Terminal und ggf. Konfigurationsschablonen hinterlegt. Jeder an der Replikation beteiligte Server sollte auf dieses System zugreifen können und jeder Server sollte von diesem System erreichbar sein.
Sofern es noch notwendig ist, installieren Sie den InterBase Server auf allen Systemen, falls Sie den InterBase Server im Bundle von uns erworben haben, verwenden Sie die Ihnen zu Verfügung gestellten Lizenzschlüssel.
Führen Sie die Installation des InterBase Replication Demon durch Aufruf des Setup- Programms auf allen an der Replikation beteiligten Servern aus. Beachten Sie die einzelnen Schritte, des Setup-Programms.
Installieren Sie dabei auf den "entfernten" Systemen den Replication Demon und den Guardian und auf Ihrem zentralen System zusätzlich die Tools & Skripts.
Dabei sind folgende Hinweise zu beachten:
Der InterBase Replication Demon setzt ein vollständig auf Hostnamen basierendes TCP/IP-Netzwerk voraus. Zu weiteren Informationen zu diesem Thema konsultieren Sie den Netzwerkadministrator oder die einschlägige Literatur.
Ob das Netzwerk und die Remote Funktionalitäten von InterBase einwandfrei arbeiten, können Sie mit dem InterBase Communications Diagnostic Programm verifizieren.
Der Setup installiert im einzelnen:
| rpModul.dll | im InterBase/Bin Verzeichnis, eine UDF-Erweiterung Ihres InterBase Servers bzw. beim Einsatz von InterBase 6 im Verzeichnis InterBase/UDF. |
| rpDemon.exe | den eigentlichen InterBase Replication Demon, standardmäßig im Verzeichnis c:\Programme\SDCTec\IBRDemon |
| rpDemon.ini | enthält im wesentlichen den lokalen Pfad zur Datenbank, damit der Demon einen Connect zu seiner Konfiguration ausführen kann. |
| rpGuard.exe | den InterBase Replication Guard im Verzeichnis des Demon |
| und zusätzlich auf Ihrem zentralen Konfigurationssystem | |
| rpConfig.exe | das Konfigurationsprogramm im Verzeichnis des Demon |
| rpTerminal.exe | das InterBase Replication Terminal |
| rpTables.sql, | das SQL-Script zum Anpassen Ihres Datenbankschemas |
| rpManual.doc, | dieses Dokument |
Wichtig: Bevor Sie das System um die Replikation erweitern, machen Sie sich bitte eine Datensicherung und schaffen so eine Entwicklungsumgebung. Installieren Sie die Replikation erst in Ihrem produktiven System, wenn Sie Ihre Konfiguration ausreichend getestet haben. Wir übernehmen für alle Softwarehersteller keine Haftung für verlorengegangene Daten und sich daraus ergebende Folgen.
Nachdem die Programmdateien installiert sind, müssen Sie Ihr Datenbankschema um die für die Replikation notwendigen Tabellen und Prozeduren erweitern. Dazu dient das Script rpTables.sql, das Sie zusammen mit den Tools im Verzeichnis des InterBase Replication Demon auf Ihrem zentralen System installiert haben.
Starten Sie dazu das Konfigurationswerkzeug rpConfig.exe und bauen Sie über Datei | DB-Connect eine Verbindung zur Datenbank auf.
Werden dann die Konfigurationstabellen der Replikation nicht gefunden, fordert Sie das Werkzeug auf, das Replikationsskript anzuwenden.
Bestätigen Sie dies, laden Sie das Skript mit
und starten Sie dann die Ausführung des Skripts
mit 
Jetzt kann Ihre Datenbank für die Replikation konfiguriert werden.
Sie können das Script auch mit Hilfe von InterBase Windows ISQL oder der IBConsole ausführen. Passen Sie dazu in der ersten Zeile das Connect Statement an und führen Sie das Skript für jede an der Replikation beteiligten Datenbank notwendig aus.
Am einfachsten lassen Sie das Script gegen Ihre Datenbank laufen und verteilen diese per Datensicherung auf alle anderen Server, dann sind Sie sicher, dass alle Datenbanken die gleiche und richtige Struktur haben. Dies geht natürlich nicht, wenn auf Ihren Servern bereits unterschiedliche Datenbestände vorhanden sind.
An Hand der einzelnen Schritte im Konfigurationstool werden im folgenden die Konfigurationsmöglichkeiten des InterBase Replication Demon beschrieben. Ohne eine korrekte Konfiguration Ihres Systems ist keine Replikation möglich. Die meisten Probleme bei der Replikation sind auf eine fehlerhafte Konfiguration zurückzuführen.
Um eine zentrale Konfiguration zu ermöglichen, erfolgt die Konfiguration über Referenz- oder Konfigurationsdatenbanken. D.h., damit nicht jeder Server manuell eingerichtet werden muss, kann ein Server die Konfiguration aus einer anderen Datenbank laden. Ist kein Konfigurationsserver angegeben, muss die Datenbank selbst konfiguriert werden. Somit ist es möglich die Konfiguration lokal an den Vorlagen vorzunehmen. Das eigentliche Replikationssystem bezieht dann die neue Konfiguration aus den Vorlagen.
Im folgenden gehen wir davon aus, dass auf allen entfernten Systemen Datenbanken liegen, bei denen rpTables.sql angewendet wurde. Die Konfiguration erfolgt nun ausgehend von Ihrem "zentralen" System.
Starten Sie bitte das Replikationsprogramm und machen Sie einen Datenbank Connect auf Ihre Konfigurationsvorlage, die eine um rpTables.sql erweiterte Anwendungsdatenbank sein muss.
Die einzelnen beteiligten Server müssen
hinterlegt werden. Um einen weiteren Server anzulegen, verwenden Sie den Neu
Button 
.
Die einzelnen Felder bedeuten:
| Server ID | eindeutige Identifikationsnummer des Servers, diese muss nicht lückenlos sein |
| Server IP | Hostname (nicht IP-Adresse) des Servers |
| Datenbank | lokaler Datenbankpfad auf den entsprechenden Server |
| Lizenz | Serverlizenz wie in Ihren Unterlagen zur Verfügung gestellt. Je Server ist eine Extralizenz notwendig. Keine Lizenz kann doppelt verwendet werden. |
| OnLine | falls ja, bleibt die Datenbankverbindung nach einer Replikation bestehen, üblicherweise nein, da im Falle von vorhandenen OnLine Verbindungen besser mit einer zentralen DB statt mit einer Replikation gearbeitet wird |
| Parallel | erlaubt Replikationszugriffe auf den Server, während dieser selbst repliziert |
| via Server | (vgl. erweiterte Konfigurationsmöglichkeiten) |
| CFG-Datenbank | Netzwerkpfad der Konfigurationsvorlage |
| DialUp Netzwerk | Soll die Replikation eine Verbindung über das DialUp-Netzwerk (RAS) aufbauen, ist hier der entsprechende Eintrag der RAS-Konfiguration des Rechners auszuwählen. Es werden Ihnen die lokalen RAS Einstellungen angeboten, die RAS Einstellungen entfernter Systeme sind hier natürlich nicht bekannt, können aber eingegeben werden. Achten Sie auf die korrekte Schreibweise. |
Durch Drücken des entsprechendes Buttons können Sie eine Tabelle in die Replikation aufnehmen oder entfernen. Es werden dann alle notwendigen Trigger, Funktionen, Grants und Standardeinstellungen vorgenommen. Diese Angaben können Sie dann auf den nächsten Seiten ändern.
Sie können auch für Tabellen, die nicht direkt repliziert werden, die Grant-Rechte für den Replikationsuser RPDEMON anlegen. Dies ist notwendig, wenn Tabellen indirekt, z.B. über Trigger von der Replikation betroffen sind.
Das Feld Replikationsmodus beschreibt, auf welche Art die Daten geändert werden:
Der Vorteil von "U" ist, das mit "prepared" SQL-Statement gearbeitet werden kann, der Zielserver der Anwendung hat weniger zu tun, bei ausreichender Bandbreite des Netzwerks die schnellste Methode.
Bei der Variante "A" werden keine Vergleichsdaten von Zielserver zum Masterserver übertragen, dafür hat der Zielserver mehr mit der Interpretation des SQL-Statements zu tun. Dies ist bei geringerer Netzwerkbandbreite (z.B. bei Wählleitungen) die schnellere Methode.
Die Variante "C" stellt einen Kompromiss zwischen "U" und "A", um nicht permanent Felder zu ändern, deren Wert sich nicht geändert hat.
Das Feld Commit nach Sätzen wird in den erweiterten Konfigurationsmöglichkeiten beschrieben und sollte im Normalfall auf 0 stehen.
Für jeden Server kann angegeben werden, welche Daten gesandt, bzw. entgegengenommen werden. Standardmäßig werden alle Felder versandt und akzeptiert.
Sie können die Auswahl inklusive treffen, also durch Angabe der zu replizierenden Felder oder exklusiv, d.h. welche Felder nicht repliziert werden sollen. Beachten Sie, dass diese Einstellungen bei Änderungen der Datenbankstruktur Ihrer Anwendung ggf. angepasst werden müssen.
Über das Target wird bestimmt, an welche Server die Änderungen eines Servers übertragen werden. Bei gleichberechtigten Systemen erfolgt die Übertragung an alle Server. Bei einer Sternreplikation erfolgt nur von der Zentrale eine Übertragung an alle anderen Server. Die Filialen übertragen nur an die Zentrale. Fast beliebige Zwischenstufen sind denkbar. Beachten Sie auch den Abschnitt über erweiterte Konfigurationsmöglichkeiten.
Auf der letzten Seite sehen Sie die automatisch angelegten Trigger, diese können an die Anforderungen Ihrer Anwendung angepasst werden.
Wenn Sie einen anderen User als RPDEMON verwenden, müssen Sie selbst darauf achten, dass die Trigger entsprechend geändert werden und alle notwendigen GRANT-Rechte vorhanden sind.
Zur Vermeidung von Problemen mit der referentiellen Integrität gibt es zwei Strategien. Erstens, die Änderung in genau der Reihenfolge übertragen, in der sie vorgekommen sind. Nachteil dieses Verfahrens ist, das permanent zwischen den zu replizierenden Tabellen umgeschaltet werden muss, der Verwaltungsaufwand nimmt stark zu. Oder aber Zweitens, es wird eine geeignete Replikationsreihenfolge gewählt.
Wenn Sie die zu replizierenden Tabellen so
anordnen, dass die Tabelle ohne Abhängigkeiten zuoberst steht, d.h.
zuerst repliziert wird, und die mit den meisten Abhängigkeiten zuletzt,
dann ergibt die Default Reihenfolge
eine Anordnung, die das
Replizieren ohne Probleme ermöglichen sollte. Sie können aber die
einzelnen Einstellungen unter Berücksichtigung der Kenntnis ihrer
referentiellen Integrität beliebig sortieren 
.
Sie können auch einzelne Operationen auf
diesem Wege von der Replikation ausschließen 
,
allerdings werden diese, wenn ein entsprechender Trigger vorhanden ist
protokolliert. Da die Änderungen dann nicht übertragen werden, bleiben
sie im Änderungsprotokoll erhalten und "belasten" die Verwaltung
der Replikation.
Mehrere TableOrder sind sinnvoll, um z.B. eine kleine Abfolge mit dringenden Daten zu definieren, die mehrmals am Tag abgeglichen wird und eine vollständige Liste, die einmal in der Nacht abgeglichen wird.
| ID | Nummer des Events |
| Name | Bezeichnung der Event beschreibt |
| Folge Event | nach Durchführung des aktuellen Events kann eine weitere Replikation gestartet werden ( vgl. auch Sternreplikation ) |
| Startserver | Server dessen Demon die Replikation ausführt. Werden mehrere gewählt, starten mehrere parallele Replikationen |
| Replikationsserver | Server die neben dem ausführenden Server an der Replikation beteiligt sind |
| OrderID | TableOrder, also die Reihenfolge der auszuführenden Replikationen |
| Priorität | wird während einer laufenden Replikation ein Event mit höherer Priorität angestoßen, wird der laufende unterbrochen ( Rollback! ). |
| User, Password | User mit Password unter dem die Replikation ausgeführt wird |
| Rollback | ob bei Fehlern ein Rollback gemacht wird. Mit "nein" wird das Transaktionsmanagement im wesentlichen ausgebremst, sollte daher nur in gut begründeten Ausnahmefällen verwendet werden. |
Mit InterBase Generatoren erzeugen Sie normalerweise Schlüsselwerte, o.ä. in Ihrer Datenbank. Problematisch bei einer Replikation ist, das die Verwaltung der Nummern nur lokal erfolgt. Dabei geht dann eine wesentliche Eigenschaft von Generatoren verloren. InterBase Generatoren können dann nicht mehr garantieren, das ein Wert eindeutig ist.
Mit globalen Generatoren lässt sich das Problem lösen. Globale Generatoren sind Nummernbereiche, die vom InterBase Replication Demon verwaltet und den einzelnen Server automatisch zugeordnet werden. Damit lässt sich die Eindeutigkeit von Nummern über mehrere Server hinweg garantieren.
Definieren Sie im obigen Dialog mindestens einen Generator Event (Generator Gruppe). Dieser legt für eine Gruppe von Generatoren fest, von welchem Server sie verwaltet werden, (vgl. auch erweiterte Konfigurationsmöglichkeiten).
Ein Generator wird dann über seinen Namen definiert, einem Event zugeordnet und dann mit Hilfe seiner zwei Parameter spezifiziert:
Zur Initialisierung der Generatoren sollten auf allen beteiligten Servern nach Einrichtung der Replikation der entsprechende Generatorevent manuell ausgelöst werden. Das darf nicht vor der Verteilung der DB auf die einzelnen Server geschehen, weil sonst alle Datenbanken mit dem gleichen Nummernbereich arbeiten müssen.
Mit Hilfe des integrierten Schedulers können Replikationen zu festgelegten Zeiten gestartet werden. Legen Sie für jeden Start einen Eintrag an und definieren Sie die einzelnen Werte:
| ID | Nummer des Eintrags |
| Server | Server an dem der Event ausgelöst wird |
| Wochentag | Wochentag an dem der Event ausgelöst wird |
| Uhrzeit | Uhrzeit zu welcher der Event ausgelöst wird |
| Event Art | Replikation starten oder Generatoren Nummernbereiche prüfen |
| Event | Auswahl des Events |
Andere Möglichkeiten eine Replikation zu starten sind:
Mit dem Mailer können automatisch eMails nach Abschluss einer Replikation versandt werden. Für jede eMail ist zu spezifizieren:
| ID | laufende Nummer |
| Adresse | eMail - Adresse, an die die Mail versandt wird |
| Code | sendet nur bei Rollback endet nur bei Satzübertragungsfehler oder Rollback, also wenn ein Problem auftrat sendet immer eine eMail, also auch wenn alles glatt durchlief |
| Style | Die Mail kann in einer Zusammenfassung (short) oder in einer langen Fassung mit Angaben zu jeder Tabelle gesendet werden |
| Subject | Subject der eMail |
In der Konfigurationsdatei des InterBase Replication Demon sind, damit der Mailer funktionieren kann, noch die folgenden Einstellungen notwendig:
[Mail] Host=mail.myserver.de ; die Adresse eines erreichbaren smtp-Server FromName=MyName ; Name im Names dessen die Mail versandt wird HdrFrom ; eMail Adresse des Absenders ReplyTo ; eMail Adresse an die eine Antwort gesendet werden kann
Wenn Sie das System zum ersten Mal konfigurieren, müssen Sie die Basislizenz eintragen. Zudem ist die Version der neuen Konfiguration einzutragen.
Der InterBase Replication Demon startet automatisch den Abgleich der Konfigurationen, wenn beim Start einer Replikation unterschiedliche Versionen vorgefunden werden. Dabei wird dann die Konfiguration der Konfigurationsdatenbank des Servers geladen.
Wichtig: Achten Sie bei der Verwendung mehrerer Konfigurationsvorlagen darauf, dass alle Vorlagen die gleiche Versionsnummer erhalten. Ansonsten vermutet der InterBase Replication Demon Inkonsistenten in der Konfiguration und versucht diese durch Aktualisierung zu entfernen. Im Feld Beschreibung können Anmerkungen zur Historie fort geschrieben werden.
Damit der InterBase Replication Demon überhaupt gestartet werden kann, muss in der Konfigurationsdatei rpdemon.ini u.a die Datenbank mit der die Verbindung aufgebaut werden soll, eingetragen werden. In der Datenbank werden dann die weiteren Konfigurationsparameter gefunden.
[Demon] Database=freetown:c:\work\kbase1.gdb ;Pfad zu Datenbank mit Serverangabe SysUser=SYSDBA ; Benutzername zur Anmeldung SysPassword=masterkey ; Passwort zur Anmeldung CharSet=ISO8859_1 ; zu verwendendes Character Set
Das Passwort müssen Sie mit Ausnahme von masterkey über den InterBase Replication Guardian eintragen, da es verschlüsselt hinterlegt wird.
Bei einem Vollabgleich werden alle Daten aller Server zu allen anderen Servern übertragen. Zu dem ist das Netzwerk auch so konfiguriert, dass sich die Server jederzeit erreichen.
Einziger Zweck der Replikation ist in diesem Fall Redundanz herzustellen. D.h., das System bleibt funktionsfähig, wenn Verbindungen ausfallen. Dazu definieren Sie das System mit seinen Standardeinstellungen. Es werden alle Änderungen der Daten an alle Server übertragen. Es gibt nur einen Replikationsevent, dieser definiert den Startserver, der die Replikation ausführt. Zu allen Servern wird dann eine Verbindung aufgebaut.
Bei einer Sternreplikation werden Filialserver Datenbankserver mit einem Zentralserver verbunden, z.B. beim Einsatz von Außendienstnotebooks und einem zentralen Netzwerk des Innendienst.
Bei einer Replikation nun alle Server miteinander zu verbinden, ist unpraktikabel. Da ja ggf. nicht alle Mitarbeiter zu diesem Zeitpunkt an das Netz angeschlossen sind, oder in einem WAN nicht genügend Telefonleitungen zur Verfügung stehen.
Daher replizieren alle Filialserver nur direkt mit dem Zentralserver, der die Änderungen dann weiterreicht. Folgende Einstellungen sind dafür notwendig.
Alle Daten werden vom Zentralserver an alle Filialserver weitergereicht, wie beim Vollabgleich.
In einem Filialserver erfolgt die direkte Weitergabe nur zum Zentralserver (im Bild Zielserver 1:freetown). Von da aus erfolgt die Weitergabe der Daten an die anderen Filialserver (hier 3:canberra).
Diese Art der Vorgehensweise ist notwendig, weil die Verwaltung, welcher Server welche Sätze erhalten hat, bzw. noch erhalten muss, nur im Zentralserver aufgebaut wird.
Finden Abgleiche asynchron statt, also z.B. immer dann, wenn ein Außendienstmitarbeiter dies für notwendig hält sein Notebook abzugleichen, wird die Replikationstätigkeit vom Filialserver aus getätigt. Dafür muss je Filialserver ein Event definiert werden. Dabei hat der Event am besten die gleiche Nummer, wie der entsprechende Filialserver. Dies ist natürlich nicht zwingend, fördert aber die Übersichtlichkeit.
Als Startserver wird dann der Filialserver festgelegt. Beteiligter Replikationsserver ist nur der Zentralserver, der Startserver ist automatisch dabei.
Soll ein vollständiger Abgleich zwischen allen Filialservern und der zentralen Datenbank durchgeführt werden, definiert man am besten eine Ziehharmonika. Dabei erfolgt ein Abgleich zwischen Server 2 und 1, dann 3 und 1, dann 4 und 1, dann wieder 3 und 1 und abschließend wieder 2 und 1. Damit kann sichergestellt werden, dass auch Änderungen vom Server 4 zum Server 2 gelangen.
Um dies zu realisieren müssen Sie 5 Events anlegen (z.B. 12, 13, 14, 23, 22), wobei nach Abschluss eines Events automatisch der nächste Event über das Feld Folgeevent angestoßen werden kann.
Werden die Events jeweils von dem Filialserver ausgeführt, wird Filialserver 2 nach Abschluss von Event 12 versuchen dem Filialserver 2 mitzuteilen, dass der Event 13 starten soll. Dazu bedarf es einer TCP/IP Verbindung von Server 2 zu 3. D.h., die Server müssen voneinander wissen (Hostfile oder DNS-Nameserver) und das Routing muss entsprechend konfiguriert werden. Sprechen Sie ggf. mit Ihrem Netzwerkadministrator.
Bei der Verwaltung der Generatoren hat man drei verschiedene Möglichkeiten, wobei sicherlich Variante a die am häufigsten verwendete ist.
Der InterBase Replication Demon kann über TCP/IP Ihre Anwendung informieren, dass er aktiv ist, bzw. dass er einen Replikationslauf mit Commit oder Rollback abgeschlossen hat.
Dazu sendet der InterBase Replication Demon über den im Guardian hinterlegten Port ein Datagramm an alle Server, die an der Replication beteiligt sind. Ist als Port -1 hinterlegt, ist dieser Mechanismus nicht aktiv.
Wenn Sie zum Beispiel vier Server im Netz haben und auf Server 2 wird eine Replikation zwischen den Servern 1, 2 und 4 gestartet, dann sendet der Demon beim Start der Replikation das Datagramm
2;nfStart;
an die Server 1, 2 und 4..
Das Datagramm besteht aus klar lesbaren ASCII-Zeichen. Die Benachrichtigungstexte im einzelnen sind die Folgenden, dabei ist das Feld Data derzeit immer leer:
<SrvId>;nfStart;<data> <SrvId>;nfCommit;<data> <SrvId>;nfRollback;<data> <SrvId>;nfConflict;<data>
Die nfConflict Meldung geht nur an die Server, deren Änderungen sich nicht durchsetzen könnten und bei denen somit Einträge in der Tabelle rp$Conflict entstanden sind.
In dem Sie einen TCP/IP SocketServer an dem hinterlegten Port in Ihrer Anwendung implementieren, können Sie diese Daten empfangen.
Neben der Benachrichtigung via TCP/IP ruft der InterBase Replication Demon auf allen, bei einer Replikation beteiligten Datenbanken zu Beginn und nach Abschluss einer Replikation, SQL-Proceduren auf.
RP$TRIGGERSTARTREPLIC RP$TRIGGERENDREPLIC
In dem Sie in diesen Proceduren einen InterBase Event auslösen, oder Arbeiten an Ihren Daten vornehmen, können Sie Ihre Anwendung auf die Replikation reagieren lassen.
Für die Funktionalität des InterBase Replication Demon sind die Proceduren nicht notwendig, sie können fehlen oder leer sein.
Da die Möglichkeit besteht, sowohl die Protokolltrigger, als auch die zu übertragenden Felder für jeden Server und jede Tabelle getrennt zu gestalten, besteht auch die prinzipielle Möglichkeit den InterBase Replication Demon zur Verteilung/Weitergabe von Daten in einer verteilten Datenbank zu nutzen.
Bei verteilten Datenbanken hängen die Details der Lösung noch stärker von Ihren individuellen Anforderungen ab, als bei einer Replikation. Wir verzichten daher hier auf weitere Details und bitten Sie, uns direkt anzusprechen.
Der InterBase Replication Demon kann natürlich auch für InterBase 6.0 genutzt werden. Dabei ist zu beachten, dass User Defined Function DLL?s nicht mehr in ..\InterBase\bin oder \Windows\System zu abzulegen sind, sondern in ..\Interbase\Udf.
Weitere "Schwierigkeiten" haben sich bei unseren Tests nicht ergeben.
Bei der Replication kann es trotz der festgelegten Reihenfolge der Tabellenabarbeitung (TableOrder) zu Problemen mit der referentiellen Integrität kommen. Eine Möglichkeit dies zu umgehen besteht darin, auftretende Übertragungsfehler bei einem ersten Durchlauf zu ignorieren und in einem zweiten Durchlauf dann zu schreiben, wenn die Voraussetzungen der referentiellen Integrität erfüllt sind.
Die Anzahl der Umläufe wird derzeit lokal am InterBase Replication Demon in der Konfigurationsdatei (rpdemon.ini) eingestellt.
[Sonstiges] LoopCountMax=2
Der Wert muss 1 sein, wenn nur ein Durchlauf stattfinden soll. Er gibt also die Anzahl der Durchläufe und nicht die Anzahl der Wiederholungen an.
Wenn bei der Übertragung der Daten im letzten Wiederholungslauf noch Fehler auftreten, wird die Replication abgebrochen und ein RollBack ausgelöst. Dadurch werden alle übertragenden Änderungen rückgängig gemacht, aber die referentielle Integrität und das Transaktionsmanagement werden gewahrt.
Um diesen Mechanismus zu deaktivieren, und die fehlerfreien Sätze zu erhalten, muss in der Konfigurationsdatei (rpdemon.ini) der Parameter
[Sonstiges] ContinueWithError=Y
gesetzt werden. Wir empfehlen diese Variante nicht einzusetzen!
Sollte dieses rudimentäre Konfliktmanagement für Ihre Anwendung nicht ausreichen, wenden Sie sich bitte an uns, mit individuellen Erweiterungen ist viel machbar, doch ist es wenig sinnvoll in einer allgemeinen Lösung eine andere Form des Konfliktmanagements zu implementieren.
Im folgenden werden die Tabellen des Interbase Replication Demon beschrieben. Statt des Konfigurationswerkzeugs, können Sie auch direkt auf diese Tabellen zugreifen, um mit SQL die Anwendung zu konfigurieren.
Das ist insbesondere bei einer großen Anzahl zu replizierender Tabellen sinnvoll. Wir empfehlen folgende Vorgehensweise:
Jeder Satz beschreibt einen an der Replikation beteiligten Server
| RP$SRVID | smallint not null | Id des Servers |
| RP$HOST | RP$TSTRING | TCP/IP Name via DNS oder Host-Datei |
| RP$DATABASE | RP$TSTRING not null | Pfad zur Datenbank (am besten alles klein schreiben, wg. eines InterBase Bugs) |
| RP$LIZENZ | RP$TSTRING not null | InterBase Replication Lizenz für den Server |
| RP$ONLINE | RP$TBOOL DEFAULT "Y" | Nach der Verbindung OnLine bleiben (normalerweise N) |
| RP$PARALLEL | RP$TBOOL DEFAULT "Y" | Dürfen gleichzeitig 2 Demon auf einer DB replizieren |
| RP$ACCEPTVIA | RP$TSTRING | Liste von Servern, über die Daten kommen dürfen, vgl. verteilte Datenbanken |
| RP$LOCAL | RP$TBOOL DEFAULT "N" | (ohne Bedeutung) |
| RP$CFGDATABASE | RP$TSTRING | Pfad mit Hostnamen zur Konfigurationsdatenbank, von der bei Bedarf eine neue Konfiguration gezogen wird |
| RP$DIALUP | RP$TSTRING | Name des DFÜ-Netzwerks, über das eine Verbindung hergestellt werden soll. Leer=Verwende LAN |
Beschreibt die zu replizierenden Datenbanktabellen Ihrer Anwendung
| RP$TBLID | smallint not null | Id der Tabelle |
| RP$TABLENAME | RP$TNAME not null | Name der Datenbanktabelle |
| RP$INDEXNAME | RP$TNAME | Wenn kein echter Primary Key verwendet wird, Name des uniquen Index, mit den Feldern die den Satz identifizieren |
| RP$TABLEKEYS | varchar(255) | Aufzählung der Felder des verwendeten Primärschlüssels Format; "<key1>";<key2>" |
| RP$COMMITAFTER | integer | Ob nach n setzen ein Commit gemacht werden soll, besser 0, sonst Transaktionsmanagement nicht sauber |
| RP$MODE | char(1) | Art auf, die die Daten der Tabelle übertragen werden: U - select for update A - update table set alle Felder C - update table set geänderte Felder |
Definiert die Reihenfolge in der die Tabellenoperationen repliziert werden
| RP$ORDID | integer not null | Id der TableOrder |
| RP$TBLID | smallint not null | Verweis auf die Tabelle |
| RP$OPORDER | integer not null | Reihenfolge 1, 2, 3,... |
| RP$OPERATION | RP$TOPERATION not null | Operation I, U, D |
Definiert, welche Daten einer Tabelle gesendet bzw. empfangen werden
| RP$SRVID | smallint not null | SrvId für den der Eintrag gilt |
| RP$TBLID | smallint not null | Verweis auf die Tabelle |
| RP$SEND | RP$TSTRING | Liste der ein- oder auszuschließenden Felder (* alle) beim senden |
| RP$RECEIVE | RP$TSTRING | Liste analog zu rp$send für das Empfangen |
| RP$INCLUSIVE | RP$TBOOL DEFAULT "Y" not null | Y: Die Felder rp$send und rp$receive beschreiben die zu verarbeitenden
Felder N: Die Felder rp$send und rp$receive beschreiben die nicht zu verarbeitenden Felder |
Definiert, welche Daten von welchem Server zu welchem Server gesendet werden
| RP$SRVID | smallint not null | Server für den der Eintrag gilt |
| RP$TBLID | smallint not null | Verweis auf die Tabelle |
| RP$TARGETID | integer not null | 0 alle Server, sonst je Zielserver einen Eintrag in rp$Target |
| RP$PACKAGE | RP$TSTRING | an welche Server sollen die Daten weiterversandt werden Format x, y, z |
Definiert den Start eines Replikationslaufes, auslösbar über rp$StartReplic, die Benutzeroberfläche oder ein TCP/IP Datagramm
| RP$EVENTID | smallint not null | ID des Events |
| RP$EVENTNAME | RP$TNAME | Bezeichnung zur Beschreibung |
| RP$STARTSERVERS | RP$TSTRING | Server, auf denen der Demon die Replikation ausführt. Normalerweise n. Möglich aber auch 2, 3, startet gleichzeitig eine Replikation an Server 2 und 3 |
| RP$PRIORITY | smallint | Höher Priorisierte Events brechen gerade laufende Events ab |
| RP$ORDID | integer not null | Id der auszuführenden TableOrder |
| RP$REPLSERVERS | RP$TSTRING | neben dem ausführenden Server, noch an der Replikation beteiligte Server |
| RP$USER | RP$TNAME | zu verwendenden User |
| RP$PASSWORD | RP$TNAME | zu verwendendes Passwort |
| RP$ROLLBACK | RP$TBOOL default "Y" | Rollback bei Fehlern |
| RP$NEXTEVENT | smallint | ID des Folgeevents rrp$replevents, der nach dem Event ausgeführt wird |
| RP$SCKEY | integer not null | Id des Eintrags |
| RP$SRVID | smallint | Server auf dem der Event ausgelöst wird |
| RP$DAY | smallint | Wochentag 1: Sonntag, 2: Montag, 3... |
| RP$TIME | date | Uhrzeit |
| RP$EVENTSTYLE | char(1) | (R)eplikations oder (G)eneratorevent |
| RP$EVENTID | smallint | Nummer des Events |
| RP$MAILID | smallint not null | Id des Eintrags |
| RP$EMAIL | varchar(64) not null | eMail Adresse, an die die Mail versandt wird |
| RP$MCODE | smallint | ab welchem Fehlerlevel versandt wird, 21 nach jeder Replikation 11 nur bei Fehlern 1 nur bei Rollbacks |
| RP$MSTYLE | char(1) | S Short L Lang |
| RP$EVENTID | smallint not null | Id des Events |
| RP$SERVERS | RP$TSTRING | Id?s der Server, die die zugeordneten Generatoren verwalten. Format: n <keiner> x, y |
Definiert einen Generator, also einen Mechanismus zur Erzeugung von Nummernbereichen, damit eindeutige Nummern im Gesamtsystem möglich werden.
| RP$GENNAME | RP$TNAME not null | Name des Generators |
| RP$THRESHOLD | integer | Schwellwert, d.h. Anzahl an Restnummern ab den ein neuer Nummernbereich angefordert wird |
| RP$BLOCKSIZE | integer | Größe eines Nummernbereichs |
| RP$ACTVALUE | integer | intern: nächster zu vergebener Wert |
| RP$ACTLASTVALUE | integer | intern letzter zu vergebener Wert des aktuellen Nummernbereichs |
| RP$NXTFIRSTVALUE | integer | intern: nächster erster Wert eines bereits neu angeforderten Nummernbereichs |
| RP$NXTGLOBALVALUE | integer | größer bekannter vergebener Wert |
| RP$EVENTID | smallint | zugeordneter Generatorevent für die Aktualisierung |
Hier werden die Sätze vermerkt, deren Änderungen nicht übertragen werden konnten.
| RP$SRVID | smallint | Id des Masterservers, von dem der Satz kam |
| RP$TBLID | smallint | Id der betroffenen Tabelle |
| RP$DATE | date | Datum der Änderung |
| RP$OPERATION | RP$TOPERATION | Operationen, die nicht ausgeführt werden können (I,U,D) |
| RP$PRIMKEY | RP$TSTRING | Primary Key der betroffen ist, im Format aus rp$Change |
| RP$DESTSRV | smallint | Server Id, zu dem die Änderung hätte übertragen werden sollen |
Diese Tabelle protokolliert summarisch den Ablauf einer Replikation, kann als Basis für Optimierungen verwendet werden.
| RP$STATKEY | integer not null | Id des Satzes |
| RP$DEMONID | smallint | Id des Servers der repliziert hat |
| RP$REPLID | integer | laufende Nummer der Replikation |
| RP$LOOP | integer | Nummer des Durchlaufs |
| RP$START | date | Datum, Uhrzeit, zu der die Replikation einer Tabelle begann |
| RP$ENDE | date | Datum und Uhrzeit des Endes |
| RP$TBLID | integer | Table ID, deren Werte hier aufgeführt sind, -1 steht für einen Replikationslauf |
| RP$COUNT | integer | Anzahl übertragene Sätze |
| RP$ERROR | integer | davon fehlerhafte Übertragungen |
Diese Tabelle enthält Details zu den Sätzen deren Änderungen nicht eingetragen werden konnte, weil der Zielserver den Eintrag auf Grund referentieller Integrität oder Constraints abgelehnt hat.
| RP$ERRKEY | integer not null | Id des Eintrags |
| RP$DEMONID | smallint | Id des Servers der repliziert hat |
| RP$REPLID | integer | laufende Nummer der Replikation |
| RP$LOOP | integer | Nummer des Durchlaufs, |
| RP$ZEIT | date | Änderungsdatum |
| RP$TBLID | integer | Tabelle, die betroffen ist |
| RP$PRIMKEY | RP$TSTRING | Primary Key der betroffen ist im Format von rp$change |
| RP$SOURCESRV | smallint | Masterserver von dem die Änderung kam |
| RP$TARGETSRV | smallint | Zielserver, wo die Änderung hin sollte |
| RP$MSG | RP$TLONGSTRING | Fehlermeldung, Meldung des Datenbankservers |
| RP$STYLE | char(1) | (W)arnung oder (E)rror |
Das Änderungsprotokoll
| RP$SRVID | smallint not null, | Server, auf dem der Satz geändert wurde |
| RP$RECID | integer not null, | laufende Nummer der Änderung |
| RP$USER | RP$TNAME, | Benutzer, der geändert hat |
| RP$TBLID | smallint not null, | Tabelle, wo geändert wurde |
| RP$OPERATION | RP$TOPERATION, | I, U, D |
| RP$PRIMKEY | RP$TSTRING not null, | Primary key korrespondieren zur PrimaryKey Beschreibung der Tabelle; "<value1>"<value2>" |
| RP$DATE | date, | Zeitpunkt der Änderung |
| RP$SEND | RP$TSTRING, | intern: welche Felder zu versenden sind |
| RP$INITIALIZED | RP$TCHANGESTATUS DEFAULT "N" | intern: Initialisierungsstatus des Satzes |
Intern: Verwaltet, welcher Server schon welche Änderungen erhalten hat und entsprechende Quittungen. Dient der Überwachung, ob die Einträge in rp$Change gelöscht werden dürfen.
| RP$SRVID | smallint not null, |
| RP$RECID | integer not null, |
| RP$TARGETID | smallint not null, |
| RP$PACKAGE | RP$TSTRING, |
| RP$TRANSFERD | RP$TBOOL DEFAULT "N", |
| RP$DELIVERED | RP$TCONTROL); |
verwaltet interne Informationen, u.a. die Basislizenz
| RP$ID | char(1) not null, |
| RP$DATE | date, |
| RP$IVALUE | smallint, |
| RP$SVALUE | varchar(128), |
| RP$REMARK | varchar(255)); |
Der InterBase Replication Demon kann direkt über das Startmenu gestartet werden. Dieses sollte insbesondere zur Zeit der Einrichtung so geschehen: Wenn das System dann im produktiven Einsatz ist, ist es besser, den Start des Demons, dem InterBase Replication Guardian zu überlassen.
Vor dem Protokollieren einer Änderung in Ihren Daten, wird mit Hilfe des InterBase Replication Demon die ID des Servers auf dem die Änderung passiert, festgestellt. Daher ist es nicht möglich, Änderungen in Ihrer Anwendung vorzunehmen, ohne das der InterBase Replication Demon aktiv ist.
Bei jedem Start des InterBase Replication Demon wird ein neues LogFile angelegt.
Mit der Nummerierung der LogFiles können Sie festlegen, bei welcher Nummer es weitergeht und wie viel Files maximal aufgehoben werden.
Mit den Log/Trace aktivieren und bestimmen Sie den Umfang der Ausgaben auf dem Bildschirm und in die Logdate. Verwenden Sie den SQL-Monitor nur, wenn Sie Fehler in Ihrer Konfiguration suchen.
Mit der unteren Auswahl können Sie detailliert festlegen, welche Art von Aktivität vom SQL-Monitor aufgezeichnet werden. Beim Einsatz des SQL Monitors entstehen umfangreiche Protokolle, diese sind nur zur Fehlersuche gedacht.
Wenn der InterBase Replication Demon in der Taskbar zu sehen ist, erreichen Sie die wesentlichen Auswahlpunkte des Menus auch über die rechte Maustaste. Zudem haben Sie die Möglichkeit, über den Menupunkt Show, das Hauptfenster des InterBase Replication Demon anzuzeigen.
Primäre Aufgabe des InterBase Replication Demon, zu überwachen ob der InterBase Replication Demon aktiv ist und diesen ggf. zu starten. Zu dem können einige Einstellungen der Konfigurationsdatei über einen Dialog des InterBase Replication Guardian vorgenommen werden.
Nach der Eingabe des Passwords für den Zugriff des Interbase Replication Demon (default mastekey), erreichen Sie das Properties (Eigenschaften) Menus.
Im oberen Teil können Sie die lokale Datenbank und den zu verwendenden Benutzer und das Passwort angeben.
Links unten werden die TCP/IP Ports definiert, die zur Kommunikation der Programme des InterBase Replication Demon untereinander eingesetzt werden. Dabei ist es notwendig, das diese Ports durch alle vorhandenen Firewalls, etc. transparent durchgehen. Der UserPort ist standardmäßig deaktiviert (vgl TCP/IP Datagramme).
In den Einstellungen des Guardian definieren Sie:
Mit diesem kleinen Tool können Sie Daten unter der Anwendung von Bedingungen aus einer Datenbank in eine andere kopieren. Geben Sie eine Quell- und eine Zieldatenbank an, sowie eine Ini-Datei zum Steuern des Prozesses.
Schritt 1, es wird eine Strukturdatensicherung
der Quelldatenbank gemacht, ohne Daten.
Schritt 2, diese Struktur wird als
neue Datenbank wiederhergestellt.
Schritt 3, gemäß der Ini-Datei
werden die Daten in die neue Datenbank übertragen.
Schritt 4, von der Zieldatenbank wird eine
Datensicherung gemacht.
Die Konfigurationsdatei hat den folgenden Aufbau:
[TABLE] KBProd=Product KBCat= KBase=Product
Dabei werden Daten jeder angegebenen Tabelle übertragen und die hinter dem Gleichheitszeichen angegebene where-Bedingung verwendet.
Wenn der InterBase Replication Demon in der Taskbar zu sehen ist, erreichen Sie die wesentlichen Auswahlpunkte des Menus auch über die rechte Maustaste. Zu dem haben Sie die Möglichkeit, über den Menupunkt Show das Hauptfenster des InterBase Replication Demon anzuzeigen.
Das InterBase Replication Terminal gibt den Zustand der InterBase Replication Demons in einem Netzwerk wieder. Dabei kann dies auf einem Computer installiert sein, der mit der Replikation sonst nichts zu tun hat. Einzige Voraussetzung ist, das vom Terminal eine TCP/IP Verbindung zu den InterBase Replication Guardians der Replikation besteht.
In der Konfigurationsdatei rpDemon.ini werden die Namen der Server eingetragen, die überwacht werden sollen. Im Rahmen des Netzwerkes muss eine Namensauflösung via DNS oder Hostdatei möglich sein.
[Servers] dublin= freetown=
Der InterBase Replication Service prüft alle 2 Minuten, ob der InterBase Replication Guardian noch aktiv ist und startet ihn, wenn dies nicht der Fall ist. Damit garantiert er auch ohne angemeldeten Benutzer unter Windows NT und Windows 2000, den Betrieb des InterBase Replication Demon.
Sie installieren den Service mit:
rpservice -install
und deinstallieren ihn wieder mit:
rpservice -uninstall
Die Verwaltung geschieht über die Verwaltung der Dienste von Windows NT bzw. Windows 2000.
Sollte nach dem Start des InterBase Replication Guardian, oder des InterBase Replication Demon über den InterBase Replication Service in Ihrem Windows nach der Anmeldung eines Benutzers die Programme nicht in der Taskbar zu sehen sein, können Sie die Icons der Programme durch den Aufruf von rpShow sichtbar machen.
Die Downloadbare Demonversion enthält die volle Funktionalität des InterBase Replication Demon, ist aber auf 60 Tage nach der Installation beschränkt. Eine weitere Nutzung entspricht nicht den Lizenzbestimmungen und kann entsprechend geahndet werden.
In der Demonstrationsversion sind Datensicherungen enthalten, um drei typische Fälle einer Replikation zu demonstrieren. Sie benötigen dafür zwei bis drei via TCP/IP verbundene Computer und auf jedem Rechner einen InterBase Server, sowie eine Installation des InterBase Replication Demon.
Es wird im folgenden davon ausgegangen, dass:
athen:c:\MeineDaten\MeineDatenbank.gdb
Dadurch verwendet InterBase TCP/IP.
Host 1: athen Datenbank 1: c:\work\kbase.gdb Konfigurationsdatenbank 1: Host 2: bern Datenbank 2: c:\work\kbase.gdb Konfigurationsdatenbank 2: athen:c:\work\kbase.gdb
[Demon] Database=athen:c:\work\kbase1.gdb
den Pfad zum lokalen Datennamen eintragen, auf "Bern" natürlich entsprechend:
bern:c:\?
können Sie den InterBase Replication Demon starten. Starten Sie den InterBase Replication Demon zu Beginn durch Aufruf von rpDemon.exe, verwenden Sie den Interbase Replication Guardian erst, wenn der Start des Demon funktioniert hat. Folgendes Bild muss sich dann ergeben:
Der Server gibt unter anderem die DEMONID an, diese muss bei "Athen" eins und bei "Bern" zwei sein.
Die jetzt bereits installierte Konfiguration ist eine Vollreplikation/Vollabgleich. D.h., jede Änderung wird auf den anderen Server übertragen. Mit dem Programm rpCllient.exe können Sie Datensätze in den Datenbanken verändern und die Replikation starten. Die Daten werden dann auf die andere Datenbank übertragen.
Auf Grund des Transaktionsmanagements werden Änderungen in rpClient erst dann sichtbar, wenn Sie nach einer Replikation die Daten erneut von der Datenbank anfordern, also den Refresh Button verwenden, der ein Close/Open, aller im Client vorhandenen Abfragen auslöst.
Machen Sie sich mit den Einstellungen der Replikation an Hand des Konfigurationswerkzeuges vertraut.
Als Vorbereitung der Sternreplikation sichern Sie die Daten den kbase_stern.gbk auf "Athen" zurück, über die Datei kbase.gdb.
Die in dieser Datenbank eingetragene Version der Konfiguration ist größer, als die bisherige von kbase_base.gbk, die noch als kbase.gdb auf dem Server "Bern" liegt.
Gehen Sie mit dem Konfigurationswerkzeug erneut auf die Datenbank kbase.gdb auf "Athen" und passen Sie die Pfade der Server erneut an. Es ist jetzt auch ein dritter Server "Canberra" vorhanden, da für eine echte Sternreplikation mindestens drei Server notwendig sind. Die Anpassung der Pfade ist leider erneut notwendig, da wir die bei Ihnen im Test real auftretende Servernamen nicht kennen konnten.
Wenn Sie nun eine Replikation starten, erkennt der InterBase Replication Demon, dass die Version der Konfiguration auf "Bern" zu klein ist und schließt "Bern" von der Replikation aus. "Bern" lädt dann automatisch die Konfiguration aus der, bei ihm hinterlegten Konfigurationsdatenbank, also in diesem Falle, aus der Datenbank auf "Athen". "Athen" bricht jetzt auch die Replikation ab, da mit sich selbst keine Replikation möglich ist.
Wenn Sie die Replikation nach dem Nachladen der Konfiguration erneut starten, haben beide Seiten wieder die gleiche Version der Konfiguration und werden daher mit den neuen Einstellungen replizieren.
Bei einer Sternreplikation fungiert ein Server (hier "Athen") als Zentralserver, an dem alle anderen Server sternförmig angeschlossen sind. Trotzdem kann ein Vollabgleich der Daten erfolgen, aber die Server "Bern" und "Canberra" sind nicht direkt miteinander verbunden, sondern versenden ihre Daten über den Zentralserver "Athen".
Um dies gut beobachten zu können, benötigen wir den dritten PC "Canberra", auf dem auch InterBase und der Interbase Relication Demon installiert sein muss. Auf "Canberra" verwenden wir dann für die Demonstration die gleiche Datenbank kbase.gdb, wie auf "Athen" und "Bern".
Starten Sie auf dem Server "Athen" den Replikationsevent 1, es erfolgt dann ein normaler Vollabgleich zwischen den Servern "Athen", "Bern" und "Canberra", analog zu 9.2.
Wenn Sie den Event 12 auf dem Server "Athen" starten, wird dieser Server "Bern" benachrichtigt, um zwischen "Bern" und "Athen" zu replizieren. Danach erfolgt ein Abgleich zwischen "Canberra" und "Athen" mit Hilfe eines Folgeevents und schließt erneut einen Abgleich zwischen "Bern" und "Athen" ab, damit auch die Änderungen von "Canberra" zum Server "Bern" gelangen können.
Bei dieser Form der Replikation müssen alle Filialserver erreichbar sein, sonst bricht die Kette ab. Auch muss für die Kommunikation zwischen den Servern eine TCP/IP Verbindung von "Bern" zu "Canberra" zum Auslösen des Folgeevents möglich sein.
Natürlich kann diese Form der Replikation auch asynchron stattfinden. D.h., "Bern" gleicht mit "Athen" Daten ab und bekommt dabei die Daten die "Athen" kennt, ohne dabei Rücksicht auf "Canberra" zu nehmen. Der Server "Canberra" wiederum gleicht seine Daten dann zu einem beliebigen anderen Zeitpunkt ab. Dafür sind die Replikationsevents 2 und 3 hinterlegt, die jeweils einen Abgleich zwischen den Servern "Bern" und "Athen" sowie "Canberra" und "Athen" starten.
Die globalen Generatoren sind in beiden Demonstrationskonfigurationen so konfiguriert, dass beim Einfügen des dritten Satzes über den globalen Generator ein neuer Nummernbereich angefordert wird. Durch Ändern der Größe des Nummernbereiches und des Schwellwertes (derzeit 2) können Sie das Verhalten des Generators anpassen.
In der Konfiguration der zu replizierenden Tabellen, können Sie die zu versendenden Felder verändern und andere Einstellungen der Replikation verändern und deren Auswirkung beobachten.
Da der InterBase Replication Demon in der Demonstrationsversion nur zeitlich und nicht funktionell begrenzt ist, können Sie natürlich auch mit Ihrer eigenen Anwendungsdatenbank experimentieren. Wir empfehlen dazu, zuvor eine Übersicht der zu replizierenden Tabellen und die dabei zu replizierenden Daten und Transferrichtungen aufzustellen. Je besser eine Replikation vorbereitet wird, desto leichter ist später die Realisierung.