Clustering | Die Slave-Instanz funktioniert nicht mehr

Symptom

Fehler beim Starten der Slave-Instanz werden unter verschiedenen Szenarien, wie z. B. den folgenden, beobachtet:

a) Den Slave-Knoten für das Offline-Backup herunterfahren und dann die Sicherung starten
b) Den Cluster für Wartungsarbeiten herunterfahren und dann die Cluster-Knoten starten.

Ursachen

1) Netzwerkprobleme von Seiten der Infrastruktur - Slave kommt in die Situation Zeitüberschreitung für „Lesen vom Master ausgelöst“

Lösung: Bitte prüfen Sie Ihre Netzwerkinfrastruktur und stellen Sie sicher, dass es keine Firewall-Änderungen oder -Ausfälle gibt, um zu überprüfen, ob Master- und Slave-Knoten miteinander kommunizieren können.

2) Inkorrekte Reihenfolge beim Starten / Stoppen der Cluster-Knoten - Verursacht, dass man in eine „nicht mehr synchrone“ Situation kommt.

Analyse und möglicher Grund für nicht mehr synchrone Clusterknoten

Sie kommen in diese Situation aufgrund einer falschen Abfolge beim Herunterfahren und Neustarten von Clusterknoten. Wenn der Server, auf dem sich die Master-Instanz befand, im Rahmen der regulären Wartung heruntergefahren wurde und der Slave die Rolle des neuen Masters übernahm und es zugelassen wurde, dass er als eigenständige Instanz ausgeführt wird. Zu einem späteren Zeitpunkt, als der Slave heruntergefahren wurde und die Master-Instanz gestartet wurde, verweigerte der Slave die Verbindung und die Knoten waren nicht mehr synchron. Dies wird erwartet, da der Slave neuere Revisionen haben würde. 

Lösung: 

a) Lassen Sie den alten Slave-Knoten als neuen Master laufen.

b) Starten Sie den alten Master und lassen Sie ihn einstweilen als „aktueller Slave“ zu.

c) Lassen Sie es zu, dass der alte Master [aktueller Slave] eine Verbindung zum alten Slave [neuer Master] herstellt, und sich selbst mit den neuesten Revisionen synchronisiert. 

d) Nachdem die Synchronisierung abgeschlossen ist, können Sie die Rollen von Master und Slave wechseln, indem Sie einfach den aktuellen Master [alter Slave] Knoten beenden und neu starten.

e) Wenn der aktuelle Master [alter Slave] gestoppt wird, erhält der aktuelle Slave [alter Master] die Master-Rolle zurück.

3) Manuelles Löschen der Marker-Datei Clustered.txt auf jedem gestoppten Cluster-Knoten - Dies bewirkt, dass die Instanz als Master-Knoten gestartet wird, während sie eigentlich als Slave-Knoten starten und sich an einen vorhandenen Master anschließen sollte.

Analyse und möglicher Grund für nicht mehr synchrone Clusterknoten

Wenn Sie in eine abrupte Situation kommen oder Ihre laufende Master-Instanz nicht ordnungsgemäß herunterfährt, kann die Master-Instanz nach dem Neustart nicht wieder mit dem Cluster verbunden werden. Dies kann in Fällen auftreten, in denen ein Schreibvorgang zu dem Zeitpunkt ausgeführt wurde, als der Master-Knoten gestoppt wurde oder wenn ein Schreibvorgang einige Sekunden vor dem Stoppen der Master-Instanz ausgeführt wurde. In diesen Fällen empfängt die Slave-Instanz möglicherweise nicht alle Änderungen von der Master-Instanz. Wenn der Master dann neu gestartet wird, erkennt CRX, dass er nicht mit den verbleibenden Clusterinstanzen synchronisiert ist und das Repository wird nicht gestartet.

Möglicherweise haben Sie versucht, den Master-Clusterknoten zu starten, indem Sie die Datei „clustered.txt“ manuell gelöscht haben. Im Allgemeinen sollte die Datei clustered.txt niemals gelöscht werden, um die Instanz zu starten. Es ist eine Marker-Datei, die uns wissen lässt, dass diese Instanz beim nächsten Start als Slave angemeldet werden muss. Der Clusterknoten, der zuletzt beendet wird, hat keine Datei „clustered.txt“. Dies hilft zu erkennen, dass dieser Knoten der letzte laufende Master-Knoten war und zuerst gestartet werden sollte.

Wenn diese Datei vorhanden ist, kann der Knoten nicht als Master-Knoten gestartet werden. Sie sollten folgende Meldung erhalten.

Erklärung:

Dies bedeutet, dass ein anderer Clusterknoten ausgeführt wurde, auch nachdem dieser Knoten gestoppt wurde, sodass jener Knoten die neuesten Revisionen und Inhalte aufweist. Daher ist der letzte Knoten, der im Cluster gestoppt wird, immer der Master-Knoten, wenn Sie die Cluster-Knoten starten.

Lösung:

a) Stoppen Sie den Slave-Knoten, der diesen Ausnahmefehler „Out-of-Sync“ ausgelöst hat

b) Stoppen Sie den aktuell laufenden Master-Knoten (der durch Löschen der Datei „clustered.txt“ gestartet wurde)

c) Starten Sie den Slave-Knoten (in diesem Fall wäre es der letzte laufende Master, da er die letzten Revisionen hat). Dieser wird jetzt als neuer Master übernehmen

d) Starten Sie den Master-Knoten, der dann als Slave dem Cluster beitreten soll

e) Sobald die Synchronisierung abgeschlossen ist, können Sie den aktuell laufenden Master-Knoten (alter Slave) stoppen und starten, um die Rollenkonsistenz von Master als Master und Slave als Slave wiederherzustellen

Was bedacht werden muss, wenn Sie den Master klonen, um den Slave zu erstellen

Aufgrund von nicht ordnungsgemäßem Herunterfahren / hartem Neustart / Netzwerkproblemen / Stromausfällen usw. eines der Cluster-Knoten, falls für den Fall, dass das Synchronisationsproblem auftritt, die Clusterknoten nicht mehr miteinander synchronisiert sind, müssen Sie entweder die alte Sicherung wiederherstellen oder den Clusterknoten neu erstellen.

In solchen Szenarien müssen Sie einen Klon eines Cluster-Knotens erstellen und als neuen Slave dem Cluster beifügen. Sie müssen also feststellen, welcher Knoten zuletzt als Master-Knoten ausgeführt wurde, da dieser Knoten den aktuellsten Inhalt und die neuesten Revisionen hat. Dann sollten Sie nur das Backup auf diesem Knoten durchführen und einen Slave erstellen.