계정 오브젝트 장애 조치하기

이 항목에서는 재해 복구를 위해 서로 다른 리전 의 여러 계정에서 복제된 계정 오브젝트를 장애 조치하는 데 필요한 단계에 대해 설명합니다.

전제 조건 요구 사항

  1. 계정 세트에서 기본 장애 조치 그룹에 대한 복제를 활성화합니다.

  2. 하나 이상의 계정에 기본 장애 조치 그룹의 보조 장애 조치 그룹(즉, 복제본)을 하나 이상 생성하고 장애 조치 그룹의 오브젝트에 대한 최신 업데이트로 복제본을 정기적으로 새로 고칩니다(즉, 동기화).

자세한 지침은 여러 계정에 걸쳐 데이터베이스 및 계정 오브젝트 복제하기 섹션을 참조하십시오.

원본 계정으로 사용할 대상 계정 승격하기

대상 계정을 소스 계정으로 승격하려면 새 소스 계정으로 승격할 대상 계정에 로그인한 후 ALTER FAILOVER GROUP … PRIMARY 명령을 실행해야 합니다.

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

참고

이 섹션의 예제는 FAILOVER 권한이 있는 역할이 실행해야 합니다.

다음 예제에서는 현재 myorg 조직의 myaccount2 를 원본 계정으로 사용하도록 승격합니다.

  1. 대상 계정 myaccount2 에 로그인합니다.

  2. 계정의 장애 조치 그룹을 나열합니다.

    SHOW FAILOVER GROUPS;
    Copy

  3. 기본 장애 조치 그룹으로 승격시킬 각 보조 장애 조치 그룹에 대해 다음 명령문을 실행합니다.

    ALTER FAILOVER GROUP myfg PRIMARY;
    Copy

    참고

    소스 리전에서 부분 장애가 발생하는 동안에도 복제 서비스는 계속 사용할 수 있으며, 대상 리전에서 보조 장애 조치 그룹을 계속 새로 고칠 수 있습니다.

    데이터 무결성을 보장하기 위해 새로 고침 작업이 진행 중일 경우 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.

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

  1. 다음 옵션 중 하나를 선택하여 완료합니다.

    중요

    SECONDARY_DOWNLOADING_METADATA 또는 SECONDARY_DOWNLOADING_DATA 단계에서 새로 고침 작업을 일시 중단하면 대상 계정의 상태가 일관적이지 않을 수 있습니다. 자세한 내용은 진행 중인 새로 고침 작업의 현재 단계 보기 섹션을 참조하십시오.

    1. 장애 조치 그룹에 대한 향후 새로 고침 작업을 일시 중단합니다. 진행 중인 새로 고침 작업이 있는 경우 장애 조치를 수행하기 전에 작업이 완료될 때까지 기다려야 합니다.

      ALTER FAILOVER GROUP myfg SUSPEND;
      Copy

    2. 향후 새로 고침 작업을 일시 중단하고 그리고 현재 진행 중인 예약된 새로 고침 작업(있는 경우)을 취소합니다.

      진행 중인 새로 고침 작업이 수동으로 트리거된 경우 자동으로 예약되지 않은 진행 중인 새로 고침 작업 취소 섹션을 참조하십시오.

      ALTER FAILOVER GROUP myfg SUSPEND IMMEDIATE;
      Copy

      참고

      문이 반환되는 시간과 새로 고침 작업 취소가 완료되는 시간 사이에 약간의 지연이 발생할 수 있습니다.

  2. 장애 조치 그룹 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';
    Copy

    장애 조치 그룹 myfg 에 대해 취소된 새로 고침 작업을 확인하려면 다음 문을 실행하면 됩니다.

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

  3. 이제 보조 장애 조치 그룹 myfg 를 기본 장애 조치 그룹으로 승격할 수 있습니다.

    ALTER FAILOVER GROUP myfg PRIMARY;
    Copy

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

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

ALTER FAILOVER GROUP myfg RESUME;
Copy

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

새로 고침 작업은 대부분의 단계에서 안전하게 취소할 수 있습니다. 그러나 SECONDARY_DOWNLOADING_METADATA 또는 SECONDARY_DOWNLOADING_DATA 단계에서 새로 고침 작업을 취소하면 대상 계정의 상태가 일관적이지 않을 수 있습니다. 새로 고침 작업이 이러한 단계 중 하나를 시작한 경우 소스 계정의 사용 가능 여부에 관계없이 완료 단계로 진행됩니다. 장애 조치 전에 단계가 완료되도록 하면 복제본이 일관적인 상태를 유지할 수 있습니다. 복제본이 일관적인 상태가 되면 수집 및 변환 파이프라인을 재개하거나 재생하여 복제본을 현재 상태로 업데이트할 수 있습니다.

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

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

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

새로 고침 작업 단계 목록은 해당 함수의 사용법 노트 를 참조하십시오.

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

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

  1. 다음 옵션 중 하나를 사용하여 새로 고침 작업을 실행하기 위한 쿼리 ID 또는 JOB_UUID를 찾습니다.

    1. 실행 중인 모든 새로 고침 작업에 대한 쿼리 IDs를 찾습니다.

      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;
      Copy

      QUERY_TEXT 열을 사용하여 목록에서 장애 조치 그룹 새로 고침 작업을 위한 QUERY_ID를 식별합니다.

    2. 특정 장애 조치 그룹 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';
      Copy

  2. SYSTEM$CANCEL_QUERY 함수 및 QUERY_ID 또는 JOB_UUID를 사용하여 새로 고침 작업을 취소합니다.

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

    반환되는 출력은 다음과 같습니다.

    query [<QUERY_ID>] terminated.

  3. 진행 중인 새로 고침 작업을 취소한 후 다음 단계 를 계속 진행합니다.

새로 승격된 원본 계정에서 Snowpipe Streaming을 위한 활성 채널 다시 열기

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

  1. openChannel API를 호출하여 테이블의 활성 채널을 다시 엽니다.

  2. 오프셋 토큰 가져오기:

    1. getLatestCommittedOffsetToken API를 호출합니다. 또는

    2. SHOW CHANNELS 명령을 실행하여 테이블의 활성 채널 목록을 불러옵니다.

  3. 가져온 오프셋 토큰에서 채널에 대한 데이터 행을 다시 삽입합니다.

Snowpipe Streaming 및 Kafka Connector

Kafka Connector와 Snowpipe Streaming을 사용하는 경우 장애 조치 후 다음 단계를 따르십시오.

  1. 새로 승격된 원본 계정을 가리키도록 Kafka 커넥터 구성을 업데이트합니다.

  2. SHOW CHANNELS 명령을 실행하여 활성 채널 및 오프셋 토큰의 목록을 불러옵니다. 각 채널은 Kafka 항목의 단일 파티션에 속합니다.

  3. 각 파티션(채널)에 대해 Kafka 항목에서 오프셋을 수동으로 재설정합니다.

  4. Kafka Connector를 다시 시작합니다.

자세한 내용은 다음을 참조하십시오.

언어: 한국어