Elasticsearch:Restart a cluster or node

Vérifications avant le redémarrage

Effectuez les vérifications suivantes avant de redémarrer.

1. Vérifiez l'état de santé du cluster Connectez-vous au cluster via Kibana et exécutez la commande GET _cluster/health. Assurez-vous que le champ status indique green.

   Exception : le redémarrage forcé est disponible uniquement lorsque l'état est yellow ou red.

2. Garantissez la redondance des données. Exécutez la commande GET _cat/indices?v pour vérifier le nombre de réplicas (champ rep) pour tous les index critiques.

   • Le nombre de réplicas doit être d'au moins 1. Les index sans réplica seront inaccessibles pendant le redémarrage.

   • Pour les instances multi-zones, le nombre de réplicas doit être inférieur au nombre de zones.

3. Identifiez et gérez les index fermés. Exécutez la commande GET _cat/indices?v pour repérer les index dont le status est défini sur close.

   • Les index fermés bloquent l'allocation des shards et le redémarrage.

   • Pour rouvrir les index fermés, exécutez la commande POST /<index_name>/_open.

4. Évaluez la charge du cluster. Sur la page Cluster Monitoring, vérifiez que la capacité est suffisante pour la migration des shards :

   • Utilisation du CPU des nœuds : inférieure à 80 %

   • Utilisation de la mémoire Heap des nœuds : environ 50 %

   • NodeLoad_1m : inférieur au nombre de cœurs CPU

Procédure

Une fois les vérifications de santé effectuées avec succès, redémarrez le cluster :

1. Connectez-vous à la console Alibaba Cloud Elasticsearch. Dans le volet de navigation de gauche, cliquez sur Elasticsearch Clusters.

2. Dans la barre de navigation supérieure, sélectionnez la région. Cliquez sur l'ID de l'instance cible, puis cliquez sur Restart dans le coin supérieur droit de la page Basic Information.

   

3. Dans la boîte de dialogue Restart, configurez les paramètres suivants :

   

   • Object

     • Cluster : redémarre tous les nœuds du cluster. Adapté aux modifications au niveau du cluster.

     • Node Restart : redémarre un ou plusieurs nœuds spécifiés. Adapté pour résoudre les problèmes affectant des nœuds individuels.

     • Node Role (pour l'architecture basic control v2 uniquement) : redémarre les nœuds d'un rôle spécifique que vous sélectionnez, tels que les nœuds de données ou les nœuds Kibana.

   • Blue-green Update et Restart Mode

     Sélectionnez une méthode de redémarrage en fonction de votre scénario, de l'état du cluster et de votre tolérance au risque :

     Méthode de redémarrage	État requis du cluster	Mécanisme et scénario	Impact	Limitations
     Blue-green Update	Normal (vert)	Provisionne de nouveaux nœuds, migre les données depuis les anciens nœuds, puis supprime les anciens nœuds. À utiliser lorsqu'un nœud présente une utilisation CPU élevée persistante et que la disponibilité est plus importante que la vitesse. Important Une mise à jour blue-green ne peut pas être utilisée conjointement avec un redémarrage forcé.	Les adresses IP des nœuds changent. Les performances peuvent fluctuer brièvement.	Non pris en charge pour les spécifications de cluster 1 vCPU 2 Go
     Restart (Standard)	Normal (vert)	Maintenance planifiée et configuration régulière du cluster.	Les adresses IP des nœuds restent inchangées. L'opération prend plus de temps. Le service reste disponible grâce aux réplicas, mais peut connaître de brèves fluctuations.
     Phased Restart	Normal (vert)	Vérifie les effets du redémarrage par lots pour réduire les risques en production. Sélectionnez les nœuds pour le premier lot. Une fois le cluster stabilisé, déclenchez manuellement le redémarrage des nœuds restants.	Les adresses IP des nœuds restent inchangées. Minimise l'impact sur la production.	Disponible uniquement pour les clusters utilisant l'architecture cloud-native control (v3)
     Forced Restart	Anormal (jaune/rouge)	À utiliser lorsque le cluster est jaune ou rouge. Les autres méthodes de redémarrage sont désactivées dans cet état.	Les adresses IP des nœuds restent inchangées. Un niveau de concurrence élevé accélère le redémarrage, mais augmente les risques : Une concurrence de 100 % redémarre tous les nœuds simultanément, ce qui entraîne une interruption de service et une perte potentielle des données mises en cache non persistées. N'utilisez une concurrence élevée que pour une récupération urgente. Concurrence : pourcentage de nœuds redémarrés simultanément. La valeur par défaut est de 10 %, avec un minimum d'un nœud. Affiché uniquement en mode de redémarrage forcé.

4. (Facultatif) Pour un redémarrage forcé, sélectionnez Restart Cluster Forcibly.

5. Cliquez sur OK.

   L'état du cluster passe à Initializing. L'état revient à Normal une fois l'opération terminée.

Vérification après le redémarrage

Vérifiez l'état de santé du cluster et surveillez la récupération des shards après le redémarrage :

1. Vérifiez l'état de santé du cluster :

   GET _cluster/health

2. Surveillez les nœuds et la récupération des shards :

   GET _cat/nodes
   GET _cat/recovery

3. Attendez que tous les shards soient alloués avant de reprendre les opérations.

FAQ

• Durée du redémarrage du cluster et des nœuds

• Accès au réseau public et redémarrage du cluster

• Modification du mot de passe et redémarrage du cluster

• Impact de l'absence de réplicas d'index sur le redémarrage du cluster

• Redémarrer un rôle de nœud ou un seul nœud