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“

On Master:
com.day.crx.core.cluster.ClusterMaster I/O error while processing connect. java.net.SocketTimeoutException: Read timed out
On Slave:
com.day.crx.core.cluster.ClusterMaster I/O error while processing connect. java.net.SocketTimeoutException: Read timed out

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.

* ClusterTarSet: Could not open (ClusterTarSet.java, line 820)
java.io.IOException: This cluster node and the master are out of sync. Operation stopped.
Please ensure the repository is configured correctly.
To continue anyway, please delete the index and data tar files on this cluster node and restart.
Please note the Lucene index may still be out of sync unless it is also deleted

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.

 

ClusterController: Trying to connect to a master, as the file clustered.txt exists.

Hinweis:

Die Datei „clustered.txt“ sollte niemals gelöscht werden, um die Instanz zu starten. Dies sollte nur dann erfolgen, wenn Sie die Instanz als eigenständiges Programm starten und nicht zu einem Teil eines Clusters machen möchten.

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

Hinweis:

 

a) Weitere Informationen zur „Out-of-Sync“-Situation finden Sie in unserem Dokumentationslink

b) Weitere Informationen zum Verfahren zum Klonen des Slaves finden Sie in unserem Dokumentationslink

 

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.

Hinweis:

Wenn Sie versuchen, den falschen Knoten zu klonen (und der alte Master wird zuerst gestoppt), würden Sie ein hohes Risiko haben, Daten im letzten laufenden Knoten zu verlieren. Stellen Sie also sicher, dass Sie bei der Auswahl des zu klonenden Knotens den richtigen Knoten auswählen.

Hinweis:

Dieser Artikel bezieht sich auf alle CQ 5.x-Versionen, die nur CRX-Version 2.x haben (größer als 2.2.0.36)

Dieses Werk unterliegt den Bedingungen der Creative Commons Attribution-Noncommercial-Share Alike 3.0 Unported License.  Twitter™- und Facebook-Beiträge fallen nicht unter die Bedingungen der Creative Commons-Lizenz.

Rechtliche Hinweise   |   Online-Datenschutzrichtlinie