Por que meu cluster do Amazon Redshift foi reinicializado fora da janela de manutenção?

Breve descrição

Um cluster do Amazon Redshift é reiniciado fora da janela de manutenção pelos seguintes motivos:

• O Amazon Redshift detectou um problema com seu cluster.
• O Amazon Redshift substituiu um nó com falha no cluster.

Para receber notificações sobre reinicializações do cluster que ocorrem fora da janela de manutenção, crie uma assinatura de notificação de eventos. As notificações de eventos também podem notificar quando você especifica o cluster como o tipo de origem. Para mais informações, consulte Assinaturas de notificação de eventos de cluster do Amazon Redshift.

Resolução

O Amazon Redshift detectou um problema com seu cluster

Os problemas a seguir podem iniciar uma reinicialização do cluster.

Um erro OOM no nó principal

Uma consulta executada em um cluster que você atualizou para uma versão posterior pode causar uma exceção de falta de memória (OOM). Para resolver esse problema, reverta o patch ou o patch que falhou.

Um erro OOM que resulta de uma versão anterior do driver

Se você estiver trabalhando em uma versão anterior do driver e seu cluster estiver passando por reinicializações frequentes, baixe a versão mais recente do driver Java Database Connectivity (JDBC). É uma prática recomendada testar a versão do driver em seu ambiente de desenvolvimento antes de usá-la na produção.

Falhas na consulta de verificação de integridade

O Amazon Redshift monitora constantemente a disponibilidade dos seus componentes. Quando uma verificação de integridade falha, o Amazon Redshift inicia uma reinicialização para colocar o cluster em um estado íntegro o mais rápido possível para diminuir o tempo de inatividade.

A maioria das falhas na verificação de integridade ocorre quando o cluster tem transações abertas de longa duração. Quando o Amazon Redshift está limpando a memória associada a transações de longa duração, o cluster pode travar. Para evitar esse problema, é uma prática recomendada monitorar conexões e transações não fechadas.

Para monitorar conexões abertas de longa duração, execute o seguinte exemplo de consulta:

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 monitorar transações abertas de longa duração, execute o seguinte exemplo de consulta:

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;

Em seguida, execute a consulta a seguir para revisar as transações abertas:

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

Para encerrar sessões ociosas e liberar as conexões, use o comando PG_TERMINATE_BACKEND.

O Amazon Redshift substituiu um nó com falha no cluster

Cada nó do Amazon Redshift é executado em uma instância separada do Amazon Elastic Compute Cloud (Amazon EC2). Um nó com falha é uma instância que não responde a nenhum sinal de pulsação durante o processo de monitoramento. Os sinais de pulsação monitoram periodicamente a disponibilidade dos nós de computação no seu cluster do Amazon Redshift.

Quando o Amazon Redshift detecta problemas ou falhas de hardware, ele substitui automaticamente os nós durante a próxima janela de manutenção. No entanto, às vezes, ele substitui imediatamente os nós defeituosos para que seu cluster possa continuar funcionando corretamente.

Os seguintes problemas podem fazer com que o Amazon Redshift substitua os nós do cluster:

• A instância do EC2 não responde porque há um problema subjacente com o hardware da instância ou ocorre uma falha na verificação automática de integridade.
• Há um problema com o disco que está no nó.
• Uma falha intermitente na comunicação de rede ou um problema com um host subjacente pode causar uma falha na comunicação entre os nós.
• A descoberta de um nó ou cluster atinge o tempo limite.
• Um nó sobrecarregado causa problemas de OOM.