Amazon Redshift 클러스터가 유지 관리 기간이 아닌데 재부팅되는 이유는 무엇입니까?

4분 분량

내 Amazon Redshift 클러스터가 유지 관리 기간이 아닌데 다시 시작되었습니다. 클러스터가 재부팅된 이유는 무엇입니까?

간략한 설명

Amazon Redshift 클러스터는 다음과 같은 이유로 유지 관리 기간이 아닌데도 다시 시작됩니다.

Amazon Redshift 클러스터에 문제가 감지되었습니다.
클러스터의 결함이 있는 노드가 교체되었습니다.

유지 관리 기간 외에 클러스터 재부팅에 대한 알림을 받으려면 Amazon Redshift 클러스터에 대한 이벤트 알림을 생성합니다.

해결 방법

Amazon Redshift 클러스터 문제가 감지되었습니다.

다음은 클러스터 재부팅을 트리거할 수 있는 몇 가지 일반적인 문제입니다.

리더 노드에서 OOM(메모리 부족) 오류: 새 버전으로 업그레이드된 클러스터에서 실행되는 쿼리가 OOM 예외를 야기하여 클러스터 재부팅을 시작할 수 있습니다. 이 문제를 해결하려면 패치 또는 실패한 패치를 롤백하는 것이 좋습니다.
이전 드라이버 버전으로 인한 OOM 오류: 이전 드라이버 버전에서 작업 중이고 클러스터가 자주 재부팅되는 경우 최신 JDBC 드라이버 버전을 다운로드합니다. 프로덕션 환경에서 사용하기 전에 개발 환경에서 드라이버 버전을 테스트하는 것이 좋습니다.
상태 확인 쿼리 실패: 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가 하드웨어 문제나 장애를 감지하면 다음 유지 관리 기간에 노드가 자동으로 교체됩니다. 경우에 따라 클러스터가 제대로 작동하도록 결함이 있는 노드를 즉시 교체해야 합니다.

클러스터 노드 장애의 일반적인 원인은 다음과 같습니다.

EC2 인스턴스 장애: EC2 인스턴스의 기본 하드웨어에 결함이 있는 것으로 확인되면 결함이 있는 노드가 교체되어 클러스터 성능을 복원합니다. EC2는 응답이 부족하거나 자동화된 상태 확인을 통과하지 못하는 경우 기본 하드웨어에 결함이 있는 것으로 태그를 지정합니다.
노드의 디스크 드라이브에 결함이 있어 노드 교체: 노드의 디스크에 문제가 감지되면 Amazon Redshift가 디스크를 교체하거나 노드를 다시 시작합니다. Amazon Redshift 클러스터가 복구되지 않으면 노드가 교체되거나 교체되도록 예약됩니다.
노드 간 통신 장애: 노드 간에 통신 오류가 있는 경우 지정된 시간에 특정 노드에서 제어 메시지를 수신하지 않습니다. 노드 간 통신 장애는 간헐적인 네트워크 연결 문제 또는 기본 호스트 문제로 인해 발생합니다.
검색 시간 초과: 지정된 시간 내에 노드 또는 클러스터에 연결할 수 없는 경우 자동 노드 교체가 트리거됩니다.
OOM (메모리 부족) 예외: 미립자 노드의 부하가 높으면 OOM 문제가 발생하여 노드 교체가 트리거될 수 있습니다.

Amazon Redshift 이벤트 알림 생성

클러스터 재부팅의 원인을 파악하려면 클러스터 재부팅을 모니터링하는 Amazon Redshift 이벤트 알림을 생성합니다. 또한 이벤트 알림은 소스가 구성되었는지 여부를 알려줍니다.