Hinweise zu Ladeprogrammen in einer Multimastertopologie

Wenn Sie Ladeprogramme in einer Multimastertopologie verwenden, müssen Sie die möglichen Anforderungen in Bezug auf die Verwaltung von Kollisions- und Revisionsinformationen berücksichtigen. Das Datengrid verwaltet Revisionsinformationen zu den Elementen im Datengrid, so dass Kollisionen erkannt werden können, wenn andere primäre Shards in der Konfiguration Einträge in das Datengrid schreiben. Wenn Einträge von einem Ladeprogramm hinzugefügt werden, werden diese Revisionsinformationen nicht eingeschlossen, und der Eintrag verwendet eine neue Überarbeitung. Da die Überarbeitung des Eintrags eine neue Einfügung zu sein scheint, könnte eine Fehlkollision auftreten, wenn ein anderes primäres Shard diesen Zustand ebenfalls ändert oder dieselben Daten aus einem Ladeprogramm extrahiert.

Replikationsänderungen rufen die Methode get im Ladeprogramm mit einer Liste der Schlüssel auf, die noch nicht im Datengrid enthalten sind, aber während der Replikationstransaktion geändert werden. Wenn die Replikation stattfindet, sind diese Einträge Kollisionseinträge. Sind die Kollisionen arbitriert, und die Überarbeitung wird angewendet. Anschließend wird eine Stapelaktualisierung im Ladeprogramm aufgerufen, um die Änderungen auf die Datenbank anzuwenden. Alle Maps, die im Revisionsfenster geändert wurden, werden in derselben Transaktion aktualisiert.

Preload-Rätsel

Stellen Sie sich eine Topologie mit zwei Rechenzentren vor: Rechenzentrum A und Rechenzentrum B. Beide Rechenzentren haben unabhängige Datenbanken, aber nur Rechenzentrum A hat ein Datengrid, das aktiv ist. Wenn Sie eine Verbindung zwischen den Rechenzentren für eine Multimasterkonfiguration herstellen, beginnen die Datengrids in Rechenzentrum A, Daten mit Push an die neuen Datengrids im Rechenzentrum B zu übertragen, was bei jedem Eintrag zu einer Kollision führt. Ein weiteres großes Problem tritt bei allen Daten auf, die in der Datenbank in Rechenzentrum B enthalten sind, aber nicht in der Datenbank in Rechenzentrum A. Diese Zeilen werden nicht gefüllt und arbitriert, was zu Inkonsistenzen führt, die nicht aufgelöst werden.

Lösung des Preload-Rätsels

Da die Daten, die nur in der Datenbank enthalten sind, keine Überarbeitungen haben können, müssen Sie das Datengrid immer vollständig aus der lokalen Datenbank laden, bevor Sie die Multimasterverbindung herstellen. Anschließend können beide Datengrids die Daten überarbeiten und arbitrieren und schließlich einen konsistenten Status erreichen.

Teilcache-Rätsel

Mit einem Teilcache versucht die Anwendung zuerst, die Daten im Datengrid zu finden. Wenn die Daten nicht im Datengrid enthalten sind, werden die Daten mithilfe des Loaders in der Datenbank gesucht. Die Einträge im Datengrid werden in regelmäßigen Abständen bereinigt, um die Cachegröße klein zu halten.

Dieser Cachetyp kann in einem Szenario mit einer Multimasterkonfiguration problematisch sein, weil die Einträge im Datengrid Metadaten zur Überarbeitung enthalten, mit deren Hilfe Kollisionen und die Seite, auf der die Änderungen vorgenommen wurden, erkannt werden können. Wenn Verbindungen zwischen den Rechenzentren nicht funktionieren, kann ein Rechenzentrum einen Eintrag aktualisieren und schließlich die Datenbank aktualisieren und den Eintrag im Datengrid ungültig machen. Nach der Wiederherstellung der Verbindung versuchen die Rechenzentren, Überarbeitungen miteinander zu synchronisieren. Da die Datenbank jedoch aktualisiert und der Eintrag im Datengrid ungültig gemacht wurde, geht die Änderung aus der Perspektive des Rechenzentrums, das ausgefallen ist, verloren. Deshalb sind die beiden Seiten des Datengrids nicht mehr synchronisiert und nicht mehr konsistent.

Lösung des Teilcache-Rätsels

Hub- und Peripherietopologie:

Sie können den Loader nur im Hub einer Hub- und Peripherietopologie ausführen, in der die Konsistenz der Daten erhalten bleibt, während das Datengrid horizontal skaliert wird. Wenn Sie diese Implementierung in Erwägung ziehen, müssen Sie jedoch bedenken, dass die Loader ein partielles Laden des Datengrids zulassen können, d. h., dass ein Bereinigungsprogramm (Evictor) konfiguriert wurde. Wenn die Peripherie Ihrer Konfiguration aus Teilcaches besteht, die aber keinen Loader haben, besteht bei Cachefehlern keine Möglichkeit, die Daten aus der Datenbank abzurufen. Wegen dieser Einschränkung müssen Sie eine vollständig gefüllte Cachetopologie mit einer Hub- und Peripheriekonfiguration verwenden.

Invalidierungen und Bereinigung

Bei der Invalidierung entstehen Inkonsistenzen zwischen dem Datengrid und der Datenbank. Daten können über das Programm oder durch Bereinigung aus dem Datengrid entfernt werden. Wenn Sie Ihre Anwendung entwickeln, müssen Sie berücksichtigen, dass bei der Behandlung von Überarbeitungen keine Änderungen repliziert werden, die ungültig gemacht wurden, was zu Inkonsistenzen zwischen primären Shards führt.

Invalidierungsereignisse sind keine Cachestatusänderungen und führen nicht zur Replikation. Alle konfigurierten Bereinigungsprogramme werden unabhängig von anderen Bereinigungsprogrammen in der Konfiguration ausgeführt. Es kann beispielsweise ein Bereinigungsprogramm für einen Speicherschwellenwert in der einen Katalogservicedomäne konfiguriert sein, aber ein anderes, weniger aggressives Bereinigungsprogramm in der anderen verbundenen Katalogservicedomäne. Wenn Datengrideinträge aufgrund der Schwellenwertrichtlinie entfernt werden, sind die Einträge in der anderen Katalogservicedomäne nicht betroffen.

Datenbankaktualisierungen und Datengridinvalidierung

Es treten Probleme auf, wenn Sie in einer Multimasterkonfiguration die Datenbank direkt im Hintergrund aktualisieren, während die Invalidierung im Datengrid für die aktualisierten Einträge aufgerufen wird. Dieses Problem tritt auf, weil das Datengrid die Änderung erst dann auf den anderen primären Shards replizieren kann, wenn der Eintrag durch einen Cache in das Datengrid verschoben wird.

Mehrere Ausgabeprogramme für eine einzige logische Datenbank

Wenn Sie eine einzige Datenbank mit mehreren primären Shards verwenden, die über einen Loader verbunden sind, treten Transaktionskonflikte auf. Ihre Loaderimplementierung muss diese Typen von Szenarien in besonderer Weise behandeln.

Daten durch Multimasterreplikation spiegeln

Sie können unabhängige Datenbanken konfigurieren, die mit unabhängigen Katalogservicedomänen verbunden sind. In dieser Konfiguration kann der Loader Änderungen mit Push aus einem Rechenzentrum in das andere Rechenzentrum übertragen.