Für die Unterstützung der Replikation setzt sich der Lebenszyklus von Shards aus verschiedenen Stadien und Ereignissen zusammen. Der Lebenszyklus eines Shards setzt sich aus dem Onlinebringen, der Laufzeit, dem Beenden, potenziellen Failover und der Fehlerbehandlung zusammen. Shards können als Reaktion auf einen geänderten Serverstatus von einem Replikat-Shard auf ein primäres Shard hochgestuft werden.
Wenn primäre Shards und Replikat-Shards verteilt und gestartet werden, finden verschiedene Ereignisse statt, um die Shards online zu bringen und in den Empfangsmodus zu versetzen.
Primäres Shard
Der Katalogservice verteilt ein primäres Shard für eine Partition. Außerdem verteilt der Katalogservice die Positionen der primären Shards gleichmäßig und leitet das Failover für die primären Shards ein.
Wenn ein Shard zu einem primären Shard wird, erhält es eine Liste mit Replikaten vom Katalogservice. Das neue primäre Shard erstellt eine Replikatgruppe und registriert alle Replikate.
Wenn das primäre Shard bereit ist, wird eine Nachricht in der Datei SystemOut.log für den Container, in dem das Shard ausgeführt wird, protokolliert, in der darauf hingewiesen wird, dass das Shard für das Geschäft bereit ist. In der Nachricht für die Geschäftsbereitschaft (oder die Nachricht CWOBJ1511I) sind der Map-Name, der Name des MapSets und die Partitionsnummer des gestarteten primären Shards aufgelistet.
CWOBJ1511I: Map-Name:MapSet-Name:Partitionsnummer (primär) ist für Business bereit.
Weitere
Informationen zur Verteilung der Shards durch den Katalogservice finden Sie im Abschnitt Shardverteilung.Replikat-Shards werden hauptsächlich vom primären Shard gesteuert, sofern das Replikat-Shard keine Probleme feststellt. Während eines normalen Lebenszyklus ist das primäre Shard für das Verteilen, Registrieren und Zurücknehmen der Registrierung eines Replikat-Shards zuständig.
Wenn ein primäres Shard ein Replikat-Shard initialisiert, wird eine Nachricht im Protokoll angezeigt, die beschreibt, wo das Replikat ausgeführt wird, um so anzuzeigen, dass das Replikat-Shard verfügbar ist. In der Nachricht für die Geschäftsbereitschaft (oder die Nachricht CWOBJ1511I) sind der Map-Name, der Name des MapSets und die Partitionsnummer des Replikat-Shards aufgelistet. Diese Nachricht sehen Sie im Folgenden:
CWOBJ1511I: Map-Name:MapSet-Name:Partitionsnummer (synchrones Replikat) ist für Business bereit.
oderCWOBJ1511I: Map-Name:MapSet-Name:Partitionsnummer (asynchrones Replikat) ist für Business bereit.
Asynchrones Replikat-Shard: Ein asynchrones Replikat-Shard fragt Daten vom primären Shard ab. Das Replikat passt die Abfragetaktung automatisch an, wenn es keine Daten vom primären Shard empängt, was darauf hinweist, das die Verbindung zum primären Shard blockiert ist. Die Taktung wird auch angepasst, wenn das Replikat einen Fehler empfängt, der auf einen Ausfall des primären Shards oder auf ein Netzproblem hinweist.
CWOBJ1543I: Das asynchrone Replikat objectGrid-Name:MapSet-Name:Partitionsnummer wurde gestarter
bzw. setzt die Replikation über das primäre Shard fort. Replikation für die Maps: [Map-Namen]
Synchrones Replikat-Shard: Wenn das synchrone Replikat-Shard gestartet wird, ist es noch nicht im Peer-Modus. Wenn sich ein Replikat-Shard im Peer-Modus befindet, empfängt es Daten vom primären Shard, sobald Daten beim primären Shard eintreffen. Vor dem Wechsel in den Peer-Modus benötigt das Replikat-Shard eine Kopie aller vorhandenen Daten im primären Shard.
Das synchrone Replikat kopiert ähnlich wie ein asynchrones Replikat Daten vom primären Shard, indem es Daten abfragt. Wenn es die vorhandenen Daten vom primären Shard kopiert, wechselt es in den Peer-Modus und empfängt die Daten, sobald das primäre Shard die Daten empfängt.
CWOBJ1526I: Replikat ObjectGrid-Name:Mapset-Name:Partitionsnummer:Map-Name wechselt
in X Sekunden in den Peer-Modus.
Wenn das synchrone Replikat-Shards im Peer-Modus arbeitet, muss das primäre Shards Transaktionen auf alle im Peer-Modus arbeitenden synchronen Replikate kopieren. Das synchrone Replikat-Shard hat dieselbe Version der Daten wie das primäre Shard. Wenn in der Implementierungsrichtlinie eine minimale Anzahl synchroner Replikate oder minSync definiert ist, muss diese Anzahl synchroner Replikate der Festschreibung zustimmen, bevor die Transaktion erfolgreich auf dem primären Shard festgeschrieben werden kann.
Die Replikation ist für die Wiederherstellung nach Ausfällen und Fehlereignissen bestimmt. Wenn ein primäres Shard ausfällt, wird seine Arbeit von einem anderen Replikat übernommen. Treten Fehler bei den Replikat-Shards auf, versucht das Replikat-Shard, eine Recovery durchzuführen. Der Katalogservice steuert die Verteilung und Transaktionen der neuen primären Shards bzw. neuen Replikat-Shards.
Replikat-Shards wird zu einem primären Shard
Ein Replikat-Shard kann aus zwei Gründen zu einem primären Shard werden. Das primäre Shard wird gestoppt oder fällt aus, oder es wurde eine Entscheidung im Sinne der Lastverteilung getroffen, die ein Verschieben des vorherigen primären Shards an eine neue Position erfordert.
Der Katalogservice wählt ein neues primäres Shards unter den vorhandenen synchronen Replikat-Shards aus. Wenn ein primäres Shard verschoben werden muss und keine Replikate vorhanden sind, wird ein temporäres Replikat für den Übergang verwendet. Das neue primäre Shard registriert alle vorhandenen Replikate und akzeptiert anschließend Transaktionen als das neue primäre Shard. Wenn die vorhandenen Replikat-Shards die richtige Datenversion haben, werden die aktuellen Daten beibehalten, wenn sich die Replikat-Shards beim neuen primären Shard registrieren. Asynchrone Replikate fragen das neue primäre Shard ab.
Wiederherstellung von Replikat-Shards
Ein synchrones Replikat-Shard wird vom primären Shard gesteuert. Wenn ein Replikat-Shard jedoch ein Problem feststellt, kann es ein Ereignis zur Zurücknahme der Registrierung auslösen, um den Status der Daten zu korrigieren. Das Replikat-Shard löscht die aktuellen Daten und ruft eine aktuelle Kopie vom primären Shard ab.
Wenn ein Replikat-Shard ein Ereignis zur Zurücknahme der Registrierung einleitet, gibt das Replikat eine Protokollnachricht aus:
CWOBJ1524I: Replikat-Listener
ObjectGrid-Name:MapSet-Name:Partition muss sich beim primären Shard registrieren.
Ursache: Aufgelistete Ausnahme
Ein Replikat kann die Replikation von Daten einstellen, wenn es Fehlersituationen feststellt, die nicht behoben werden können.
Zu viele Registrierungsversuche
Wenn ein Replikat sich mehrfach erneut registriert, ohne die Daten erfolgreich festzuschreiben, wird das Replikat gestoppt. Das Stoppen verhindert, dass ein Replikat in eine Endlosschleife für die Registrierung eintritt. Standardmäßig wiederholt ein Replikat-Shard seinen Registrierungsversuch dreimal nacheinander, bevor es gestoppt wird.
Wenn sich ein Replikat-Shard zu oft neu registriert, gibt es die folgende Nachricht im Protokoll aus:
CWOBJ1537E: ObjectGrid-Name:MapSet-Name:Partition hat die zulässige Anzahl
erneuter Registrierungen (timesAllowed) ohne erfolgreiche Transaktionen überschritten.
Wenn die Wiederherstellung des Replikats durch erneute Registrierung nicht möglich ist,
kann ein tiefgreifendes Problem bei den Transaktionen, die sich auf das Replikat-Shard beziehen, vorliegen.
Ein mögliches Problem sind fehlende Ressourcen im Klassenpfad, wenn ein Fehler bei der Dekomprimierung der Schlüssel oder Werte aus der Transaktion auftritt.Fehler beim Wechsel in den Peer-Modus
Wenn ein Replikat versucht, in den Peer-Modus zu wechseln und ein Fehler bei der Verarbeitung des vorhandenen Datenvolumens vom primären Shard (Prüfpunktdaten) auftritt, wird das Replikat beendet. Das Beenden verhindert, dass ein Replikat mit ungültigen Anfangsdaten gestartet wird. Da das Replikat dieselben Daten vom primären Shard empfängt, wenn es sich erneut registriert, findet keine Wiederholung statt.
Wenn ein Replikat-Shard nicht in den Peer-Modus wechseln kann, gibt es die folgende Nachricht im Protokoll aus:
CWOBJ1527W Replikat ObjectGrid-Name:MapSet-Name:Partition:Map-Name konnte nach numSeconds Sekunden nicht in den Peer-Modus wechseln.
Es wird eine weitere
Nachricht im Protokoll angezeigt, die erläutert, warum das Replikat nicht in den Peer-Modus wechseln konnte.Fehler bei Wiederherstellung nach Neuregistrierung oder beim Wechsel in Peer-Modus
Wenn ein Replikat die erneute Registrierung nicht durchführen oder nicht in den Peer-Modus wechseln kann, bleibt das Replikat so lange inaktiviert, bis ein neues Verteilungsereignis stattfindet. Ein neues Verteilungsereignis kann das Starten oder Stoppen eines neuen Servers sein. Sie können ein Verteilungsereignis auch mit der Methode "triggerPlacement" in der MBean "PlacementServiceMBean" einleiten.