Symptôme

Une panne de démarrage de l’esclave peut être observée dans les différents cas suivants :

a) La réduction du nœud esclave pour la sauvegarde à froid puis son redémarrage
b) La réduction de la grappe pour les opérations de maintenance puis le démarrage des nœuds de la grappe.

 

Causes :

1) Problèmes de réseau au niveau de l’infrastructure - L’esclave se trouve dans une situation du type « communication avec le maître interrompue ».

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

Solution : Vérifiez votre infrastructure réseau et veillez à ce qu’il n’y ait aucune modification dans le pare-feu ni de coupures de courant afin de vous assurer que les nœuds maître et esclave peuvent communiquer entre eux.

 

2) Séquence incorrecte suivie pour démarrer et arrêter les nœuds de la grappe provoquant une situation de « désynchronisation ».

* 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 et causes possibles de la désynchronisation d’une grappe de nœuds :

Cette situation se produit en raison d’une séquence incorrecte d’arrêt et de redémarrage de nœuds de grappe. Si le serveur sur lequel le maître réside a été réduit dans le cadre d’une maintenance régulière et que l’esclave a été autorisé à prendre la place du maître, il prend les commandes de façon autonome. Plus tard lorsque l’esclave a été arrêté et que le maître a été lancé, l’esclave a refusé de se joindre à lui et les nœuds se sont désynchronisés. Ceci est prévu, étant donné que l’esclave aura subi de nouvelles révisions. 

 

Solution : 

a) Laissez l’ancien nœud esclave prendre la place du nouveau maître.

b) Démarrez l’ancien maître et laissez-le se joindre à l’esclave actuel pour l’instant.

c) Autorisez l’ancien maître [l’esclave actuel] à se connecter à l’ancien esclave [le maître actuel] et à se synchroniser lui-même avec les dernières révisions. 

d) Une fois la synchronisation terminée, vous pouvez ensuite changer les rôles de nœuds maître et esclave en arrêtant simplement le nœud maître actuel [l’ancien esclave] puis en le redémarrant.

e) Puisque le maître actuel [l’ancien esclave] est arrêté, l’esclave actuel [l’ancien maître] retrouve son rôle de maître.

 

3) Suppression manuelle d’un identifiant de fichier Clustered.txt sur tout nœud de la grappe arrêté - Ceci entraîne une instance à démarrer en tant nœud maître alors qu’il devait démarrer en tant nœud esclave et rejoindre un maître existant.

Analyse et causes possibles de la désynchronisation d’une grappe de nœuds :

S’il se produit un changement brusque ou un arrêt brutal de votre instance maître en cours d’exécution, l’instance maître ne peut pas rejoindre la grappe après avoir été redémarrée. Cela peut se produire lorsque l’opération d’écriture est en cours au moment où le nœud maître s’arrête, ou lorsqu’une opération d’écriture a lieu quelques secondes avant l’interruption de l’instance maître. Dans ce cas, l’instance esclave peut ne pas recevoir toutes les modifications de l’instance maître. Lorsque le maître est redémarré, CRX détecte qu’il est désynchronisé avec les autres instances de la grappe et que le référentiel ne démarre pas.

Vous avez également peut-être essayé de démarrer le nœud maître de la grappe en supprimant le fichier clustered.txt manuellement. En général, les clustered.txt ne doivent pas être supprimés pour démarrer l’instance. Il s’agit d’un fichier d’identification qui permet d’indiquer que cette instance doit se joindre à la grappe en tant qu’esclave la prochaine fois qu’il est démarré. Le nœud de grappe qui s’arrête le dernier ne contient pas de fichier clustered.txt. Cela permet d’identifier que ce nœud était le dernier nœud maître en cours d’exécution et doit être démarré en premier.

Si ce fichier est présent, le nœud ne peut pas être démarré comme nœud maître. Vous devriez recevoir un message comme ci-dessous.

Explication:

Cela signifie qu’un autre nœud de la grappe était en cours d’exécution même après l’arrêt de ce nœud afin qu’il dispose des dernières révisions et du dernier contenu. Par conséquent, le dernier nœud arrêté dans la grappe serait le nœud maître chaque fois que vous démarrez les nœuds de la grappe.

 

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

Remarque :

Les Clustered.txt ne doivent pas être supprimés pour démarrer l’instance. Cette opération ne doit être effectuée que si vous souhaitez démarrer l’instance comme autonome et ne pas l’intégrer à la grappe.

Solution :

a) Arrêtez le nœud esclave qui est responsable de cette désynchronisation exceptionnelle.

b) Arrêtez le nœud maître actuel en cours d’exécution (démarré par la suppression du fichier clustered.txt).

c) Démarrez le nœud esclave (dans ce cas, il est le dernier maître en cours d’exécution car il dispose des dernières révisions). Il prendra la place du nouveau maître.

d) Lancez le nœud maître, qui rejoint alors la grappe en tant qu’esclave.

e) Une fois la synchronisation terminée, vous pouvez arrêter et démarrer le nœud maître en cours d’exécution (l’ancien esclave) pour rétablir les rôles et pour que le maître se comporte comme maître et l’esclave comme esclave.

Remarque :

 

a) Pour plus d’informations sur la situation de désynchronisation, consultez notre documentation en suivant ce lien :

b) Pour plus d’informations sur la marche à suivre pour cloner l’esclave, consultez notre documentation en suivant ce lien :

 

Quand vous clonez le maître, n’oubliez pas de créer l’esclave.

En raison des problèmes d’arrêt brutal, de redémarrage difficile, de problèmes de réseau, de coupures de courant, etc. des nœuds de grappe, si vous rencontrez un problème de désynchronisation lorsque les nœuds de la grappe ne sont plus synchronisés les uns avec les autres, en tant que procédure de récupération, vous devez restaurer la grappe à partir de l’ancienne sauvegarde ou recréer le nœud de la grappe.

Dans ce cas, vous devez créer un clone d’un nœud de la grappe et le joindre à la grappe en tant que nouvel esclave. Vous devez donc identifier le nœud qui fut le dernier maître en cours d’exécution car ce nœud dispose des dernières révisions et du dernier contenu. Ensuite, effectuez la sauvegarde uniquement sur ce nœud et créez un esclave.

Remarque :

Si vous essayez de dupliquer le nœud incorrect (l’ancien maître en cours d’arrêt), il est probable que vous perdiez des données présentes dans le dernier nœud maître. Par conséquent, veillez à cloner le nœud correct.

Remarque :

Cet article s’applique à toutes les versions CQ 5.x qui possèdent la version CRX 2.x uniquement (supérieure à 2.2.0.36).

Ce produit est distribué sous licence Creative Commons Attribution - Pas d’utilisation commerciale - Partage à l’identique 3.0 non transposé  Les publications Twitter™ et Facebook ne sont pas couvertes par les dispositions Creative Commons.

Mentions légales   |   Politique de confidentialité en ligne