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

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

For information about the purpose of the failover mechanism and when to use it, see 비즈니스 연속성 및 재해 복구 소개.

Prerequisites¶

Enable replication in a set of accounts within the same organization, across multiple regions in one cloud service provider or across different cloud service providers.
Create a primary failover group that defines the kinds of objects to replicate, and specifies the target accounts to which to replicate. You can optionally divide the replicated objects across multiple failover groups, for example if some databases should be replicated more frequently than others.
Create at least one secondary failover group (replica) of each primary failover group in one or more secondary accounts.
Refresh (synchronize) each replica with the latest updates to the objects in the failover group. Perform an initial refresh, and set up a schedule to regularly bring the latest changes to each secondary account.

For instructions, see 계정 오브젝트 및 데이터베이스 복제하기.

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

Snowsight 또는 SQL 을 사용하여 대상 계정을 소스 계정으로 승격(장애 조치)할 수 있습니다.

For more information about the kinds of objects you can specify in a failover group, see 복제 그룹 및 장애 조치 그룹.

Promote a target account to serve as the source account using Snowsight¶

참고

Only account administrators can edit a replication or failover group using Snowsight (see 복제 구성에 Snowsight 사용 시 제한 사항).

For the most consistent and reliable failover experience, select all the applicable failover groups and connections and promote them all at the same time. We refer to this operation as a bulk failover.

To promote a target account to serve as the source account using Snowsight, follow these steps:

Sign in to Snowsight. Make sure to sign in using the target account.
탐색 메뉴에서 Admin » Accounts 를 선택합니다.
Select Replication, then select Initiate failover. Doing so brings up a dialog where you make the remaining choices.
Select any failover groups to promote. After the failover, the objects specified in those failover groups become writable on the newly promoted primary account. Those objects become read-only on the account that formerly was the primary and is now a secondary account.
Select Next.
Select any connections to promote. After the failover, those connections connect to the account that you’re promoting to be the new primary account.
Select Next.
Select Fail over in the confirmation window.
If any refresh operations are in progress for the failover groups you selected, you can wait for those refreshes to complete, or choose an alternative approach if your failover is urgent and should take priority.

The default action is to wait for the refreshes to complete. That way, the primary and secondary systems are all in a consistent state when the bulk failover runs. Snowflake uses your currently selected warehouse to poll the status of the ongoing refreshes. If you don’t have a selected warehouse, you select one now using the Select warehouse option.

Or, you can proceed with the failover immediately by selecting Show advanced options.
- To fail over only the failover groups that aren’t currently being refreshed, select Exit with current progress. In that case, you perform additional refreshes later for the groups that were skipped during the bulk failover.
- To cancel the refresh operations and continue the failover, select Cancel refreshes and force failover. In that case, you might need to clean up any inconsistencies on the secondary system from the interrupted refreshes.

If the failover operation didn’t complete for all failover groups, you can perform another bulk failover. Or you can fail over the remaining failover groups one at a time, using the procedure in Promote a single failover group to serve as the primary using Snowsight.

Promote a single failover group to serve as the primary using Snowsight¶

참고

Only account administrators can edit a replication or failover group using Snowsight (see 복제 구성에 Snowsight 사용 시 제한 사항).

To promote a single failover group to be the primary using Snowsight, follow these steps:

Sign in to Snowsight. Make sure to sign in using the target account.
탐색 메뉴에서 Admin » Accounts 를 선택합니다.
Replication 를 선택한 다음 Groups 을 선택합니다.
승격하려는 장애 조치 그룹의 위치를 찾고 행의 마지막 열에서 More 메뉴(…)를 선택합니다.
Fail over 를 선택한 다음 확인 창에서 Fail over 를 선택합니다.

팁

You typically use this procedure if you encounter a problem failing over one group, and you need to retry the failover only for that group. To promote an entire account to be the primary, select multiple failover groups and connections and perform a bulk failover. For more information, see Promote a target account to serve as the source account using Snowsight.

SQL 을 사용하여 대상 계정을 소스 계정으로 승격합니다.¶

To promote a target account to serve as the source account using SQL, you sign in to the target account and execute the ALTER FAILOVER GROUP … PRIMARY command.

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

참고

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

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

대상 계정 myaccount2 에 로그인합니다.
계정의 장애 조치 그룹을 나열합니다.
```
SHOW FAILOVER GROUPS;
```
Copy
기본 장애 조치 그룹으로 승격시킬 각 보조 장애 조치 그룹에 대해 다음 명령문을 실행합니다.
```
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.

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

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

중요

SECONDARY_DOWNLOADING_METADATA 또는 SECONDARY_DOWNLOADING_DATA 단계에서 새로 고침 작업을 일시 중단하면 대상 계정의 상태가 일관적이지 않을 수 있습니다. 자세한 내용은 진행 중인 새로 고침 작업의 현재 단계 보기 섹션을 참조하십시오.
1. 장애 조치 그룹에 대한 향후 새로 고침 작업을 일시 중단합니다. 진행 중인 새로 고침 작업이 있는 경우 장애 조치를 수행하기 전에 작업이 완료될 때까지 기다려야 합니다.
  ALTER FAILOVER GROUP myfg SUSPEND;
  Copy
2. 향후 새로 고침 작업을 일시 중단하고 그리고 현재 진행 중인 예약된 새로 고침 작업(있는 경우)을 취소합니다.
  
  진행 중인 새로 고침 작업이 수동으로 트리거된 경우 자동으로 예약되지 않은 진행 중인 새로 고침 작업 취소 섹션을 참조하십시오.
  ALTER FAILOVER GROUP myfg SUSPEND IMMEDIATE;
  Copy
  참고
  
  문이 반환되는 시간과 새로 고침 작업 취소가 완료되는 시간 사이에 약간의 지연이 발생할 수 있습니다.

장애 조치 그룹 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

이제 보조 장애 조치 그룹 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, REPLICATION_GROUP_REFRESH_PROGRESS_ALL 테이블 함수를 사용합니다.

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

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

Copy

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

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

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

다음 옵션 중 하나를 사용하여 새로 고침 작업을 실행하기 위한 쿼리 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
SYSTEM$CANCEL_QUERY 함수 및 QUERY_ID 또는 JOB_UUID를 사용하여 새로 고침 작업을 취소합니다.
```
SELECT SYSTEM$CANCEL_QUERY('<QUERY_ID | JOB_UUID>');
```
Copy
반환되는 출력은 다음과 같습니다.
```
query [<QUERY_ID>] terminated.
```
진행 중인 새로 고침 작업을 취소한 후 다음 단계 를 계속 진행합니다.

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

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

openChannel API를 호출하여 테이블의 활성 채널을 다시 엽니다.
오프셋 토큰 가져오기:
1. getLatestCommittedOffsetToken API를 호출합니다. 또는
2. SHOW CHANNELS 명령을 실행하여 테이블의 활성 채널 목록을 불러옵니다.
가져온 오프셋 토큰에서 채널에 대한 데이터 행을 다시 삽입합니다.

참고

이 단계는 Snowflake Ingest SDK 를 통한 Snowpipe Streaming에만 적용되며, Kafka 커넥터를 통한 Snowpipe Streaming에는 적용되지 않습니다. 아래 단계 에 따라 장애 조치 후 Kafka Connector를 다시 시작합니다.

Snowpipe Streaming 및 Kafka Connector¶

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

새로 승격된 원본 계정을 가리키도록 Kafka 커넥터 구성을 업데이트합니다.
SHOW CHANNELS 명령을 실행하여 활성 채널 및 오프셋 토큰의 목록을 불러옵니다. 각 채널은 Kafka 항목의 단일 파티션에 속합니다.
각 파티션(채널)에 대해 Kafka 항목에서 오프셋을 수동으로 재설정합니다.
Kafka Connector를 다시 시작합니다.

For more information, see: