Amazon Redshift 클러스터가 유지 관리 기간 외에 재부팅된 이유는 무엇입니까?

간략한 설명

Amazon Redshift 클러스터가 유지 관리 기간 외에 다시 시작되는 이유는 다음과 같습니다.

• Amazon Redshift가 클러스터에서 문제를 감지했습니다.
• Amazon Redshift가 클러스터에서 결함이 있는 노드를 교체했습니다.

유지 관리 기간 외에 발생하는 클러스터 재부팅에 대한 알림을 받으려면 이벤트 알림 구독을 생성하십시오. 이벤트 알림은 소스 유형으로 클러스터를 지정하는 경우에도 알림을 보낼 수 있습니다. 자세한 내용은 Amazon Redshift 클러스터 이벤트 알림 구독을 참조하십시오.

해결 방법

Amazon Redshift가 클러스터에서 문제 감지

다음과 같은 문제로 인해 클러스터 재부팅이 시작될 수 있습니다.

리더 노드의 OOM 오류

최신 버전으로 업그레이드한 클러스터에서 실행되는 쿼리는 OOM(Out-Of-Memory, 메모리 부족) 예외를 초래할 수 있습니다. 이 문제를 해결하려면 패치 또는 실패한 패치를 롤백하십시오.

이전 드라이버 버전에서 발생한 OOM 오류

이전 버전의 드라이버를 사용 중이고 클러스터가 자주 재부팅되는 경우 최신 JDBC(Java Database Connectivity, Java 데이터베이스 연결) 드라이버 버전을 다운로드하십시오. 프로덕션에 사용하기 전에 개발 환경에서 드라이버 버전을 테스트하는 것이 가장 좋습니다.

**상태 확인 쿼리 실패 **

Amazon Redshift는 구성 요소의 가용성을 지속적으로 모니터링합니다. 상태 확인에 실패하면 Amazon Redshift는 가능한 한 빨리 클러스터를 정상 상태로 되돌려 가동 중지 시간을 줄이기 위해 재시작을 수행합니다.

대부분의 상태 확인 실패는 클러스터에 장기 실행 중인 열린 트랜잭션이 있을 때 발생합니다. Amazon Redshift가 장기 실행 중인 트랜잭션과 관련된 메모리를 정리할 때 클러스터가 잠길 수 있습니다. 이 문제를 방지하려면 닫히지 않은 연결과 트랜잭션을 모니터링하는 것이 가장 좋습니다.

장기 실행 중인 공개 연결을 모니터링하려면 다음 예제 쿼리를 실행합니다.

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;

장기 실행 중인 열린 트랜잭션을 모니터링하려면 다음 예제 쿼리를 실행합니다.

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;

그 후 다음 쿼리를 실행하여 열린 트랜잭션을 검토합니다.

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

유휴 세션을 종료하고 연결을 해제하려면 PG_TERMINATE_BACKEND 명령을 사용합니다.

Amazon Redshift가 클러스터에서 결함이 있는 노드 교체

각 Amazon Redshift 노드는 별도의 Amazon Elastic Compute Cloud(Amazon EC2) 인스턴스에서 실행됩니다. 장애가 발생한 노드는 모니터링 프로세스 중에 하트비트 신호에 응답하지 않는 인스턴스입니다. 하트비트 신호는 Amazon Redshift 클러스터의 컴퓨팅 노드 가용성을 주기적으로 모니터링합니다.

Amazon Redshift가 하드웨어 문제 또는 장애를 감지하면 다음 유지 관리 기간에 자동으로 노드를 교체합니다. 그러나 때때로 Amazon Redshift는 결함이 있는 노드를 즉시 교체하여 클러스터가 계속 올바르게 작동할 수 있도록 합니다.

다음과 같은 문제로 인해 Amazon Redshift가 클러스터 노드를 대체할 수 있습니다.

• 인스턴스의 하드웨어에 근본적인 문제가 있거나 자동 상태 확인이 실패했기 때문에 EC2 인스턴스가 응답하지 않습니다.
• 노드에 있는 디스크에 문제가 있습니다.
• 간헐적인 네트워크 통신 장애 또는 기본 호스트 문제로 인해 노드 간 통신 장애가 발생할 수 있습니다.
• 노드 또는 클러스터 검색 시간이 초과되었습니다.
• 과부하된 노드로 인해 OOM 문제가 발생합니다.