Pourquoi mon cluster Amazon Redshift a-t-il redémarré en dehors de la fenêtre de maintenance ?

Lecture de 5 minute(s)
0

Mon cluster Amazon Redshift a redémarré en dehors de la fenêtre de maintenance. Pourquoi mon cluster a-t-il redémarré ?

Brève description

Un cluster Amazon Redshift est redémarré en dehors de la fenêtre de maintenance pour les raisons suivantes :

  • Un problème lié à votre cluster Amazon Redshift a été détecté.
  • Un nœud défectueux dans le cluster a été remplacé.

Pour être informé des redémarrages de cluster en dehors de votre fenêtre de maintenance, créez une notification d'événement pour votre cluster Amazon Redshift.

Résolution

Un problème lié à votre cluster Amazon Redshift a été détecté

Voici quelques problèmes courants qui peuvent déclencher un redémarrage du cluster :

  • Erreur de manque de mémoire (OOM) sur le nœud principal : une requête qui est exécutée sur un cluster qui est mis à niveau vers une version plus récente peut provoquer une exception OOM, déclenchant un redémarrage du cluster. Pour résoudre ce problème, restaurez votre correctif ou le correctif ayant échoué.
  • Erreur OOM résultant d'une ancienne version de pilote : si vous travaillez sur une ancienne version de pilote et que votre cluster subit fréquemment des redémarrages, téléchargez la dernière version du pilote JDBC. Il est recommandé de tester la version du pilote dans votre environnement de développement avant de l'utiliser en production.
  • Échec des requêtes de surveillance d'état : Amazon Redshift surveille en permanence la disponibilité de ses composants. En cas d'échec d'une surveillance d'état, Amazon Redshift lance un redémarrage pour que le cluster soit dans un état sain dès que possible. Cela permet de réduire le nombre de temps d'arrêt.

Éviter les échecs des requêtes de surveillance d'état

Les échecs de surveillance d'état les plus courants surviennent lorsque le cluster comporte des transactions ouvertes de longue durée. Lorsqu'Amazon Redshift nettoie la mémoire associée à des transactions de longue durée, le cluster peut être bloqué. Pour éviter de telles situations, il est recommandé de surveiller les transactions non clôturées à l'aide des requêtes suivantes.

Pour les connexions ouvertes de longue durée, exécutez l'exemple de requête suivant :

select s.process as process_id,
       c.remotehost || ':' || c.remoteport as remote_address,
       s.user_name as username,
       s.db_name,
       s.starttime as session_start_time,
       i.starttime as start_query_time,
       datediff(s,i.starttime,getdate())%86400/3600||' hrs '|| 
datediff(s,i.starttime,getdate())%3600/60||' mins ' || 
datediff(s,i.starttime,getdate())%60||' secs 'as running_query_time,
       i.text as query
from stv_sessions s
left join pg_user u on u.usename = s.user_name
left join stl_connection_log c
          on c.pid = s.process
          and c.event = 'authenticated'
left join stv_inflight i
          on u.usesysid = i.userid
          and s.process = i.pid
where username <> 'rdsdb'
order by session_start_time desc;

Pour les transactions ouvertes de longue durée, exécutez l'exemple de requête suivant :

select *,datediff(s,txn_start,getdate())/86400||' days '||datediff(s,txn_start,getdate())%86400/3600||' hrs '||datediff(s,txn_start,getdate())%3600/60||' mins '||datediff(s,txn_start,getdate())%60||' secs' from svv_transactions
where lockable_object_type='transactionid' and pid<>pg_backend_pid() order by 3;

Lorsque vous disposez de ces informations, vous pouvez consulter les transactions encore ouvertes en exécutant la requête suivante :

select * from svl_statementtext where xid = <xid> order by starttime, sequence)

Pour mettre fin aux sessions inactives et libérer les connexions, utilisez la commande PG_TERMINATE_BACKEND.

Un nœud défectueux dans le cluster Amazon Redshift a été remplacé

Chaque nœud Amazon Redshift s'exécute sur une instance Amazon Elastic Compute Cloud (Amazon EC2) distincte. Un nœud défaillant est une instance qui ne répond pas aux signaux de pulsation envoyés au cours du processus de surveillance. Les signaux de pulsation surveillent régulièrement la disponibilité des nœuds de calcul dans votre cluster Amazon Redshift.

Ces vérifications d'état automatiques tentent de récupérer le cluster Amazon Redshift lorsqu'un problème est détecté. Lorsqu'Amazon Redshift détecte des problèmes matériels ou des échecs, les nœuds sont automatiquement remplacés dans la fenêtre de maintenance suivante. Notez que, dans certains cas, les nœuds défectueux doivent être immédiatement remplacés pour garantir le bon fonctionnement de votre cluster.

Voici quelques causes courantes de l'échec des nœuds d'un cluster :

  • Échec de l'instance EC2 : lorsque le matériel sous-jacent d'une instance EC2 est détecté comme étant défectueux, le nœud défectueux est remplacé pour restaurer les performances du cluster. EC2 marque, à l'aide d'une balise, le matériel sous-jacent comme étant défectueux en cas d'absence de réponse ou d'échec des surveillances d'état automatiques.
  • Remplacement de nœud en raison d'un disque défectueux d'un nœud : lorsqu'un problème est détecté sur le disque d'un nœud, Amazon Redshift remplace le disque ou redémarre le nœud. Si le cluster Amazon Redshift ne parvient pas à rétablir la situation, le nœud est remplacé ou doit être remplacé.
  • Échec de communication entre les nœuds : en cas d'échec de communication entre les nœuds, les messages de contrôle ne sont pas reçus par un nœud donné à l'heure spécifiée. Les échecs de communication entre les nœuds sont provoqués par un problème de connexion réseau intermittent ou un problème lié à l'hôte sous-jacent.
  • Délai d'expiration de découverte : un remplacement automatique du nœud est déclenché si un nœud ou un cluster ne peut pas être atteint dans le délai spécifié.
  • Exception de manque de mémoire (OOM) : une charge importante sur un nœud peut provoquer des problèmes OOM, déclenchant le remplacement d'un nœud.

Création de notifications d'événement Amazon Redshift

Pour identifier la cause du redémarrage de votre cluster, créez une notification d'événement Amazon Redshift aux redémarrages de cluster. Les notifications d'événement vous indiquent également si la source a été configurée.


Informations connexes

Catégories d'événements et messages d'événements Amazon Redshift

Gestion des notifications d'événements à l'aide de la console Amazon Redshift

Gestion des notifications d'événements à l'aide de l'interface de ligne de commande (CLI) et de l'API Amazon Redshift

AWS OFFICIEL
AWS OFFICIELA mis à jour il y a un an