계정 객체 장애 조치(Failing Over Account Objects)

Business Critical 기능

이 기능은 Business Critical Edition(이상)이 필요해요. 업그레이드 문의는 Snowflake Support에 연락해 주세요.

이 주제는 재해 복구를 위해 서로 다른 리전의 여러 계정 간에 복제된 계정 객체를 장애 조치하는 데 필요한 단계를 설명해요.

장애 조치 메커니즘의 목적과 사용 시점에 대한 내용은 비즈니스 연속성·재해 복구 소개를 참고해요.

출처: Snowflake 문서

본문

전제 조건

같은 조직 내 계정 집합에서 한 클라우드 서비스 제공자의 여러 리전에 걸쳐 또는 서로 다른 클라우드 서비스 제공자 간에 복제를 활성화해요.
복제할 객체 종류를 정의하고 복제할 대상 계정을 지정하는 기본 장애 조치 그룹을 만들어요. 일부 데이터베이스가 다른 것보다 더 자주 복제되어야 하는 경우처럼, 복제된 객체를 여러 장애 조치 그룹으로 나눌 수 있어요.
하나 이상의 보조 계정에서 각 기본 장애 조치 그룹의 보조 장애 조치 그룹(복제본)을 하나 이상 만들어요.
장애 조치 그룹의 객체에 대한 최신 업데이트로 각 복제본을 새로고침(동기화)해요. 초기 새로고침을 수행하고, 최신 변경을 각 보조 계정에 정기적으로 가져오도록 일정을 설정해요.

지침은 계정 객체와 데이터베이스 복제를 참고해요.

대상 계정을 소스 계정으로 승격

Snowsight 또는 SQL을 사용해 대상 계정을 소스 계정으로 승격(장애 조치)할 수 있어요.

장애 조치 그룹에 지정할 수 있는 객체 종류에 대한 자세한 내용은 복제 그룹과 장애 조치 그룹을 참고해요.

Snowsight로 대상 계정을 소스 계정으로 승격

참고(Note): Snowsight로 복제 또는 장애 조치 그룹을 편집할 수 있는 사람은 계정 관리자뿐이에요(Snowsight를 복제 구성에 사용할 때의 제한 참고).

가장 일관되고 신뢰할 수 있는 장애 조치 경험을 위해, 해당되는 모든 장애 조치 그룹과 연결을 선택해 모두 동시에 승격해요. 이 작업을 *벌크 장애 조치(bulk failover)*라고 해요.

Snowsight로 대상 계정을 소스 계정으로 승격하려면 다음 단계를 따라요.

Snowsight에 로그인해요. 대상 계정으로 로그인해야 합니다.
내비게이션 메뉴에서 Admin » Accounts를 선택해요.
Replication을 선택한 다음 Initiate failover를 선택해요. 그러면 나머지 선택을 하는 대화상자가 열려요.
승격할 장애 조치 그룹을 선택해요. 장애 조치 후 해당 장애 조치 그룹에 지정된 객체는 새로 승격된 기본 계정에서 쓰기 가능해져요. 이전에 기본이었다가 이제 보조 계정이 된 계정에서는 그 객체들이 읽기 전용이 돼요.
Next를 선택해요.
승격할 연결을 선택해요. 장애 조치 후 해당 연결은 새 기본 계정으로 승격 중인 계정에 연결돼요.
Next를 선택해요.
확인 창에서 Fail over를 선택해요.
선택한 장애 조치 그룹에 대해 진행 중인 새로고침 작업이 있으면 그 새로고침이 완료될 때까지 기다리거나, 장애 조치가 긴급해서 우선시해야 한다면 다른 접근 방식을 선택할 수 있어요.

기본 동작은 새로고침이 완료될 때까지 기다리는 것이에요. 이렇게 하면 벌크 장애 조치가 실행될 때 기본·보조 시스템이 모두 일관된 상태에 있게 돼요. Snowflake는 현재 선택한 웨어하우스로 진행 중인 새로고침 상태를 폴링해요. 선택한 웨어하우스가 없으면 지금 Select warehouse 옵션으로 하나를 선택해요.

또는 Show advanced options를 선택해 즉시 장애 조치를 진행할 수 있어요.

현재 새로고침 중이 아닌 장애 조치 그룹만 장애 조치하려면 Exit with current progress를 선택해요. 그 경우 벌크 장애 조치 중 건너뛴 그룹에 대해서는 나중에 추가 새로고침을 수행해요.
새로고침 작업을 취소하고 장애 조치를 계속하려면 Cancel refreshes and force failover를 선택해요. 그 경우 중단된 새로고침으로 인한 보조 시스템의 불일치를 정리해야 할 수도 있어요.

장애 조치 작업이 모든 장애 조치 그룹에 대해 완료되지 않았으면 다른 벌크 장애 조치를 수행할 수 있어요. 또는 Snowsight로 단일 장애 조치 그룹을 기본으로 승격의 절차를 사용해 남은 장애 조치 그룹을 하나씩 장애 조치할 수 있어요.

Snowsight로 단일 장애 조치 그룹을 기본으로 승격

참고(Note): Snowsight로 복제 또는 장애 조치 그룹을 편집할 수 있는 사람은 계정 관리자뿐이에요(Snowsight를 복제 구성에 사용할 때의 제한 참고).

Snowsight로 단일 장애 조치 그룹을 기본으로 승격하려면 다음 단계를 따라요.

Snowsight에 로그인해요. 대상 계정으로 로그인해야 합니다.
내비게이션 메뉴에서 Admin » Accounts를 선택해요.
Replication을 선택한 다음 Groups를 선택해요.
승격하려는 장애 조치 그룹을 찾아 행의 마지막 열에 있는 More 메뉴(…)를 선택해요.
Fail over를 선택한 다음 확인 창에서 Fail over를 선택해요.

팁(Tip): 이 절차는 한 그룹을 장애 조치하는 데 문제가 발생해 해당 그룹에 대해서만 장애 조치를 재시도해야 할 때 주로 사용해요. 전체 계정을 기본으로 승격하려면 여러 장애 조치 그룹과 연결을 선택해 벌크 장애 조치를 수행해요. 자세한 내용은 Snowsight로 대상 계정을 소스 계정으로 승격을 참고해요.

SQL로 대상 계정을 소스 계정으로 승격

SQL로 대상 계정을 소스 계정으로 승격하려면 대상 계정에 로그인해 ALTER FAILOVER GROUP … PRIMARY 명령을 실행해요.

보조 장애 조치 그룹을 기본 장애 조치 그룹으로 승격

참고(Note): 이 섹션의 예시는 FAILOVER 권한이 있는 역할이 실행해야 해요.

다음 예시는 현재 myorg 조직의 myaccount2를 소스 계정으로 승격해요.

대상 계정 myaccount2에 로그인해요.
계정의 장애 조치 그룹을 나열해요.

SHOW FAILOVER GROUPS;

기본 장애 조치 그룹으로 승격하려는 각 보조 장애 조치 그룹에 대해 다음 문장을 실행해요.

ALTER FAILOVER GROUP myfg PRIMARY;

참고(Note): 소스 리전에서 부분 중단이 발생하는 동안 복제 서비스가 계속 사용 가능하고 대상 리전의 보조 장애 조치 그룹을 계속 새로고침할 수 있어요.

데이터 무결성을 보장하기 위해 Snowflake는 새로고침 작업이 진행 중이면 장애 조치를 방지해요. 즉, 복제 작업이 새로고침 중인 보조 장애 조치 그룹은 기본으로 승격할 수 없어요. 이 시나리오에서 ALTER FAILOVER GROUP … PRIMARY 명령은 오류를 반환해요.

진행 중인 새로고침 작업으로 인한 장애 조치 문장 실패 해결

승격하려는 보조 장애 조치 그룹에 진행 중인 새로고침 작업이 있으면 장애 조치 문장에서 다음 오류가 발생해요.

Replication group "<GROUP_NAME>" cannot currently be set as primary because it is being
refreshed. Either wait for the refresh to finish or cancel the refresh and try again.

성공적으로 장애 조치하려면 다음 단계를 완료해야 해요.

다음 옵션 중 하나를 선택하고 완료해요.

중요(Important): SECONDARY_DOWNLOADING_METADATA 또는 SECONDARY_DOWNLOADING_DATA 단계에서 새로고침 작업을 일시 중단하면 대상 계정에 불일치 상태가 발생할 수 있어요. 자세한 내용은 진행 중인 새로고침 작업의 현재 단계 보기를 참고해요.

장애 조치 그룹의 향후 새로고침 작업을 일시 중단해요. 진행 중인 새로고침 작업이 있으면 장애 조치를 하기 전에 완료될 때까지 기다려야 해요.

ALTER FAILOVER GROUP myfg SUSPEND;

향후 새로고침 작업을 일시 중단 하고 현재 진행 중인 예약 새로고침 작업(있는 경우)도 취소해요.

진행 중인 새로고침 작업이 수동으로 트리거된 경우 자동 예약되지 않은 진행 중인 새로고침 작업 취소를 참고해요.

ALTER FAILOVER GROUP myfg SUSPEND IMMEDIATE;

참고(Note): 문장이 반환된 시점과 새로고침 작업 취소가 완료된 시점 사이에 약간의 지연이 있을 수 있어요.

장애 조치 그룹 myfg에 진행 중인 새로고침 작업이 없는지 확인해요. 다음 쿼리는 결과가 없어야 해요.

SELECT phase_name, start_time, job_uuid
  FROM TABLE(INFORMATION_SCHEMA.REPLICATION_GROUP_REFRESH_HISTORY('myfg'))
  WHERE phase_name <> 'COMPLETED' and phase_name <> 'CANCELED';

장애 조치 그룹 myfg의 취소된 새로고침 작업을 보려면 다음 문장을 실행할 수 있어요.

SELECT phase_name, start_time, job_uuid
  FROM TABLE(INFORMATION_SCHEMA.REPLICATION_GROUP_REFRESH_HISTORY('myfg'))
  WHERE phase_name = 'CANCELED';

이제 보조 장애 조치 그룹 myfg를 기본 장애 조치 그룹으로 승격할 수 있어요.

ALTER FAILOVER GROUP myfg PRIMARY;

대상 계정에서 예약 복제 재개

장애 조치 시 모든 보조 장애 조치 그룹의 예약 새로고침이 일시 중단돼요. 보조 장애 조치 그룹이 있는 각 대상 계정에서 ALTER FAILOVER GROUP … RESUME을 실행해 자동 새로고침을 재개해야 해요.

ALTER FAILOVER GROUP myfg RESUME;

진행 중인 새로고침 작업의 현재 단계 보기

새로고침 작업은 대부분의 단계에서 안전하게 취소할 수 있어요. 하지만 SECONDARY_DOWNLOADING_METADATA 또는 SECONDARY_DOWNLOADING_DATA 단계에서 새로고침 작업을 취소하면 대상 계정에 불일치 상태가 발생할 수 있어요. 새로고침 작업이 이 단계 중 하나를 시작하면 소스 계정의 가용성과 무관하게 완료까지 진행돼요. 장애 조치 전에 단계가 완료되도록 두면 복제본이 일관된 상태에 있게 보장돼요. 복제본이 일관된 상태에 도달한 후에는 인제스트·변환 파이프라인을 재개하거나 재생해 복제본을 현재 상태로 업데이트할 수 있어요.

장애 조치 그룹의 진행 중인 새로고침 작업의 현재 단계를 보려면 Information Schema REPLICATION_GROUP_REFRESH_PROGRESS, REPLICATION_GROUP_REFRESH_PROGRESS_BY_JOB, REPLICATION_GROUP_REFRESH_PROGRESS_ALL 테이블 함수를 사용해요.

예를 들어 장애 조치 그룹 myfg의 진행 중인 새로고침 작업의 현재 단계를 보려면 다음 문장을 실행해요.

SELECT phase_name, start_time, end_time
  FROM TABLE(
    INFORMATION_SCHEMA.REPLICATION_GROUP_REFRESH_PROGRESS('myfg')
  );

새로고침 작업 단계 목록은 함수의 사용 참고 사항을 참고해요.

자동 예약되지 않은 진행 중인 새로고침 작업 취소

복제 일정에 의해 자동으로 트리거되지 않은 진행 중인 새로고침 작업을 취소하려면 SYSTEM$CANCEL_QUERY 함수를 사용해야 해요.

다음 옵션 중 하나를 사용해 실행 중인 새로고침 작업의 쿼리 ID 또는 JOB_UUID를 찾아요.
- 모든 실행 중인 새로고침 작업의 쿼리 ID 찾기:

SELECT query_id, query_text
  FROM TABLE(INFORMATION_SCHEMA.QUERY_HISTORY())
  WHERE query_type = 'REFRESH REPLICATION GROUP'
  AND execution_status = 'RUNNING'
  ORDER BY start_time;

QUERY_TEXT 열을 사용해 목록에서 장애 조치 그룹 새로고침 작업의 QUERY_ID를 식별해요.

특정 장애 조치 그룹 myfg의 진행 중인 새로고침 작업에 대한 JOB_UUID 찾기:

SELECT phase_name, start_time, job_uuid
  FROM TABLE(INFORMATION_SCHEMA.REPLICATION_GROUP_REFRESH_HISTORY('myfg'))
  WHERE phase_name <> 'COMPLETED' and phase_name <> 'CANCELED';

SYSTEM$CANCEL_QUERY 함수와 QUERY_ID 또는 JOB_UUID를 사용해 새로고침 작업을 취소해요.

SELECT SYSTEM$CANCEL_QUERY('<QUERY_ID | JOB_UUID>');

다음 출력을 반환해요.

query [<QUERY_ID>] terminated.

진행 중인 새로고침 작업을 취소한 후 다음 단계로 계속해요.

새로 승격된 소스 계정에서 Snowpipe Streaming 활성 채널 다시 열기

Snowpipe Streaming이 채우는 기본 데이터베이스의 테이블은 보조 데이터베이스로 복제돼요. 장애 조치 후 테이블에 대한 활성 Snowpipe Streaming 채널을 다시 열고 채널에 대해 누락된 데이터 행을 다시 삽입해요.

openChannel API를 호출해 테이블의 활성 채널을 다시 열어요.
오프셋 토큰을 가져와요.
- getLatestCommittedOffsetToken API를 호출하거나
- SHOW CHANNELS 명령을 실행해 테이블의 활성 채널 목록을 검색해요.
가져온 오프셋 토큰부터 채널의 데이터 행을 다시 삽입해요.

참고(Note): 이 단계는 Snowflake Ingest SDK가 있는 Snowpipe Streaming에만 적용돼요. Kafka 커넥터가 있는 Snowpipe Streaming에는 적용되지 않아요. 장애 조치 후 Kafka 커넥터를 다시 시작하려면 아래 단계를 따라요.

Snowpipe Streaming과 Kafka 커넥터

Kafka 커넥터와 Snowpipe Streaming을 사용 중이라면 장애 조치 후 다음 단계를 따라요.

Kafka 커넥터 구성을 새로 승격된 소스 계정을 가리키도록 업데이트해요.
SHOW CHANNELS 명령을 실행해 활성 채널과 오프셋 토큰 목록을 검색해요. 각 채널은 Kafka 토픽의 단일 파티션에 속해요.
Kafka Topic에서 각 파티션(채널)에 대해 오프셋을 수동으로 재설정해요.
Kafka 커넥터를 다시 시작해요.

자세한 내용은 다음을 참고해요.

더 알아보기 (Learn more)

계정 복제 소개 — 복제·장애 조치 개념
복제 구성 — 복제·장애 조치 그룹 설정
복제 모니터링 — 복제 상태 모니터링