Partitionsreplikat- und Partitions-Cache-Topologien
Wenn in einem Cluster alle Serverknoten über dieselbe Datenkopie verfügen, erhalten Sie eine hohe Verfügbarkeit dieser Daten. Das bedeutet, dass der Cluster einige Knotenausfälle ohne Datenverlust überstehen kann. Dies bietet Ihnen jedoch keine Skalierbarkeit. Wenn die Daten enorm anwachsen, muss das Design den Umfang der Replikation reduzieren und mit der Partitionierung der Daten beginnen.
Partitionierung bedeutet, dass Sie Ihre Daten auf mehrere Knoten verteilen müssen, damit sowohl die Lese- als auch die Schreibdatenlast verteilt wird. Wenn Ihre Daten wachsen, können Sie dem Cluster weitere Serverknoten hinzufügen, um mehr Daten zu speichern. Jeder Serverknoten in einem Cluster wird als Partition bezeichnet.
Durch die Partitionierung der Daten können Sie Skalierbarkeit erreichen. Nun stellt sich jedoch die Frage: Wie werden die Daten partitioniert? Eine einfache Lösung könnte darin bestehen, Daten im Round-Robin-Verfahren einer Partition zuzuweisen, aber wie finden wir ein bestimmtes Datenelement, nachdem es dem Speicher hinzugefügt wurde?
Durch Round-Robin verlieren wir die Möglichkeit, den Speicherort von Daten zu verfolgen. Wir brauchen eine bessere Möglichkeit zur Datenverteilung, die nicht nur eine gleichmäßige Verteilung der Daten gewährleistet, sondern auch die Möglichkeit, sie schnell nachzuschlagen.
Note
Die partitionierte Topologie wird ebenfalls unterstützt NCache Professional.
Note
Der einzige Unterschied zwischen den Topologien „Partitioniert“ und „Partition-Replica“ besteht darin, dass erstere keine Replikat-Caches hat, was sie anfällig für Datenverluste macht.
Hash-basierte Datenpartitionierung für Partitions-Caches
NCache teilt Daten in mehrere Blöcke auf und platziert diese Blöcke in verschiedenen Partitionen. Diese Brocken werden Buckets genannt. Es gibt insgesamt 1000 Buckets, die gleichmäßig auf die Knoten im Cluster aufgeteilt sind. Die Idee hier besteht darin, eine Hash-Funktion auf den Schlüssel des Elements anzuwenden und ihn anhand der Anzahl der Gesamt-Buckets (in diesem Fall 1000) zu modifizieren, um einen Besitzer-Bucket für diese Daten zu erhalten.
Verbreitungskarte
Der Koordinatorserver im Cluster ist dafür verantwortlich, eine Karte zu generieren, die die Bucket-Verteilung enthält. Diese Karte wird Verbreitungskarte genannt. Der Koordinatorserver teilt diese Verteilungskarte mit den übrigen Partitionen im Cluster und mit den verbundenen Clients. Mit dieser Methode erhalten Sie immer die gleiche Bucket-Adresse für ein Element, unabhängig von der Anzahl der Server im Cluster. Auch wenn der Bucket jederzeit von einer Partition zur anderen verschoben werden kann, kann sich der Bucket eines Elements niemals ändern. Das heißt, wenn sich ein Eimer bewegt, nimmt er alle seine Daten mit.
Verteilung der Daten gemäß der Verteilungskarte
Wenn Sie einen Cache-Cluster mit einer einzelnen Partition starten, werden alle 1000 Buckets diesem Knoten zugewiesen. Das bedeutet, dass alle Daten auf dieser Partition landen. Wenn Sie einen anderen Knoten im Cluster starten, werden die Buckets gleichmäßig auf die beiden Partitionen mit jeweils 500 Buckets verteilt. Ähnlich verhält es sich mit dem Hinzufügen eines dritten Knotens zum Cluster: Die Buckets sind wieder vorhanden redisgewürdigt. In diesem Fall verfügen die drei Knoten über 333, 333 bzw. 334 Buckets.
Wenn eine Partition den Cluster verlässt, ändert sich auch die Bucket-Verteilung. Wenn beispielsweise eine Partition einen Cluster mit drei Knoten verlässt, werden die 333 oder 334 Buckets, die dieser Partition gehören, gelöscht redisauf die verbleibenden zwei Knoten verteilt. Bei jeder Änderung der Verteilung wird eine Statusübertragung ausgelöst, um die Daten zwischen den Knoten entsprechend der Bucket-Verteilung neu auszugleichen.
Zufällige Verteilung der Daten
Diese Partitionierungsmethode bietet Ihnen ein angemessenes Maß an Zufälligkeit, um sicherzustellen, dass die Daten gleichmäßig zwischen den Buckets und Partitionen aufgeteilt werden. Allerdings verlieren Sie bei dieser Partitionierungsmethode die Kontrolle darüber, welche Daten welcher Partition zugeordnet werden sollen. Meistens ist es Ihnen egal, wohin Ihre Daten gehen. In einigen Fällen möchten Sie jedoch möglicherweise, dass die zugehörigen Daten am selben Ort gespeichert werden. Hierzu können Sie Location Affinity verwenden, bei dem eine Hash-Funktion auf einen Teil des Schlüssels statt auf den gesamten Schlüssel angewendet wird.
Ausgewogene Verteilung der Daten
Immer wenn Eimer da sind rediszwischen den Knoten gewürdigt, NCache stellt sicher, dass die Eimer sind redisso angepasst, dass die Datenmenge, die jede Partition empfängt, nahezu gleich ist. Jede Partition teilt die Statistiken der Buckets, die ihr gehören, in einem konfigurierbaren Intervall mit anderen Partitionen im Cluster. Dies hilft bei Bedarf bei der Erstellung einer ausgewogenen Verteilungskarte, die im Hinblick auf die Daten, die jede Partition erhält, fair ist. Die Bilanzierung basiert auf der Größe der Daten und nicht auf der Anzahl der Elemente. Dieser Ausgleich wird in der Regel zum Zeitpunkt des Buckets sichergestellt redisTribut als Ergebnis des Verlassens oder Beitretens eines Knotens.
Automatischer und manueller Datenlastausgleich
Es besteht jedoch eine geringe Wahrscheinlichkeit, dass Sie feststellen, dass eine oder mehrere Partitionen in einem Cluster schief sind und mehr Last erhalten als die anderen. In diesem Fall haben Sie die Möglichkeit, die Daten eines bestimmten Knotens manuell auszugleichen, um sicherzustellen, dass die Daten auf diesem Knoten der durchschnittlichen Datengröße entsprechen, die jede Partition empfängt. Dann gibt es noch eine Funktion namens „Auto Data Load Balancing“, die diese Aufgabe automatisch im Hintergrund erledigt. Diese Funktion ist standardmäßig deaktiviert, da sie bei unvorsichtiger Verwendung zu häufigen Buckets führen kann redisVerteilung und damit unerwünschte Zustandsübertragungen zwischen den Partitionen.
Datengröße pro Partition
Die Datengröße, die jede Partition aufnehmen kann, entspricht der konfigurierten Cache-Größe. Wenn die konfigurierte Cachegröße beispielsweise 2 GB beträgt und die Clustergröße aus drei Partitionen besteht, beträgt die Gesamtcachegröße in diesem Cluster 6 GB.
Mit dieser Topologie verteilen Sie also nicht nur die Lese- und Schreiblast zwischen den Servern, sondern erhöhen auch die Kapazität mit jedem neuen Server, der dem Cluster hinzugefügt wird.
Partitionsreplikat
Nachdem wir nun behandelt haben, wie die Partition-Replica-Topologie die Transaktionslast und die Speicherkapazität skaliert. Lassen Sie uns darüber sprechen, wie es mit Hochverfügbarkeit umgeht. Jeder Knoten im Cluster verfügt über eine Sicherung einer anderen Partition, die als passive Partition fungiert und als Replikat bezeichnet wird. Im Falle eines Knotenausfalls weiß der Cache-Cluster, dass die Daten der verlorenen Partition weiterhin in seinem Replikat verfügbar sind. Somit laufen die Client-Anwendungen weiterhin reibungslos, da die Daten der verlorenen Partition weiterhin vom Cluster über dieses Replikat bereitgestellt werden.
Die Clientanwendungen kommunizieren direkt nur mit den aktiven Partitionen. Jede Partition ist dann für die Replikation ihrer Daten auf ihr jeweiliges Replikat verantwortlich.
Auch wenn der Replikationsgrad in dieser Topologie nicht so hoch ist wie in der Replizierte TopologieWenn Sie mindestens ein Backup haben, stellen Sie sicher, dass Ihre Daten im Falle eines Knotenausfalls immer noch sicher sind. Solange es nicht zu gleichzeitigen Knotenausfällen kommt, sind die Daten in dieser Topologie sicher, was die meisten Szenarien abdeckt.
Jeder Clusterknoten verfügt über eine aktive und eine Replikatinstanz, und auf jedem Clusterknoten sind sowohl aktive als auch Replikatinstanzen im selben Cacheprozess vorhanden.
Da die Replikatinstanz auf jedem Cache-Knoten vorhanden ist, benötigt sie die gleiche Speichergröße wie die aktive Cache-Instanz. Das bedeutet, dass jeder Partition-Replica-Cache-Knoten im Vergleich zu seiner konfigurierten Cache-Größe doppelt so viel Speicher benötigt.
Alle vom Client hinzugefügten Daten werden im aktiven Knoten gespeichert und von dort aus auf sein dediziertes Replikat repliziert, das sich auf einem anderen Knoten im Cluster befindet. Diese Anordnung der Replikatknoten stellt sicher, dass keine Daten verloren gehen, wenn ein aktiver Knoten ausfällt.
Strategie zur Replikatauswahl
NCache wählt den Replikatknoten automatisch auf der Grundlage der Reihenfolge aus, in der die Knoten dem Cache-Cluster beitreten. Das Replikat des ersten Knotens ist auf dem Serverknoten vorhanden, der dem Cluster nach dem ersten Knoten beigetreten ist, und so weiter. Und die Replik des letzten Knotens wird auf dem ersten Serverknoten (Koordinatorserver) des Cache-Clusters platziert.
Dieser gesamte Replikatauswahlprozess erfolgt automatisch. Immer wenn ein Serverknoten den Cache-Cluster verlässt oder ein neuer Knoten dem Cache-Cluster beitritt, werden die Replikate ebenfalls entsprechend der aktualisierten Mitgliedschaftszuordnung neu zugewiesen.
Speicherverbrauch einzelner Knoten
Jeder Serverknoten (aktiv und Replikat) zeichnet die konfigurierte Cachegröße auf und stellt sicher, dass die gespeicherten Daten niemals das angegebene Speicherlimit überschreiten. Es gibt zwei spezielle Szenarien, in denen diese Speicherlimitprüfung unterschiedlich funktioniert. Sie werden im Folgenden erläutert:
- Nur ein Knoten befindet sich im Betriebszustand und ihm werden Daten hinzugefügt. Die aktive Cache-Instanz kann das Doppelte der angegebenen Cache-Größe zum Speichern der Daten verwenden, da ihr Replikat keinen Nutzen hat.
- Wenn in einem Cluster mit mehreren Knoten alle anderen Knoten den Cluster verlassen und nur ein Knoten am Leben bleibt, werden Daten von seiner Replikat-Cache-Instanz an die aktive Cache-Instanz übertragen. Der freie Speicher des Replikats wird dann vom aktiven Cache genutzt, um die vom Replikat empfangenen Daten aufzunehmen.
Replikationsstrategien
Die Partition-Replica-Topologie verfügt über zwei Replikationsstrategien, um die Daten vom aktiven Serverknoten auf den Replikatknoten zu replizieren:
Asynchrone Replikation: In diesem Modus werden Hintergrundwarteschlangen verwendet, um die Daten zu replizieren, ohne die Clientvorgänge zu blockieren. Jeder Schreibvorgang wird in die Warteschlange gestellt, und dedizierte Hintergrundthreads wählen die Daten in Blöcken aus dieser Warteschlange aus und replizieren sie auf die Replikatinstanz. Diese Replikationsstrategie eignet sich für Anwendungen, die dazu neigen, häufig zu schreiben, aber nicht auf den Abschluss der Replikationen warten möchten, bevor sie den nächsten Cache-Vorgang durchführen. Es besteht jedoch die Möglichkeit eines Datenverlusts, wenn ein Knoten abrupt verlässt. In diesem Fall gehen nicht replizierte Vorgänge in der Warteschlange verloren.
Synchronisierungsreplikation: Im synchronen Replikationsmodus wird jeder Schreibvorgang vom Client auf das Replikat repliziert, bevor die Kontrolle an die Clientanwendung zurückgegeben wird. Dieser Replikationsmodus stellt sicher, dass sowohl die aktiven als auch die Replikat-Cache-Instanzen über dieselbe Kopie der Benutzerdaten verfügen. Wenn die Replikation auf der Replikatinstanz fehlschlägt, wird das Element aus den aktiven und Replikat-Cache-Instanzen entfernt.
Betriebsverhalten
Räumungen, Ablauf, Abhängigkeiten, writeThru/writeBehindusw. werden vom aktiven Knoten gesteuert. Immer wenn ein aktiver Knoten aufgrund einer der genannten Funktionen ein Element von ihm entfernt, repliziert er es auf sein Replikat, um die zuvor gespeicherten Daten daraus zu entfernen. Ähnlich, writeThru/writeBehind Operationen werden nur aus dem aktiven Cache ausgeführt.
In der Partition-Replica-Topologie sind die Clients direkt mit jedem Serverknoten verbunden, jedoch nur mit seinen aktiven Partitionen/Instanzen. Allerdings gibt es einige Situationen, in denen die Clients vorübergehend über Clusteraufrufe mit den Replikatinstanzen interagieren. Sie werden im Folgenden erläutert:
- Wenn während der Statusübertragung ein Knoten den Cluster verlässt, werden die für den verlassenden Knoten vorgesehenen Clientoperationen von seinem Replikat aus bedient.
- Wenn sich ein Cluster im Wartungsmodus befindet, werden alle für den zu wartenden Knoten vorgesehenen Vorgänge während des Wartungszeitraums von seinem Replikat aus bedient.
Staatliche Übertragung
Der Statustransfer ist ein Prozess zum automatischen Übertragen/Kopieren der Daten zwischen den Cache-Knoten. Die Statusübertragung wird ausgelöst, wenn ein neuer Knoten dem Cluster beitritt oder ein aktueller Knoten den Cluster verlässt. Das Verlassen/Beitreten eines Knotens führt auch zu einer Änderung der Mitgliedschaft im Cluster.
Wenn ein Knoten die Aktualisierung empfängt Verbreitungskarteüberprüft es die Existenz der Buckets (die ihm zugewiesen wurden) in seiner lokalen Umgebung. Die zugewiesenen Buckets, die in der lokalen Umgebung des Knotens nicht vorhanden sind, werden einzeln von anderen Knoten abgerufen. Abhängig von der Anzahl der Serverknoten im Cache-Cluster werden also während der Statusübertragung mehrere Buckets übertragen.
Die Statusübertragung wird in den folgenden drei Hauptszenarien ausgelöst:
Beim Knotenbeitritt
Wenn ein neuer Knoten dem Cache-Cluster beitritt, generiert der Koordinatorserver eine neue Verteilungskarte, um die Buckets von den aktuellen Knoten an den neu beigetretenen Knoten zu verteilen. Und nach Erhalt der Verteilungskarte ruft der neu beigetretene Knoten die Buckets von den aktuellen Knoten ab. Während dieser Statusübertragung ruft der neu verbundene Knoten jeweils einen Bucket ab. Nachdem er einen Bucket empfangen hat, ruft er den nächsten Bucket ab und so weiter, bis er alle ihm zugewiesenen Buckets gemäß seiner Verteilungskarte von anderen Knoten abruft.
Beim Verlassen des Knotens
Ebenso wird die Zustandsübertragung ausgelöst, wenn ein Cache-Knoten den Cache-Cluster verlässt. Der Koordinatorserver redisverteilt seine Buckets auf die aktiven Knoten des Clusters. In diesem Fall rufen die aktiven Knoten die Daten aus dem Replikat des ausgehenden Knotens ab.
Note
Wenn mehr als ein Knoten gleichzeitig oder nacheinander den Cluster verlässt, während bereits eine Statusübertragung läuft, kann es zu Datenverlust kommen
Zum automatischen Datenlastausgleich
Die Partition-Replica-Topologie verfügt über die Funktion Automatischer Datenlastenausgleich Dabei überwacht es kontinuierlich die Verteilung der Daten zwischen den Clusterknoten. Und wenn die Datenverteilung nicht innerhalb des erwarteten Verteilungsbereichs (60 % bis 40 %) liegt, wird automatisch der automatische Datenlastausgleich ausgelöst. In diesem Fall generiert der Koordinatorserver eine neue Verteilungskarte neu und redisTributiert die Buckets so, dass alle Clusterknoten über Daten gleicher Größe verfügen.
Note
Es kann auch ein Datenlastausgleich durchgeführt werden manuell von dem NCache Managementzentrum.
Was auch immer der Grund für die Staatsübertragung ist, dieser gesamte Prozess erfolgt automatisch und nahtlos. Und während der Statusübertragung, insbesondere wenn ein Serverknoten den Cache-Cluster verlässt, werden alle Client-Operationen, die für den verlassenden Knoten bestimmt waren, von seinem Replikat über Cluster-Operationen bedient.
Replikate führen ebenso wie andere aktive Knoten auch eine Statusübertragung von ihren aktiven Knoten durch. Replikate ziehen ihre zugewiesenen Buckets von ihren aktiven Knoten, um die Kopie der Daten zum Zeitpunkt der Statusübertragung abzurufen. Diese Statusübertragung findet jedoch nur bei einer Bucket-Neuzuweisung statt. Andernfalls werden die Daten über den Replikationsmechanismus auf die Replikate repliziert.
Verschiedene Möglichkeiten zur Überwachung der Zustandsübertragung
NCache bietet mehrere Möglichkeiten zur Überwachung der Statusübertragung im Cache-Cluster. Sie werden im Folgenden erläutert:
- Cache-Protokolle: Wann immer die Statusübertragung ausgelöst und gestoppt wird, wird dies in den Cache-Protokollen des Clusters protokolliert. Cache-Protokolle sind unter vorhanden %NCHOME%/bin/log -Ordner.
- Benutzerdefinierte Zähler: NCache veröffentlicht auch benutzerdefinierte Zähler, die unter Windows und Linux angezeigt werden können.
- Perfmon-basierte Zähler: Unter Windows NCache veröffentlicht auch die Zustandsübertragungszähler über das Windows-Tool Perfmon.
- Windows-Ereignisprotokolle: Informationen/Ereignisse im Zusammenhang mit der Statusübertragung werden auch in den Windows-Ereignisprotokollen veröffentlicht.
- E-Mail-Benachrichtigungen: Statusübertragungsspezifische E-Mail-Benachrichtigungen können hinsichtlich ihrer Einleitung und Beendigung konfiguriert werden.
Client-Konnektivität
Wie bei der Partitionierung erläutert, werden die Daten auf alle Server im Cluster verteilt. Im Gegensatz zu anderen Topologien muss der Client für partitionierte Topologien eine Verbindung mit allen Partitionen herstellen, wobei jede Partition eine Teilmenge der Gesamtdaten enthält.
Der Client erhält beim Connect-Aufruf eine Verteilungskarte, die den Client über die laufenden Serverknoten und deren informiert Hash-basierte Verteilungen. Der Client stellt eine Verbindung zu allen Serverknoten her, um vollständige Daten aus dem Cache abzurufen. Der Kunde erhält eine aktualisierte Karte bei jeder Änderung der Clustermitgliedschaft, um die Konnektivität aufrechtzuerhalten. Der Client erhält außerdem eine Benachrichtigung über den Austritt/Beitritt eines Mitglieds und setzt die Konnektivität entsprechend dem Empfang zurück Karte.
Der Client führt die Lese-/Schreibvorgänge auf intelligente Weise direkt auf dem Serverknoten aus, der den Schlüssel entsprechend enthält Hash-basierte Verbreitungskarte es empfängt. Für alle Operationen, bei denen der Schlüssel nicht bekannt ist, z SQL-Suche, GetByTagsusw. sendet der Client die Anfrage an alle Serverknoten und kombiniert deren jeweilige Antworten.
Wenn der Client in jedem Fall keine Verbindung zu einem Serverknoten des Clusters herstellen kann, bedeutet das nicht, dass er keine Informationen von diesem Serverknoten schreiben und abrufen kann. Zu diesem Zweck nutzt es die anderen Serverknoten, mit denen es verbunden ist, und fordert in seinem Namen den nicht erreichbaren Serverknoten auf, Operationen auszuführen. Wenn der Client beispielsweise keine Verbindung zu Knoten1 herstellen kann und einen Schlüssel erhalten möchte, der sich in Knoten1 befindet, sendet er die Anfrage an Knoten2, der sie an Knoten1 weiterleitet und die Antwort zurückgibt.
Wartungsmodus
Wenn ein Patch oder ein Upgrade von Hardware/Software erforderlich ist NCache Auf dem Server kann es zu keinen Ausfallzeiten der Anwendung kommen. Das Stoppen eines Cache-Knotens löst jedoch aus staatliche Übertragung innerhalb des gesamten Cache-Clusters, was zu einer übermäßigen Nutzung von Ressourcen wie Netzwerk, CPU und Speicher führt. Das staatliche Übertragung Der Vorgang kann je nach Größe der Cache-Daten und des Clusters kostspielig sein. Ein typischer Upgrade-Workflow umfasst den Neustart des Cache-Knotens nach dem anderen, was zwei Statusübertragungen erfordert, eine beim Verlassen des Knotens und die andere beim Knotenbeitritt.
Wartungsmodus wird eingeführt, um diese kostspieligen Zustandsübertragungen während der Wartung auf Cache-Servern zu vermeiden. Sobald ein Cache-Server für eine bestimmte Zeit wegen Wartungsarbeiten angehalten wird, wird das Replikat des zu wartenden Knotens vorübergehend aktiv und beginnt mit der Bearbeitung von Client-Anfragen. Wenn der Knoten (der gerade gewartet wurde) wieder beitritt, nachdem seine Wartung innerhalb der angegebenen Zeit abgeschlossen wurde, wird der staatliche Übertragung wird für diesen Knoten initiiert, um ihn mit dem Cache-Cluster zu synchronisieren.
Der Cluster verlässt die Wartungsmodus in drei verschiedenen Staaten. Wenn der Wartungsknoten innerhalb der angegebenen Zeit dem Cache-Cluster beitritt, staatliche Übertragung wird initiiert, um den Status des Clusters zu synchronisieren, und der Cluster verlässt den Wartungsmodus. Wenn der Wartungsknoten innerhalb der angegebenen Zeit nicht wieder dem Cache-Cluster beitreten kann, geht der Cluster davon aus, dass der Knoten ausgefallen ist, und verlässt den Wartungsmodus, erzeugt eine neue Karteund startet die staatliche Übertragung. Abgesehen von Erfolg und Misserfolg gibt es noch eine weitere Anomalie Wartungsmodus, dh wenn ein Knoten verlässt. Wenn sich der Cluster im befindet Wartungsmodus und jeder andere Knoten als der Wartungsknoten verlässt den Cluster WartungsmodusDies kann zu Datenverlust führen.
Split-Brain-Recovery
Die Geteiltes Gehirn bezieht sich auf einen Zustand, in dem ein Cache-Cluster in mehrere Untercluster aufgeteilt wird. Cache-Server in einem Cluster kommunizieren über TCP. Daher kann jeder Netzwerkfehler oder jedes Problem zu einem Kommunikationsverlust zwischen den in einem Cluster vorhandenen Servern führen. Wenn der Kommunikationsverlust zwischen den Servern über einen bestimmten Zeitraum hinausgeht, ändert sich die Mitgliedschaftskarte entsprechend der Konnektivität zwischen den Servern. Dies führt zur Bildung mehrerer Subcluster. Diese Untercluster werden Splits genannt. Wir nennen es geteiltes Gehirn da die Subcluster nicht miteinander kommunizieren können, ähnlich wie die Gehirnhälften beim Split-Brain-Syndrom nicht miteinander kommunizieren können.
Alle Subcluster sind fehlerfrei und verarbeiten die darin enthaltenen Daten. Darüber hinaus können Clients für weitere Lese-/Schreibvorgänge eine Verbindung zu diesen Subclustern herstellen. Der Client erhält eine Mitgliedschaftskarte von Clusterservern, um die Konnektivität zu aktualisieren. Hier kann sich der Client abhängig von der ersten empfangenen Karte mit jedem Subcluster verbinden.
Geteiltes Gehirn wird nur erkannt, wenn die Kommunikation zwischen Servern wieder aufgenommen wird und festgestellt wird, dass alle Server betriebsbereit, aber nicht Teil eines einzelnen Clusters sind. Abhängig vom Kommunikationsverlust zwischen den Servern sind zwei oder mehr Aufteilungen möglich. Einmal geteiltes Gehirn erkannt wird, wird der Wiederherstellungsprozess eingeleitet. Alle Teilungen werden nacheinander wiederhergestellt, bis alle Untercluster zusammengeführt werden.
Das geteiltes Gehirn Der Wiederherstellungsprozess wird unmittelbar nach seiner Erkennung eingeleitet. Es benötigt zwei fehlerfreie Aufteilungen, identifiziert deren Koordinatorserver, entscheidet auf Grundlage der Clustergröße über die Gewinner- und Verliereraufteilung, erwirbt eine Sperre für die Verliereraufteilung, um die Clientaktivität auf diesem Cluster einzuschränken, und ändert die Clustermitgliedschaft. Danach werden alle Clients zum Gewinner-Cluster-Split umgeleitet und alle Knoten des Verlierer-Splits werden nacheinander neu gestartet, um dem Gewinner-Cluster beizutreten. Alle Verlierer-Splits verschmelzen auf die gleiche Weise mit dem Gewinner-Cluster-Split und der Cluster wird wieder gesund.
Mit Datenverlust ist zu rechnen geteiltes Gehirn Bei der Wiederherstellung kommt es bei der Aufteilung des Clusters in mehrere Untercluster zu Datenverlusten, da mehrere Knoten in einem Cluster gleichzeitig den Cluster verlassen. Die Subcluster können Kundenanfragen in einem Zustand von bearbeiten geteiltes Gehirn, können diese Vorgänge verloren gehen, wenn der Split, mit dem der Client verbunden ist, ein Verlierer-Split ist, der neu gestartet wird, um dem Hauptcluster beizutreten.
Siehe auch
Replizierte Topologie
Gespiegelte Topologie
Cache-Cluster
Lokaler Cache