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

Brève description

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

• Amazon Redshift a détecté un problème avec votre cluster.
• Amazon Redshift a remplacé un nœud défectueux dans le cluster.

Pour être averti des redémarrages du cluster en dehors de votre fenêtre de maintenance, créez un abonnement aux notifications d'événements. Les notifications d'événements peuvent également vous avertir lorsque vous spécifiez le cluster comme type de source. Pour plus d'informations, consultez la section Abonnements aux notifications d'événements de cluster Amazon Redshift.

Résolution

Amazon Redshift a détecté un problème avec votre cluster

Les problèmes suivants peuvent provoquer le redémarrage d'un cluster.

Une erreur OOM sur le nœud principal

Une requête exécutée sur un cluster que vous avez mis à niveau vers une version ultérieure peut provoquer une exception de mémoire insuffisante (OOM). Pour résoudre ce problème, restaurez votre correctif ou le correctif qui a échoué.

Une erreur OOM résultant d'une version antérieure du pilote

Si vous travaillez sur une version antérieure du pilote et que votre cluster est fréquemment redémarré, téléchargez la dernière version du pilote Java Database Connectivity (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 vérification de l'état

Amazon Redshift surveille en permanence la disponibilité de ses composants. Lorsqu'une vérification de l’état échoue, Amazon Redshift lance un redémarrage pour remettre le cluster en bon état le plus rapidement possible afin de réduire les temps d'arrêt.

La plupart des échecs de vérification de l'état se produisent lorsque le cluster inclut des transactions ouvertes de longue date. Lorsqu'Amazon Redshift nettoie la mémoire associée à des transactions de longue durée, le cluster peut se verrouiller. Pour éviter ce problème, il est recommandé de surveiller les connexions et les transactions non fermées.

Pour surveiller 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 surveiller les transactions ouvertes de longue date, 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;

Exécutez ensuite la requête suivante pour vérifier les transactions en cours :

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.

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

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 d’impulsion pendant le processus de surveillance. Les signaux Heartbeat surveillent régulièrement la disponibilité des nœuds de calcul de votre cluster Amazon Redshift.

Lorsqu'Amazon Redshift détecte des problèmes ou des pannes matérielles, il remplace automatiquement les nœuds lors de la fenêtre de maintenance suivante. Cependant, Amazon Redshift remplace parfois immédiatement les nœuds défectueux afin que votre cluster puisse continuer à fonctionner correctement.

Les problèmes suivants peuvent entraîner le remplacement des nœuds de cluster par Amazon Redshift :

• L'instance EC2 ne répond pas en raison d'un problème sous-jacent lié au matériel de l'instance ou parce que la vérification de l’état automatique échoue.
• Un problème est survenu avec le disque qui se trouve sur le nœud.
• Un échec de communication réseau intermittente ou un problème avec un hôte sous-jacent peut provoquer un échec de communication entre les nœuds.
• La découverte d'un nœud ou d'un cluster expire.
• Un nœud surchargé entraîne des problèmes de mémoire insuffisante (OOM).