¿Por qué se ha reiniciado mi clúster de Amazon Redshift fuera del periodo de mantenimiento?

Descripción corta

Un clúster de Amazon Redshift se reinicia fuera del periodo de mantenimiento por los siguientes motivos:

• Amazon Redshift ha detectado un problema con el clúster.
• Amazon Redshift ha sustituido un nodo defectuoso en el clúster.

Para recibir notificaciones sobre los reinicios de clústeres que se producen fuera del periodo de mantenimiento, cree una suscripción de notificación de eventos. Las notificaciones de eventos también pueden notificarle cuando especifique el clúster como tipo de origen. Para obtener más información, consulte Suscripciones de notificaciones de eventos de clústeres de Amazon Redshift.

Resolución

Amazon Redshift ha detectado un problema con el clúster

Los siguientes problemas pueden iniciar un reinicio del clúster.

Un error de OOM en el nodo principal

Una consulta que se ejecuta en un clúster que se ha actualizado a una versión posterior puede provocar una excepción de falta de memoria (OOM). Para resolver este problema, revierta el parche o el parche fallido.

Un error de OOM que resulta de una versión anterior del controlador

Si está trabajando en una versión anterior del controlador y el clúster se reinicia con frecuencia, descargue la versión más reciente del controlador Java Database Connectivity (JDBC). Se recomienda probar la versión del controlador en el entorno de desarrollo antes de usarla en el de producción.

Errores en las consultas de comprobación de estado

Amazon Redshift supervisa constantemente la disponibilidad de sus componentes. Cuando se produce un error en una comprobación de estado, Amazon Redshift desencadena un reinicio para restablecer el buen estado del clúster lo antes posible para reducir el tiempo de inactividad.

La mayoría de los errores de comprobación de estado más comunes se producen cuando el clúster tiene transacciones abiertas de larga duración. Cuando Amazon Redshift limpia la memoria asociada a transacciones de larga duración, el clúster puede bloquearse. Para evitar este problema, se recomienda supervisar las conexiones y transacciones no cerradas.

Para supervisar las conexiones abiertas de larga duración, ejecute la siguiente consulta de ejemplo:

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;

Para supervisar las transacciones abiertas de larga duración, ejecute la siguiente consulta de ejemplo:

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;

A continuación, ejecute la siguiente consulta para revisar las transacciones abiertas:

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

Para terminar las sesiones inactivas y liberar las conexiones, utilice el comando PG_TERMINATE_BACKEND.

Amazon Redshift ha sustituido un nodo defectuoso en el clúster

Cada nodo de Amazon Redshift se ejecuta en una instancia independiente de Amazon Elastic Compute Cloud (Amazon EC2). Un error en un nodo corresponde a una instancia que no responde a las señales de latido durante el proceso de supervisión. Las señales de latido supervisan periódicamente la disponibilidad de los nodos de computación en su clúster de Amazon Redshift.

Cuando Amazon Redshift detecta problemas o fallos de hardware, sustituye automáticamente los nodos durante el siguiente periodo de mantenimiento. Sin embargo, a veces Amazon Redshift sustituye inmediatamente los nodos defectuosos para que el clúster pueda seguir funcionando correctamente.

Los siguientes problemas pueden provocar que Amazon Redshift sustituya los nodos del clúster:

• La instancia de EC2 no responde porque hay un problema subyacente con el hardware de la instancia o porque se produce un error en la comprobación de estado automatizada.
• Hay un problema con el disco que está en el nodo.
• Un error de comunicación de red intermitente o un problema con un host subyacente pueden provocar un error de comunicación entre los nodos.
• Se agota el tiempo de espera para la detección de un nodo o clúster.
• Un nodo sobrecargado provoca problemas de OOM.