여러 계정 간 데이터베이스 및 계정 객체 복제

여러 계정 간 데이터베이스 및 계정 객체 복제 (Replicating databases and account objects across multiple accounts)

이 토픽은 같은 조직 안의 Snowflake 계정 간에 계정 객체와 데이터를 복제하고 객체와 데이터를 동기화 상태로 유지하는 데 필요한 절차를 설명해요. 계정 복제는 서로 다른 리전(region) 과 클라우드 플랫폼(cloud platform) 사이의 Snowflake 계정 간에도 발생할 수 있어요.

출처: Snowflake 문서 - Replicating databases and account objects across multiple accounts

본문

Standard 및 Business Critical 기능

데이터베이스와 공유 복제는 모든 계정에서 사용할 수 있어요.
그 외 계정 객체의 복제와 장애 조치/복구(failover/failback)에는 Business Critical Edition 이상이 필요해요.
업그레이드 문의는 Snowflake Support에 연락해요.

참고: 계정을 Business Critical Edition(이상)으로 업그레이드하면 장애 조치 기능을 사용할 수 있게 되기까지 최대 12시간이 걸릴 수 있어요.

복제와 장애 조치/복구를 위한 리전 지원

고객은 리전 그룹(Region Group) 안의 모든 리전 간에 복제할 수 있어요. 서로 다른 리전 그룹 에 속한 리전 간에 복제하려면(예: Snowflake 상용 리전에서 정부 리전으로) Snowflake Support에 연락해 접근을 활성화해야 해요.

데이터베이스 복제에서 그룹 기반 복제로 전환

ALTER DATABASE 를 사용해 복제가 활성화된 데이터베이스는 복제/장애 조치 그룹에 추가하기 전에 복제를 비활성화 해야 해요.

참고: 이 섹션의 SQL 문은 ACCOUNTADMIN 역할로 실행해요.

1단계: 복제가 활성화된 데이터베이스의 복제 비활성화

SYSTEM$DISABLE_DATABASE_REPLICATION 함수를 실행해 기본 데이터베이스와 그에 연결된 보조 데이터베이스의 복제를 비활성화하면 복제/장애 조치 그룹에 추가할 수 있어요.

기본 데이터베이스가 있는 소스 계정에서 다음 SQL 문을 실행해요.

SELECT SYSTEM$DISABLE_DATABASE_REPLICATION('mydb');

2단계: 데이터베이스를 기본 장애 조치 그룹에 추가하고 보조 장애 조치 그룹 생성

데이터베이스의 복제를 성공적으로 비활성화하면 기본 데이터베이스를 소스 계정의 장애 조치 그룹에 추가할 수 있어요.

그런 다음 타깃 계정에 보조 장애 조치 그룹을 만들어요. 타깃 계정에서 보조 장애 조치 그룹을 새로고침하면 이전에 보조였던 데이터베이스가 자동으로 보조 장애 조치 그룹의 멤버로 추가되고 기본 데이터베이스의 변경 사항으로 새로고침돼요.

기본 및 보조 장애 조치 그룹 생성에 대한 자세한 내용은 워크플로우 를 참고해요.

참고: 이전에 복제된 데이터베이스를 복제/장애 조치 그룹에 추가하면 Snowflake는 해당 데이터베이스에 대해 이미 복제된 데이터를 다시 복제하지 않아요. 그룹을 새로고침할 때 마지막 새로고침 이후의 변경 사항만 복제돼요.

워크플로우

다음 SQL 문은 계정 및 데이터베이스 객체 복제를 활성화하고 객체를 새로고침하는 워크플로우를 보여줘요. 각 단계는 아래에서 자세히 설명해요.

참고: 다음 예제는 소스 계정과 타깃 계정에 복제가 활성화되어 있어야 해요. 자세한 내용은 사전 요구 사항: 조직의 계정에 복제 활성화 를 참고해요.

예제

선호하는 Snowflake 클라이언트에서 다음 SQL 문을 실행해 계정 및 데이터베이스 객체 복제와 장애 조치를 활성화하고 객체를 새로고침해요.

소스 계정에서 실행

역할을 만들고 CREATE FAILOVER GROUP 권한을 부여해요. 이 단계는 선택 사항 이에요.

USE ROLE ACCOUNTADMIN;
CREATE ROLE myrole;
GRANT CREATE FAILOVER GROUP ON ACCOUNT TO ROLE myrole;

소스 계정에 장애 조치 그룹을 만들고 특정 타깃 계정으로의 복제를 활성화해요.
- 참고: ALTER DATABASE를 사용해 데이터베이스 복제 및 장애 조치가 이전에 활성화된 데이터베이스를 그룹에 추가하려면 먼저(이 토픽의) 데이터베이스 복제에서 그룹 기반 복제로 전환 지침을 따르세요.
- 참고: 장애 조치 그룹에 데이터베이스를 추가하려면 활성 역할이 데이터베이스에 대한 MONITOR 권한을 가져야 해요. 데이터베이스 권한에 대한 자세한 내용은 데이터베이스 권한을 참고해요.

USE ROLE myrole;
CREATE FAILOVER GROUP myfg
  OBJECT_TYPES = USERS, ROLES, WAREHOUSES, RESOURCE MONITORS, DATABASES
  ALLOWED_DATABASES = db1, db2
  ALLOWED_ACCOUNTS = myorg.myaccount2, myorg.myaccount3
  REPLICATION_SCHEDULE = '10 MINUTE';

타깃 계정에서 실행

타깃 계정에 역할을 만들고 CREATE FAILOVER GROUP 권한을 부여해요. 이 단계는 선택 사항 이에요.

USE ROLE ACCOUNTADMIN;
CREATE ROLE myrole;
GRANT CREATE FAILOVER GROUP ON ACCOUNT TO ROLE myrole;

소스 계정의 장애 조치 그룹 복제본으로 타깃 계정에 장애 조치 그룹을 만들어요.
- 참고: 소스 계정에 없는 계정 객체(예: 사용자 또는 역할)가 타깃 계정에 존재하면 보조 그룹을 만들기 전에 사용자 및 역할의 초기 복제 를 참고해요.

USE ROLE myrole;
CREATE FAILOVER GROUP myfg AS REPLICA OF myorg.myaccount1.myfg;

보조 장애 조치 그룹을 수동으로 새로고침해요. 이 단계는 선택 사항 이에요. 기본 장애 조치 그룹이 복제 일정과 함께 생성되면 보조 장애 조치 그룹 생성 시 초기 새로고침이 자동으로 실행돼요.
- 장애 조치 그룹에 REPLICATE 권한을 가진 역할을 만들어요. 이 단계는 선택 사항 이에요. 타깃 계정에서 장애 조치 그룹에 대한 OWNERSHIP 권한을 가진 역할로 실행해요.

GRANT REPLICATE ON FAILOVER GROUP myfg TO ROLE my_replication_role;

REPLICATE 권한을 가진 역할로 새로고침 문을 실행해요.

USE ROLE my_replication_role;
ALTER FAILOVER GROUP myfg REFRESH;

장애 조치 그룹에 FAILOVER 권한을 가진 역할을 만들어요. 이 단계는 선택 사항 이에요. 타깃 계정에서 장애 조치 그룹에 대한 OWNERSHIP 권한을 가진 역할로 실행해요.

GRANT FAILOVER ON FAILOVER GROUP myfg TO ROLE my_failover_role;

계정 객체 및 데이터베이스 복제

이 섹션의 지침은 계정을 복제할 준비를 하고, 소스 계정에서 타깃 계정으로 특정 객체의 복제를 활성화하며, 타깃 계정의 객체를 동기화하는 방법을 설명해요.

중요

타깃 계정은 기본적으로 Tri-Secret Secure 또는 AWS PrivateLink와 같은 Snowflake 서비스에 대한 프라이빗 연결이 활성화되어 있지 않아요. 규정 준수, 보안 또는 기타 목적으로 Tri-Secret Secure 또는 Snowflake 서비스에 대한 프라이빗 연결이 필요하다면 타깃 계정에서 해당 기능을 구성하고 활성화하는 것은 사용자 책임이에요.

사전 요구 사항: 조직의 계정에 복제 활성화

조직 관리자(organization administrator)는 소스 및 타깃 계정에 복제를 활성화해야 해요.

계정에 복제를 활성화하기 위해 조직 관리자 는 SYSTEM$GLOBAL_ACCOUNT_SET_PARAMETER 함수를 사용해 ENABLE_ACCOUNT_DATABASE_REPLICATION 파라미터를 true 로 설정해요.

조직 관리자로서 조직의 각 소스 및 타깃 계정에 복제를 활성화해요.

-- 조직의 계정 목록 보기
-- 복제를 활성화하려는 각 계정의 조직 이름과 계정 이름을 기록
SHOW ACCOUNTS;

-- 조직의 각 소스 및 타깃 계정에 대해 이 문을 실행해 복제 활성화
SELECT SYSTEM$GLOBAL_ACCOUNT_SET_PARAMETER
  ('<organization_name>.<account_name>', 'ENABLE_ACCOUNT_DATABASE_REPLICATION', 'true');

SYSTEM$GLOBAL_ACCOUNT_SET_PARAMETER 함수는 레거시 계정 로케이터(account locator) 식별자를 지원하지만, 조직에 동일한 로케이터를 공유하는 계정이 여러 개(서로 다른 리전에) 있으면 예기치 않은 결과가 발생할 수 있어요.

1단계: 소스 계정에서 CREATE FAILOVER GROUP 권한을 가진 역할 생성 — 선택 사항

역할을 만들고 CREATE FAILOVER GROUP 권한을 부여해요. 이 단계는 선택 사항이에요. 이미 이 역할을 만들었다면 3단계: 소스 계정에서 기본 장애 조치 그룹 생성 으로 건너뛰어요.

USE ROLE ACCOUNTADMIN;
CREATE ROLE myrole;
GRANT CREATE FAILOVER GROUP ON ACCOUNT TO ROLE myrole;

2단계: 복제가 활성화된 계정 및 그룹 멤버십 확인

기본 장애 조치 그룹을 만들기 전에 복제가 활성화된 계정과 기존 장애 조치/복제 그룹을 확인해요.

복제가 활성화된 모든 계정 보기

조직에서 복제가 활성화된 계정 목록을 가져오려면 SHOW REPLICATION ACCOUNTS 를 사용해요.

ACCOUNTADMIN 역할로 다음 SQL 문을 실행해요.

SHOW REPLICATION ACCOUNTS;

결과:

+------------------+-------------------------------+--------------+-----------------+-----------------+-------------------+--------------+
| snowflake_region | created_on                    | account_name | account_locator | comment         | organization_name | is_org_admin |
+------------------+-------------------------------+--------------+-----------------+-----------------+-------------------+--------------+
| AWS_US_WEST_2    | 2020-07-15 21:59:25.455 -0800 | myaccount1   | myacctlocator1  |                 | myorg             | true         |
+------------------+-------------------------------+--------------+-----------------+-----------------+-------------------+--------------+
| AWS_US_EAST_1    | 2020-07-23 14:12:23.573 -0800 | myaccount2   | myacctlocator2  |                 | myorg             | false        |
+------------------+-------------------------------+--------------+-----------------+-----------------+-------------------+--------------+
| AWS_US_EAST_2    | 2020-07-25 19:25:04.412 -0800 | myaccount3   | myacctlocator3  |                 | myorg             | false        |
+------------------+-------------------------------+--------------+-----------------+-----------------+-------------------+--------------+

전체 리전 ID 목록을 참고해요.

장애 조치 및 복제 그룹 멤버십 보기

계정, 데이터베이스, 공유 객체에는 그룹 멤버십에 대한 제약 이 있어요. 새 그룹을 만들거나 기존 그룹에 객체를 추가하기 전에 기존 장애 조치 그룹 목록과 각 그룹의 객체를 검토할 수 있어요.

참고: 이 섹션의 SQL 문은 계정 관리자(ACCOUNTADMIN 역할을 가진 사용자) 또는 그룹 소유자(그룹에 대한 OWNERSHIP 권한을 가진 역할)만 실행할 수 있어요.

현재 계정에 연결된 모든 장애 조치 그룹과 각 그룹의 객체 유형을 봐요.

SHOW FAILOVER GROUPS;

장애 조치 그룹 myfg 의 모든 데이터베이스를 봐요.

SHOW DATABASES IN FAILOVER GROUP myfg;

장애 조치 그룹 myfg 의 모든 공유를 봐요.

SHOW SHARES IN FAILOVER GROUP myfg;

3단계: 소스 계정에서 기본 장애 조치 그룹 생성

기본 장애 조치 그룹을 만들고 현재(소스) 계정에서 같은 조직의 한 개 이상의 타깃 계정으로 특정 객체의 복제와 장애 조치를 활성화해요.

복제/장애 조치 그룹은 Snowsight 또는 SQL 을 사용해 만들 수 있어요.

참고: ALTER DATABASE를 사용해 데이터베이스 복제가 이전에 활성화된 데이터베이스를 복제/장애 조치 그룹에 추가하려면 먼저(이 토픽의) 데이터베이스 복제에서 그룹 기반 복제로 전환 지침을 따르세요.

Snowsight로 복제/장애 조치 그룹 생성

참고

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

타깃 계정에 ACCOUNTADMIN 역할을 가진 사용자로 로그인해야 해요. 그렇지 않으면 로그인하라는 메시지가 표시돼요. 소스 계정과 타깃 계정은 동일한 연결 유형(공용 인터넷)을 사용해야 해요. 그렇지 않으면 타깃 계정 로그인이 실패해요.

새 복제/장애 조치 그룹을 만들려면 다음 단계를 완료해요.

Snowsight 에 로그인해요.
탐색 메뉴에서 Admin » Accounts 를 선택해요.
Replication 을 선택한 다음 Groups 탭에서 다음 작업 중 하나를 완료해요.
- Business Critical Edition(이상) 계정의 경우 다음 작업 중 하나를 완료해요.
  - 복제 그룹이나 연결이 없으면 Get started 를 선택해 복제 그룹과 연결을 구성해요. Setup business continuity 마법사가 나타나요.
  - 연결을 구성하지 않고 복제 그룹을 구성하려면 + Group 을 선택해요. Create a group 마법사가 나타나요.
- Standard Edition 및 Enterprise Edition 계정의 경우 다음 작업 중 하나를 완료해요.
  - 복제 그룹이나 연결이 없으면 Get started 를 선택해 복제 그룹을 구성해요. Setup replication 마법사가 나타나요.
  - 복제 그룹이 한 개 이상 존재하면 + Group 을 선택해 복제 그룹을 구성해요. Create a group 마법사가 나타나요.
Select a target account 페이지에서 타깃 계정을 선택하고 로그인한 다음 Next 를 선택해요.
Create a group 페이지의 Group name 상자에 다음 요구 사항을 충족하는 그룹 이름을 입력해요.
- 알파벳 문자로 시작해야 하며, 식별자 문자열이 큰따옴표로 묶여 있지 않으면 공백이나 특수 문자를 포함할 수 없어요(예: “My object”). 큰따옴표로 묶인 식별자는 대소문자를 구분해요. 자세한 내용은 식별자 요구 사항 을 참고해요.
- 계정 내 장애 조치 및 복제 그룹 간에 고유해야 해요.
Edit objects 를 선택해 공유 및 계정 객체를 그룹에 추가해요.
- 참고: 계정 객체는 하나의 복제/장애 조치 그룹에만 추가할 수 있어요. 계정에 계정 객체가 있는 복제/장애 조치 그룹이 이미 존재하면 해당 객체를 선택할 수 없어요.
Select databases 를 선택해 데이터베이스 객체를 그룹에 추가해요.
Replication frequency 를 선택해요.
계정이 Business Critical Edition 이상이면 기본적으로 장애 조치 그룹이 생성돼요. 대신 복제 그룹을 만들려면 Advanced options 를 선택한 다음 Enable failover 를 해제해요.
다음 작업 중 하나를 완료해요.
- Business Critical Edition(이상) 계정의 경우 Next 를 선택해요.
- Standard Edition 및 Enterprise Edition 계정의 경우 Start replication 을 선택해 복제 그룹을 만들어요.
Business Critical Edition(이상) 계정의 경우 Create connection 페이지에서 Connection name 상자에 연결 이름을 입력한 다음 Start replication 을 선택해요.

복제 그룹 생성이 실패하면 Snowsight로 복제 그룹 생성·편집 문제 해결 을 참고해 일반적인 오류와 해결 방법을 확인해요.

SQL로 장애 조치 그룹 생성

지정된 계정 및 데이터베이스 객체의 장애 조치 그룹을 소스 계정에 만들고 타깃 계정 목록으로의 복제 및 장애 조치를 활성화해요. 구문은 CREATE FAILOVER GROUP 을 참고해요.

예를 들어 사용자, 역할, 웨어하우스, 리소스 모니터, 데이터베이스 db1 및 db2 의 복제를 소스 계정에서 같은 조직의 myaccount2 계정으로 활성화해요. 복제 일정을 설정해 myaccount2 를 10분마다 자동으로 새로고침해요.

소스 계정에서 다음 문을 실행해요.

USE ROLE myrole;
CREATE FAILOVER GROUP myfg
    OBJECT_TYPES = USERS, ROLES, WAREHOUSES, RESOURCE MONITORS, DATABASES, INTEGRATIONS, NETWORK POLICIES
    ALLOWED_DATABASES = db1, db2
    ALLOWED_INTEGRATION_TYPES = API INTEGRATIONS
    ALLOWED_ACCOUNTS = myorg.myaccount2
    REPLICATION_SCHEDULE = '10 MINUTE';

4단계: 타깃 계정에서 CREATE FAILOVER GROUP 권한을 가진 역할 생성 — 선택 사항

타깃 계정에 역할을 만들고 CREATE FAILOVER GROUP 권한을 부여해요. 이 단계는 선택 사항이에요. 이미 이 역할을 만들었다면 5단계: 타깃 계정에서 보조 장애 조치 그룹 생성 으로 건너뛰어요.

USE ROLE ACCOUNTADMIN;
CREATE ROLE myrole;
GRANT CREATE FAILOVER GROUP ON ACCOUNT TO ROLE myrole;

5단계: 타깃 계정에서 보조 장애 조치 그룹 생성

참고: 소스 계정에 없는 계정 객체(예: 사용자 또는 역할)가 타깃 계정에 존재하면 보조 그룹을 만들기 전에 사용자 및 역할의 초기 복제 를 참고해요.

소스 계정의 기본 장애 조치 그룹의 복제본으로 타깃 계정에 보조 장애 조치 그룹을 만들어요.

(이 토픽의) 3단계: 소스 계정에서 기본 장애 조치 그룹 생성 에서 복제를 활성화한 각 타깃 계정에서 CREATE FAILOVER GROUP … AS REPLICA OF 문을 실행해요.

각 타깃 계정에서 실행:

USE ROLE myrole;
CREATE FAILOVER GROUP myfg AS REPLICA OF myorg.myaccount1.myfg;

6단계: 타깃 계정에서 보조 장애 조치 그룹을 수동으로 새로고침 — 선택 사항

타깃 계정의 객체를 수동으로 새로고침하려면 ALTER FAILOVER GROUP … REFRESH 명령을 실행해요.

모범 사례로, CREATE FAILOVER GROUP 또는 ALTER FAILOVER GROUP 을 사용해 REPLICATION_SCHEDULE 파라미터를 설정해 보조 새로고침을 예약하는 것을 권장해요.

참고: 타깃 계정에서 함수를 호출한 사용자가 소스 계정에서 삭제되면 새로고침 작업이 실패해요.

장애 조치 그룹에 REPLICATE 권한을 역할에 부여 — 선택 사항

타깃 계정에서 보조 복제/장애 조치 그룹을 새로고침하는 명령을 실행하려면 장애 조치 그룹에 REPLICATE 권한을 가진 역할을 사용해야 해요. REPLICATE 권한은 현재 복제되지 않으며 소스 및 타깃 계정 모두에서 장애 조치(또는 복제) 그룹에 부여해야 해요.

그룹에 대한 OWNERSHIP 권한을 가진 역할로 소스 계정에서 이 문을 실행해요.

GRANT REPLICATE ON FAILOVER GROUP myfg TO ROLE my_replication_role;

그룹에 대한 OWNERSHIP 권한을 가진 역할로 타깃 계정에서 이 문을 실행해요.

GRANT REPLICATE ON FAILOVER GROUP myfg TO ROLE my_replication_role;

보조 장애 조치 그룹 수동 새로고침

예를 들어 장애 조치 그룹 myfg 의 객체를 새로고침하려면 타깃 계정에서 다음 문을 실행해요.

USE ROLE my_replication_role;
ALTER FAILOVER GROUP myfg REFRESH;

7단계: 장애 조치 그룹에 FAILOVER 권한을 역할에 부여 — 선택 사항

타깃 계정에서 보조 장애 조치 그룹을 장애 조치하는 명령을 실행하려면 장애 조치 그룹에 FAILOVER 권한 을 가진 역할을 사용해야 해요. FAILOVER 권한은 현재 복제되지 않으며 각 소스 및 타깃 계정에서 부여해야 해요.

자세한 내용은 역할과 권한 부여의 복제 를 참고해요.

예를 들어 장애 조치 그룹 my_fg 에 대해 역할 my_failover_role 에 FAILOVER 권한을 부여하려면 그룹에 대한 OWNERSHIP 권한을 가진 역할로 타깃 계정 에서 다음 문을 실행해요.

GRANT FAILOVER ON FAILOVER GROUP myfg TO ROLE my_failover_role;

지정된 권한 집합으로 사용자 지정 역할을 만드는 방법은 사용자 지정 역할 만들기 를 참고해요.

보안 가능 객체(securable objects)에서 SQL 작업을 수행하기 위한 역할과 권한 부여에 대한 일반 정보는 접근 제어 개요 를 참고해요.

장애 조치 그룹의 스키마 수준 복제

장애 조치 그룹의 데이터베이스에 대해 데이터베이스 및/또는 데이터베이스의 개별 스키마에 REPLICABLE_WITH_FAILOVER_GROUPS 파라미터를 선택적으로 구성해 복제할 스키마의 부분집합을 지정할 수 있어요.

이 기능을 사용하면 장애 조치 그룹에서 복제할 스키마를 제어할 수 있어요. 데이터베이스의 데이터 일부에만 장애 조치가 제공하는 추가 재해 복구 보호가 필요한 경우 유용해요.

이 파라미터는 모든 데이터베이스와 그 안의 스키마에 기본적으로 활성화되어 있으므로, 복제에서 제외할 데이터베이스 및/또는 스키마를 선택해 복제 세분성(granularity)을 조정할 수 있어요. 포함하는 데이터베이스가 복제되지 않더라도 특정 스키마의 복제를 허용해 복제 설정을 더 세밀하게 조정할 수도 있어요.

복제하거나 건너뛸 스키마 지정

장애 조치 그룹의 데이터베이스에서 복제하거나 건너뛸 스키마를 선택적 REPLICABLE_WITH_FAILOVER_GROUPS 파라미터로 명시적으로 지정할 수 있어요.

REPLICABLE_WITH_FAILOVER_GROUPS 파라미터

REPLICABLE_WITH_FAILOVER_GROUPS 파라미터는 장애 조치 그룹의 데이터베이스에 속하는 스키마가 복제되는지 여부를 지정해요. 이 파라미터는 데이터베이스와 데이터베이스의 모든/일부 스키마에 설정할 수 있어요. 파라미터가 데이터베이스에 설정되면 특정 스키마에 다른 값이 명시적으로 설정되지 않는 한 데이터베이스의 모든 스키마가 그 값을 상속해요.

파라미터는 'YES' 또는 'NO' 두 값을 받으며(대소문자 구분 없음) 선택 사항이에요.

REPLICABLE_WITH_FAILOVER_GROUPS가 데이터베이스에 명시적으로 설정되지 않으면(또는 명시적으로 해제되면) 데이터베이스는 표준 복제 동작을 따르며, 이는 파라미터를 'YES'로 설정한 것과 동일해요.
REPLICABLE_WITH_FAILOVER_GROUPS가 스키마에 명시적으로 설정되지 않으면(또는 명시적으로 해제되면) 복제 동작은 상위 데이터베이스로부터 상속돼요.

ALTER DATABASE <name> SET REPLICABLE_WITH_FAILOVER_GROUPS = {'YES' | 'NO'}

ALTER DATABASE <name> UNSET REPLICABLE_WITH_FAILOVER_GROUPS

ALTER SCHEMA <name> SET REPLICABLE_WITH_FAILOVER_GROUPS = {'YES' | 'NO'}

ALTER SCHEMA <name> UNSET REPLICABLE_WITH_FAILOVER_GROUPS

보안 요구 사항

데이터베이스 또는 스키마에서 이 파라미터를 설정하거나 해제하려면 다음 권한이 필요해요.

REPLICATE(계정 수준 권한). 스키마 수준 복제 기능 이전에는 이 권한이 복제 그룹과 장애 조치 그룹에 대한 객체 수준 권한만 있었어요. ACCOUNTADMIN 역할을 가진 사용자는 이 권한을 다른 역할에 부여할 수 있어요.
USAGE(데이터베이스 및 스키마 권한) 또는 데이터베이스와 스키마에서 작업을 수행할 수 있게 하는 유사한 권한.

예제

기존 역할 replicationadmin 에 필요한 권한을 부여해요.

USE ROLE ACCOUNTADMIN;
GRANT REPLICATE ON ACCOUNT TO ROLE replicationadmin;
GRANT USAGE ON DATABASE db1 TO ROLE replicationadmin;
GRANT USAGE ON SCHEMA db1.sch1 TO ROLE replicationadmin;

db1 데이터베이스에서 스키마 sch1 하나만 복제해요.

USE ROLE replicationadmin;
ALTER DATABASE db1 SET REPLICABLE_WITH_FAILOVER_GROUPS = 'NO';
ALTER SCHEMA sch1 SET REPLICABLE_WITH_FAILOVER_GROUPS = 'YES';

db2 데이터베이스에서 스키마 sch2 하나를 제외한 모든 스키마를 복제해요.

USE ROLE replicationadmin;
ALTER DATABASE db2 SET REPLICABLE_WITH_FAILOVER_GROUPS = 'YES';
ALTER SCHEMA sch2 SET REPLICABLE_WITH_FAILOVER_GROUPS = 'NO';

타깃 계정에서 REPLICABLE_WITH_FAILOVER_GROUPS가 설정된 스키마의 새로고침

데이터베이스 새로고침 중:

REPLICABLE_WITH_FAILOVER_GROUPS가 'YES'로 설정된 스키마는 소스 계정에서 타깃 계정으로 복제돼요.
REPLICABLE_WITH_FAILOVER_GROUPS가 'NO'로 설정된 스키마는 다음 두 시나리오를 제외하고 복제되지 않아요.
- 타깃 스키마가 소스 계정 스키마의 복제본인 경우. 이 경우 타깃 스키마는 항상 소스 스키마와 동기화돼요.
- 타깃 스키마가 소스 계정 스키마와 이름 충돌이 있는 경우. 이 경우 이름 충돌로 인해 복제 작업이 실패해요.

계정에서 REPLICABLE_WITH_FAILOVER_GROUPS가 설정된 데이터베이스 및 스키마 나열

ACCOUNT_USAGE 및 INFORMATION_SCHEMA 뷰를 쿼리해 현재 계정의 REPLICABLE_WITH_FAILOVER_GROUPS 파라미터에 설정된 값을 나열할 수 있어요.

팁: ACCOUNT_USAGE 또는 INFORMATION_SCHEMA 뷰를 사용하는 이유가 익숙하지 않다면 Account Usage와 Information Schema의 차이 를 참고해요.

예제

이 예제에서는 INFORMATION_SCHEMA 뷰를 사용해요. 이렇게 하면 변경 직후 설정을 즉시 확인할 수 있어요.

기존 replicationadmin 역할을 사용해 두 데이터베이스가 있는 계정의 모든 파라미터 값을 반환해요.

db1 데이터베이스는 명시적으로 NO로 설정되고, 데이터베이스의 sch1 스키마는 명시적으로 YES로 설정돼요. 데이터베이스에서 그 스키마 하나만 복제 대상이 돼요.
db2 데이터베이스는 명시적으로 YES로 설정되고, 데이터베이스의 sch2 스키마는 명시적으로 NO로 설정돼요. 그 스키마 하나를 제외한 데이터베이스의 모든 스키마가 복제 대상이 돼요.

USE ROLE replicationadmin;
SELECT database_name, replicable_with_failover_groups
  FROM db1.INFORMATION_SCHEMA.DATABASES;

+---------------+---------------------------------+
| DATABASE_NAME | REPLICABLE_WITH_FAILOVER_GROUPS |
+---------------+---------------------------------+
| DB1           | NO                              |
| DB2           | YES                             |
| DB3           | UNSET                           |
+---------------+---------------------------------+

SELECT schema_name, catalog_name, replicable_with_failover_groups
  FROM db1.INFORMATION_SCHEMA.SCHEMATA
  ORDER BY catalog_name;

+--------------------+--------------+---------------------------------+
| SCHEMA_NAME        | CATALOG_NAME | REPLICABLE_WITH_FAILOVER_GROUPS |
+--------------------+--------------+---------------------------------+
| PUBLIC             | DB1          | NO                              |
| SCH1               | DB1          | YES                             |
| SCH2               | DB1          | NO                              |
| SCH3               | DB1          | NO                              |
| INFORMATION_SCHEMA | DB1          | UNSET                           |
+--------------------+--------------+---------------------------------+

USE ROLE replicationadmin;
SELECT schema_name, catalog_name, replicable_with_failover_groups
  FROM db2.INFORMATION_SCHEMA.SCHEMATA
  ORDER BY catalog_name;

+--------------------+--------------+---------------------------------+
| SCHEMA_NAME        | CATALOG_NAME | REPLICABLE_WITH_FAILOVER_GROUPS |
+--------------------+--------------+---------------------------------+
| PUBLIC             | DB2          | YES                             |
| SCH1               | DB2          | YES                             |
| SCH2               | DB2          | NO                              |
| SCH3               | DB2          | YES                             |
| INFORMATION_SCHEMA | DB2          | UNSET                           |
+--------------------+--------------+---------------------------------+

장애 조치 그룹의 최적화된 새로고침

프리뷰 기능 — 공개

모든 Business Critical Edition(이상) 계정에서 사용할 수 있어요.

최적화된 새로고침(optimized refresh)은 계정의 객체 수가 늘어남에 따라 새로고침을 더 효율적이고 예측 가능하게 만드는 장애 조치 그룹용 새로고침 모드예요. 각 새로고침은 이전 새로고침 이후의 데이터 및 메타데이터 변경 사항만 스캔하고 적용하므로, 새로고침 시간은 장애 조치 그룹 내 객체 수가 아니라 변경 속도(rate of change)에 비례해요.

기존 새로고침 경험은 계속 사용할 수 있으며 이를 Replication Classic 이라고 불러요. 오늘 사용하는 장애 조치 그룹은 기본적으로 Replication Classic으로 계속 실행되어요. 계속 사용하기 위해 별도 조치가 필요하지 않아요.

기본 장애 조치 그룹에 OPTIMIZED_REFRESH = TRUE 속성 하나를 설정해 장애 조치 그룹별로 옵트인해요.

장점

확장에 따라 더 낮고 예측 가능한 RPO. 각 새로고침이 이전 새로고침 이후 변경된 내용만 이동시키므로 새로고침 시간은 계정의 총 객체 수가 아니라 변경 속도에 따라 결정돼요. 데이터베이스, 스키마, 테이블, 역할, 권한 부여가 많은 계정에서 가장 큰 개선을 볼 수 있어요.
안정적인 워크로드에서 더 빠른 새로고침. 메타데이터 변경이 적은 기간은 그에 상응하는 작은 새로고침 주기가 돼요.
더 단순하고 예측 가능한 가격. 최적화된 새로고침에 적용되는 가격 모델은 주로 복제된 데이터의 양에 기반하며, 객체 변경당 차원에 관대한 월별 무료 허용량이 있어요. 자세한 내용은 최적화된 새로고침 가격을 참고해요.
드롭인 호환성. 최적화된 새로고침은 이미 사용하는 것과 동일한 장애 조치 그룹 SQL 표면과 함께 작동해요. 복제, 장애 조치, 복구(장애 복구) 의미론은 변경되지 않아요.

요구 사항

장애 조치 그룹에서 최적화된 새로고침을 활성화하면:

장애 조치 그룹에 REPLICATION_SCHEDULE이 설정되어 있어야 하며, 일정 간격이 6시간 이하여야 해요. 장애 조치 그룹의 가장 최근 성공한 새로고침이 6시간보다 오래되면 다음 새로고침은 전체 새로고침으로 대체되어 증분 새로고침이 재개되기 전에 기준선(baseline)을 다시 설정해요.
OPTIMIZED_REFRESH 속성은 기본 장애 조치 그룹에만 설정할 수 있어요. 보조 장애 조치 그룹에 설정하면 실패해요.
Business Critical Edition(이상)이 필요해요(장애 조치 그룹 기능 자체에서 상속).

팁: 최적화된 새로고침의 최상의 경험을 위해 Snowflake는 REPLICATION_SCHEDULE 을 10 MINUTE 이하로 권장해요. 빈번한 새로고침은 각 증분 주기를 작게 유지해 낮은 RPO와 가장 예측 가능한 새로고침 시간을 제공해요.

새 장애 조치 그룹에서 최적화된 새로고침 활성화

소스 계정에서 실행해요. 이 예제는 최적화된 새로고침을 사용해 데이터베이스 db1 을 10분마다 타깃 계정 myaccount2 로 복제하는 myfg 라는 장애 조치 그룹을 만들어요.

CREATE FAILOVER GROUP myfg
  OBJECT_TYPES = DATABASES
  ALLOWED_DATABASES = db1
  ALLOWED_ACCOUNTS = myorg.myaccount2
  REPLICATION_SCHEDULE = '10 MINUTE'
  OPTIMIZED_REFRESH = TRUE;

타깃 계정에서는 평소처럼 보조 장애 조치 그룹을 만들어요. 보조에 추가 속성은 필요하지 않아요.

CREATE FAILOVER GROUP myfg AS REPLICA OF myorg.myaccount1.myfg;

기존 장애 조치 그룹을 최적화된 새로고침으로 전환

소스 계정에서 실행해요. 기존 장애 조치 그룹에 이미 6시간 요구 사항을 충족하는 REPLICATION_SCHEDULE이 없으면 같은 문에서 설정하거나 조정해요.

ALTER FAILOVER GROUP myfg SET
  REPLICATION_SCHEDULE = '10 MINUTE'
  OPTIMIZED_REFRESH = TRUE;

ALTER가 성공하면 다음 새로고침은 최적화된 새로고침을 처음 활성화할 때 기대할 수 있는 것 에 설명된 첫 새로고침 동작으로 최적화된 새로고침으로 실행돼요.

장애 조치 그룹을 Replication Classic으로 되돌리기

최적화된 새로고침은 완전히 되돌릴 수 있어요. 장애 조치 그룹을 Replication Classic으로 되돌리려면 속성을 해제해요.

ALTER FAILOVER GROUP myfg UNSET OPTIMIZED_REFRESH;

다음 새로고침은 Replication Classic으로 실행되며 기존 복제 가격으로 청구돼요.

현재 모드 확인

SHOW FAILOVER GROUPS 를 사용해 각 그룹이 어떤 모드를 사용하는지 확인해요. 출력에는 is_optimized_refresh_enabled 열이 포함돼요.

SHOW FAILOVER GROUPS;

TRUE 값은 그룹의 후속 새로고침이 최적화된 새로고침을 사용한다는 뜻이고, FALSE 값은 Replication Classic을 사용한다는 뜻이에요.

ACCOUNT_USAGE의 REPLICATION_GROUPS 뷰 를 쿼리해 IS_OPTIMIZED_REFRESH_ENABLED 열을 볼 수도 있어요.

최적화된 새로고침을 처음 활성화할 때 기대할 수 있는 것

기존 장애 조치 그룹에 OPTIMIZED_REFRESH = TRUE 를 설정하거나 속성이 설정된 새 장애 조치 그룹을 만들면, 활성화 후 첫 새로고침은 나중에 Snowflake가 증분 변경을 적용하는 기준선을 설정하는 일회성 부트스트래핑 새로고침이에요.

다음 사항을 계획해요.

부트스트래핑 새로고침은 안정 상태(steady-state) 새로고침보다 오래 걸려요. 그 시간은 같은 장애 조치 그룹의 Replication Classic 새로고침과 비슷해요.
부트스트래핑 새로고침은 최적화된 새로고침 가격 모델로 청구돼요(복제된 데이터 양 + 변경된 객체, 월별 무료 허용량 적용). 자세한 내용은 최적화된 새로고침 가격을 참고해요.
후속 새로고침은 증분적이고 빠르며, 두 번째 새로고침부터는 이전 새로고침 이후의 변경 사항만 타깃 계정으로 전송돼요.

REPLICATION_SCHEDULE이 곧 새로고침을 생성할 장애 조치 그룹에서 최적화된 새로고침을 활성화하면 그 새로고침이 부트스트래핑 새로고침으로 실행돼요. 수동으로 아무것도 트리거할 필요가 없어요.

부트스트래핑 새로고침 후 모든 표준 장애 조치 그룹 작업은 이전과 똑같이 동작해요. 예약 새로고침, 수동 새로고침, 승격(promotion), 장애 조치, 복구(장애 복구)는 변경되지 않아요.

공개 프리뷰 중 제한 사항

드물게 특정 조건(예: 새 기능에 대한 복제 지원을 도입하는 새 Snowflake 릴리스)에서 개별 새로고침이 증분 대신 전체 새로고침으로 실행될 수 있어요. 그 새로고침은 평소보다 오래 걸려요.

같은 계정에서 최적화된 새로고침과 Replication Classic 혼합

OPTIMIZED_REFRESH 설정은 장애 조치 그룹별이에요. 한 계정의 일부 장애 조치 그룹은 최적화된 새로고침을 사용하고 다른 그룹은 Replication Classic을 사용할 수 있어요. 복제, 장애 조치, 복구는 새로고침 모드와 관계없이 장애 조치 그룹에 대해 동일하게 동작해요.

타깃 계정에서 스크립트로 만든 객체에 전역 ID 적용

복제가 아닌 다른 방법(예: 스크립트 사용)으로 타깃 계정에 계정 객체(예: 사용자, 역할)를 만들었다면 이러한 사용자와 역할에는 기본적으로 전역 식별자(global identifier)가 없어요. 새로고침 작업은 전역 식별자를 사용해 이러한 객체를 소스 계정의 동일한 객체와 동기화해요.

대부분의 경우 타깃 계정이 소스 계정에서 새로고침될 때, 새로고침 작업은 타깃 계정의 OBJECT_TYPES 목록에 있는 유형 중 전역 식별자가 없는 계정 객체를 삭제(drop) 해요. 다만 타깃 계정으로의 사용자 및 역할 초기 복제는 첫 새로고침 작업이 실패하게 만들 수 있어요. 이 동작에 대한 자세한 내용은 사용자 및 역할의 초기 복제 를 참고해요.

SYSTEM$LINK_ACCOUNT_OBJECTS_BY_NAME()을 사용해 전역 ID 적용

소스 및 타깃 계정에서 같은 이름의 일치 객체를 연결하면 일부 객체 유형의 손실을 방지할 수 있어요. SYSTEM$LINK_ACCOUNT_OBJECTS_BY_NAME 함수는 타깃 계정의 계정 객체에 전역 식별자를 추가해요.

참고: 전역 식별자는 다음 객체 유형에 대해 복제/장애 조치 그룹에 포함된 계정 객체에만 추가돼요.

RESOURCE_MONITOR

ROLE

USER

WAREHOUSE

장애 조치 그룹 myfg 의 object_types 목록에 포함된 유형의 계정 객체에 타깃 계정에서 전역 식별자를 적용해요.

ACCOUNTADMIN 역할로 다음 SQL 문을 실행해요.

SELECT SYSTEM$LINK_ACCOUNT_OBJECTS_BY_NAME('myfg');

사용자 및 역할의 초기 복제

USERS 및 ROLES 객체 유형의 초기 새로고침 작업 동작은 타깃 계정에 같은 이름의 일치 객체가 있는지 여부에 따라 달라질 수 있어요.

참고

이 섹션에서 설명하는 동작은 이러한 객체 유형이 타깃 계정에 처음 복제될 때만 적용돼요.

아래 시나리오는 USERS의 복제를 설명해요. ROLES의 복제에도 동일하게 적용돼요.

타깃 계정에 소스 계정의 사용자와 같은 이름의 기존 사용자가 있으면 초기 새로고침 작업이 실패하고 계속 진행할 수 있는 두 가지 옵션을 설명해요.
- 새로고침 작업을 강제하고 타깃 계정의 기존 사용자 삭제를 허용해요. 소스 계정의 사용자가 타깃 계정으로 복제돼요. 그룹의 새로고침을 강제하려면 새로고침 명령에 FORCE 파라미터를 사용해요. 예를 들어 장애 조치 그룹의 새로고침을 강제하려면 다음 명령을 실행해요.
```
ALTER FAILOVER GROUP <fg_name> REFRESH FORCE;
```
- 계정 객체를 이름으로 연결해요. SYSTEM$LINK_ACCOUNT_OBJECTS_BY_NAME 함수가 타깃 계정과 소스 계정 양쪽에서 같은 이름의 사용자를 연결해요. 연결된 타깃 계정의 사용자는 삭제되지 않아요. 계정 객체를 이름으로 연결하려면 다음 명령을 실행해요.
```
SELECT SYSTEM$LINK_ACCOUNT_OBJECTS_BY_NAME('<rg_name>');
```
  참고: 소스 계정에 같은 이름의 일치 사용자가 없는 타깃 계정의 사용자는 삭제 돼요.
타깃 계정에 소스 계정의 사용자와 이름이 일치하는 사용자가 없으면 타깃 계정의 초기 새로고침 작업이 모든 사용자를 삭제해요. 이로 인해 다음과 같은 데이터 및 메타데이터 손실이 발생할 수 있어요.
- USERS가 복제/장애 조치 그룹의 OBJECT_TYPES 목록에 포함된 경우:
  - 워크시트가 손실돼요.
  - 쿼리 이력이 손실돼요.
- USERS가 OBJECT_TYPES 목록에 포함되지만 ROLES는 포함되지 않은 경우:
  - 사용자에 대한 권한 부여가 손실돼요.
- ROLES가 OBJECT_TYPES 목록에 포함된 경우:
  - 공유 객체에 대한 권한 부여가 손실돼요.

타깃 계정에서 사용자나 역할이 삭제되는 것을 방지하려면:

소스 계정에서 초기 복제 전에 타깃 계정에만 존재하는 사용자나 역할을 수동으로 다시 만들어요.
타깃 계정에서 SYSTEM$LINK_ACCOUNT_OBJECTS_BY_NAME 함수를 사용해 두 계정에서 같은 이름의 일치 객체를 연결해요.

보조 스토리지 통합을 위한 클라우드 스토리지 접근 구성

스토리지 통합 복제를 활성화하면 스토리지 통합이 타깃 계정으로 복제된 후 추가 단계를 수행해야 해요.

복제된 통합은 기본 통합의 IAM(identity and access management) 엔티티와 다른 자체 IAM 엔티티를 가져요. 따라서 클라우드 프로바이더 권한을 업데이트해 복제된 통합에 클라우드 스토리지에 대한 접근 권한을 부여해야 해요.

이 신뢰 관계는 타깃 계정에서 한 번만 구성하면 돼요.

이 과정은 소스 계정에서 접근 권한을 부여하는 것과 비슷해요. 자세한 내용은 다음 페이지를 참고해요.

Amazon S3에 접근하도록 Snowflake 스토리지 통합 구성
Google Cloud Storage용 통합 구성
Azure용 Snowflake 스토리지 통합 구성

보조 스테이지의 디렉터리 테이블에 대한 자동 새로고침 구성

디렉터리 테이블이 있는 외부 스테이지를 복제하고 소스 디렉터리 테이블에 대해 자동 새로고침을 구성했다면 보조 디렉터리 테이블에 대해 자동 새로고침 을 구성하는 단계를 수행해야 해요.

이 과정은 소스 계정에서 자동 새로고침을 설정하는 것과 비슷해요. 자세한 내용은 다음을 참고해요.

Amazon S3: 구성 과정은 이벤트 알림을 설정한 방식에 따라 달라져요.
- Amazon Simple Queue Service(SQS)와 함께 Amazon S3 Event Notifications를 사용한다면 2단계: 이벤트 알림 구성 의 지침을 따르세요. SQS에서 SNS로 마이그레이션할 수도 있어요. 자세한 내용은 Amazon Simple Notification Service(SNS)로 마이그레이션을 참고하세요.
- Amazon Simple Notification Service(SNS)를 사용한다면 Snowflake SQS 큐를 SNS 토픽에 구독하기를 참고하세요.
Google Cloud Storage: 타깃 계정에서 Pub/Sub 토픽에 대한 새 구독과 새 알림 통합을 만들어요. 그런 다음 Pub/Sub 구독에 Snowflake 접근 권한을 부여해요. 지침은 GCS Pub/Sub를 사용한 자동화 구성 을 참고해요.
Azure Blob Storage: 새 Event Grid 구독과 스토리지 큐를 만들어요. 그런 다음 타깃 계정에 새 알림 통합을 만들고 스토리지 큐에 Snowflake 접근 권한을 부여해요. 지침은 Azure Event Grid로 자동화 구성 을 참고해요.

중요

타깃 계정에서 이러한 구성 단계를 완료한 후에는 디렉터리 테이블의 전체 새로고침을 수행해 알림을 놓치지 않았는지 확인해야 해요.
Google Cloud Storage 및 Azure Blob Storage의 경우 각 타깃 계정의 알림 통합 이름이 소스 계정의 알림 통합 이름과 일치해야 해요.

보조 자동 로드(auto-ingest) 파이프에 대한 알림 구성

장애 조치 전에 보조 자동 로드 파이프에 대한 클라우드 알림을 구성하는 추가 단계를 수행해야 해요. 이 섹션은 이 추가 구성이 필요한 이유와 각 지원 클라우드 프로바이더별로 구성하는 방법을 다뤄요.

Amazon S3

구성 과정은 이벤트 알림을 설정한 방식에 따라 달라져요. 예를 들어 Snowflake 스테이지 위치에 대한 메시지를 게시하기 위해 Amazon Simple Notification Service(SNS) 토픽에 의존하는 자동 로드 파이프가 있다고 가정해요.

파이프를 타깃 계정으로 복제하면 Snowflake가 자동으로 새 Amazon Simple Queue Service(SQS) 큐를 만들어요. 이 SQS 큐를 타깃 계정용으로 SNS 토픽에 구독해 스테이지 위치에 대한 알림을 받아야 해요.

Amazon Simple Queue Service(SQS)와 함께 Amazon S3 Event Notifications를 사용한다면 4단계: 이벤트 알림 구성 의 지침을 따르세요.
- 중요: 파이프가 알림을 놓치지 않았는지 확인하기 위해 새 SQS 큐로 전환한 후 파이프를 새로고침해야 해요. SQS에서 SNS로 마이그레이션할 수도 있어요. 자세한 내용은 Amazon Simple Notification Service(SNS)로 마이그레이션을 참고하세요.
Amazon Simple Notification Service(SNS)를 사용한다면 Snowflake SQS 큐를 SNS 토픽에 구독하기 를 참고해요.
Amazon EventBridge를 사용한다면 옵션 3: Snowpipe를 자동화하도록 Amazon EventBridge 설정 을 참고해요.

Microsoft Azure Blob Storage

Microsoft Azure blob storage의 스테이지에 있는 파일에서 데이터를 자동으로 로드하는 파이프에는 Event Grid 구독, 스토리지 큐, 스토리지 큐에 바인딩된 알림 통합이 필요해요. 타깃 계정의 보조 파이프에는 별도의 Event Grid, 스토리지 큐, 스토리지 큐에 바인딩된 알림 통합이 필요해요. 소스 계정과 타깃 계정의 Event Grid는 모두 동일한 Azure Storage 소스의 엔드포인트로 구성되어야 해요.

구성 세부 정보는 아래 다이어그램을 참고해요.

[IMAGE: Pipe replication for Azure]

새 Event Grid 구독과 스토리지 큐를 만들어요. 그런 다음 타깃 계정에 새 알림 통합을 만들고 스토리지 큐에 Snowflake 접근 권한을 부여해요. 지침은 Azure Event Grid로 자동화 구성 을 참고해요.

중요

각 타깃 계정의 알림 통합 이름은 소스 계정의 알림 통합 이름과 일치해야 해요.

Google Cloud Storage용 외부 스테이지

Google Cloud Storage의 파일에서 데이터를 자동으로 로드하는 파이프에는 Google Pub/Sub 구독과 해당 구독을 참조하는 알림 통합이 필요해요. 타깃 계정의 각 복제된 파이프에도 Google Pub/Sub 구독과 해당 구독을 참조하는 알림 통합이 필요해요. 각 소스 및 타깃 계정의 Pub/Sub 구독은 Google Cloud Storage 소스에서 알림을 받는 동일한 Pub/Sub 토픽에 구독되어야 해요.

구성 세부 정보는 아래 다이어그램을 참고해요.

[IMAGE: Pipe replication for GCP]

Pub/Sub 토픽에 대한 새 구독과 타깃 계정에 새 알림 통합을 만들어요. 그런 다음 Pub/Sub 구독에 Snowflake 접근 권한을 부여해요. 지침은 GCS Pub/Sub을 사용한 자동화 구성 을 참고해요.

중요

각 타깃 계정의 알림 통합 이름은 소스 계정의 알림 통합 이름과 일치해야 해요.

API 통합에 대한 원격 서비스 업데이트

API 통합 복제를 활성화했다면 API 통합이 타깃 계정으로 복제된 후 추가 단계가 필요해요. 복제된 통합은 기본 통합의 IAM 엔티티와 다른 자체 IAM 엔티티를 가져요. 따라서 복제된 함수에 접근 권한을 부여하도록 원격 서비스의 권한을 업데이트해야 해요. 이 과정은 기본 계정의 함수에 접근 권한을 부여하는 것과 비슷해요. 자세한 내용은 아래 링크를 참고해요.

Amazon Web Services: Snowflake와 새 IAM 역할 사이의 신뢰 관계 설정.
Google Cloud Platform: Proxy Service용 GCP Security Policy 생성.
Microsoft Azure:
- 1단계: Azure용 API 통합 연결
- 2단계: validate-JWT 정책 생성

기본 및 보조 데이터베이스의 데이터 세트 비교

Snowflake는 각 복제 새로고침 작업의 일부로 자동 검증 검사를 수행해요. 검증 실패가 발생하면 새로고침이 실패해요. 따라서 복제된 데이터를 수동으로 검증할 필요가 없어요. 규정 준수 목적으로 추가 검증이 필요하면 새로고침 작업이 끝난 후 수동 검증 단계를 수행할 수 있어요.

Snowflake의 자동 검증

Snowflake는 현재 각 새로고침 작업 후 기본 계정과 보조 계정 사이에서 다음 검사를 수행해요.

복제된 모든 파일에 대해 기본 계정과 보조 계정의 해시 값을 비교해요.
각 테이블에 대해 기본 계정과 보조 계정에서 다음 값을 비교해요.
- 파일 수.
- 행 수.
- 바이트 수.

수동 검증

복제/장애 조치 그룹에서 데이터베이스 객체가 복제되면 HASH_AGG 함수를 사용해 기본 및 보조 데이터베이스의 일부 또는 모든 테이블의 행을 비교해 데이터 일관성을 검증할 수 있어요. HASH_AGG 함수는 입력 행 집합에 대한 집계된 부호 있는 64비트 해시 값을 반환해요. 해시 값은 입력 행의 순서와 관계없이 동일해요.

보조 계정과 기본 계정 모두에서 모든 테이블 또는 무작위 테이블 부분집합에 대해 이 함수를 쿼리해요. 기본 계정에서 AT | BEFORE 절을 사용해 관련 데이터베이스의 최신 새로고침 시점을 지정해요. 두 계정의 쿼리 결과를 비교해요.

새로고침 후 데이터를 수동으로 검증하는 예제

다음 예제에서 데이터베이스 mydb 는 장애 조치 그룹 myfg 에 포함돼 있어요. 데이터베이스 mydb 에는 테이블 myschema.mytable 이 포함돼 있어요.

타깃 계정에서 실행할 명령

Snowflake Information Schema 의 REPLICATION_GROUP_REFRESH_PROGRESS 테이블 함수를 쿼리해요. PRIMARY_UPLOADING_METADATA 단계의 DETAILS 열에 있는 primarySnapshotTimestamp 를 기록해요. 이것은 기본 계정에서 해당 데이터베이스의 최신 새로고침 타임스탬프예요.

SELECT PARSE_JSON(details)['primarySnapshotTimestamp']
  FROM TABLE(
    information_schema.replication_group_refresh_progress(
      'myfg'
    ))
  WHERE PHASE_NAME = 'PRIMARY_UPLOADING_METADATA';

보조 계정에서 지정된 테이블에 대해 HASH_AGG 함수를 쿼리해요. 다음 쿼리는 myschema.mytable 테이블의 모든 행에 대한 해시 값을 반환해요.

SELECT HASH_AGG(*) FROM mydb.myschema.mytable;

소스 계정에서 실행할 명령

기본 계정에서 같은 테이블에 대해 HASH_AGG 함수를 쿼리해요. Time Travel을 사용해 보조 데이터베이스에 대해 최신 새로고침이 수행된 시점을 지정해요.

SELECT HASH_AGG(*) FROM mydb.myschema.mytable
  AT (TIMESTAMP => '<primarySnapshotTimestamp>'::TIMESTAMP);

두 쿼리의 결과를 비교해요. 출력은 동일해야 해요.

소스 계정에서 복제/장애 조치 그룹 수정

Snowsight 또는 SQL 을 사용해 소스 계정의 복제/장애 조치 그룹의 이름, 포함된 객체, 복제 일정을 편집할 수 있어요.

참고: 복제 그룹을 장애 조치 그룹으로 또는 그 반대로 바꿀 수 없어요. 장애 조치를 활성화하거나 비활성화하려면 그룹을 삭제하고 올바른 장애 조치 설정으로 다시 만들어요.

Snowsight로 소스 계정에서 복제/장애 조치 그룹 수정

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

이 작업을 수행하려면 소스 계정에 로그인해야 해요. 로그인하지 않으면 Status 열에 새로고침 상태 대신 로그인 메시지가 표시돼요.

Snowsight 에 로그인해요.
탐색 메뉴에서 Admin » Accounts 를 선택해요.
Replication 을 선택한 다음 Groups 를 선택해요.
편집하려는 복제/장애 조치 그룹을 찾아 행의 마지막 열에서 More 메뉴(…)를 선택해요.
Edit 을 선택해요.
그룹 이름을 변경하려면 Group name 상자에 다음 요구 사항을 충족하는 새 이름을 입력해요.
- 알파벳 문자로 시작해야 하며, 식별자 문자열이 큰따옴표로 묶여 있지 않으면 공백이나 특수 문자를 포함할 수 없어요(예: “My object”). 큰따옴표로 묶인 식별자는 대소문자를 구분해요. 자세한 내용은 식별자 요구 사항 을 참고해요.
- 계정 내 장애 조치 그룹과 복제 그룹의 이름은 고유해야 해요.
Edit objects 를 선택해 공유 및 계정 객체를 추가하거나 제거해요.
- 참고: 계정 객체는 하나의 복제/장애 조치 그룹에만 추가할 수 있어요. 계정에 계정 객체가 있는 복제/장애 조치 그룹이 이미 존재하면 해당 객체를 선택할 수 없어요.
Select databases 를 선택해 데이터베이스 객체를 추가하거나 제거해요.
그룹의 복제 일정을 변경하려면 Replication frequency 를 선택해요.
그룹을 업데이트하려면 Save 를 선택해요.

그룹 변경 저장이 실패하면 Snowsight로 복제 그룹 생성·편집 문제 해결 을 참고해 일반적인 오류와 해결 방법을 확인해요.

SQL로 소스 계정에서 복제/장애 조치 그룹 수정

ALTER REPLICATION GROUP 또는 ALTER FAILOVER GROUP 명령을 사용해 복제/장애 조치 그룹 속성을 수정할 수 있어요.

타깃 계정에서 복제 일정 일시 중지 또는 재개

Snowsight 또는 SQL 을 사용해 타깃 계정에서 복제 일정을 일시 중지(suspend)하거나 재개(resume)할 수 있어요.

Snowsight로 타깃 계정에서 복제 일정 일시 중지 또는 재개

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

복제 일정을 일시 중지하거나 재개하려면 타깃 계정에 로그인해야 해요.

Snowsight 에 로그인해요.
탐색 메뉴에서 Admin » Accounts 를 선택해요.
Replication 을 선택한 다음 Groups 를 선택해요.
편집하려는 복제/장애 조치 그룹을 찾아 행의 마지막 열에서 More 메뉴(…)를 선택해요.
Pause 또는 Resume 을 선택해요.

SQL로 타깃 계정에서 복제 일정 일시 중지 또는 재개

ALTER REPLICATION GROUP 또는 ALTER FAILOVER GROUP 명령을 사용해 타깃 계정에서 복제 일정을 일시 중지하거나 재개할 수 있어요. 일시 중지하려면 SUSPEND 파라미터를, 재개하려면 RESUME 파라미터를 지정해요.

보조 복제/장애 조치 그룹 삭제

DROP REPLICATION GROUP 또는 DROP FAILOVER GROUP 명령을 사용해 보조 복제/장애 조치 그룹을 삭제할 수 있어요. 복제/장애 조치 그룹 소유자(즉 그룹에 대한 OWNERSHIP 권한을 가진 역할)만 그룹을 삭제할 수 있어요.

Snowsight로 보조 복제/장애 조치 그룹을 삭제하려면 소스 계정에서 그룹을 삭제해야 해요. Snowsight로 복제/장애 조치 그룹 삭제 를 참고해요.

기본 복제/장애 조치 그룹 삭제

Snowsight 또는 SQL을 사용해 기본 복제/장애 조치 그룹을 삭제할 수 있어요. SQL로 기본 그룹을 삭제하려면 먼저 모든 보조 그룹을 삭제해야 해요. 보조 복제/장애 조치 그룹 삭제 를 참고해요.

SQL로 기본 복제/장애 조치 그룹 삭제

기본 복제/장애 조치 그룹은 그룹의 모든 복제본(즉 보조 복제/장애 조치 그룹)이 삭제된 후에만 삭제할 수 있어요. 또는 보조 장애 조치 그룹을 기본 장애 조치 그룹으로 승격한 다음 이전 기본 장애 조치 그룹을 삭제할 수도 있어요.

그룹 소유자만 그룹을 삭제할 수 있다는 점에 유의해요.

Snowsight로 복제/장애 조치 그룹 삭제

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

기본 복제/장애 조치 그룹과 연결된 모든 보조 그룹을 삭제할 수 있어요.

Snowsight 에 로그인해요.
탐색 메뉴에서 Admin » Accounts 를 선택해요.
Replication 을 선택한 다음 Groups 를 선택해요.
삭제하려는 복제/장애 조치 그룹을 찾아 행의 마지막 열에서 More 메뉴(…)를 선택해요.
Drop 을 선택한 다음 Drop group 을 선택해요.

Snowsight로 복제 그룹 생성·편집 시 문제 해결

다음 시나리오는 Snowsight로 복제/장애 조치 그룹을 만들거나 편집할 때 발생할 수 있는 일반적인 문제를 해결하는 데 도움이 돼요.

그룹에 데이터베이스를 추가할 수 없음
그룹에 공유를 추가할 수 없음

그룹에 데이터베이스를 추가할 수 없음

오류	Database '<database_name>' is already configured to replicate to account '<account_name>' by replication group '<group_name>'.
원인	데이터베이스는 하나의 복제/장애 조치 그룹에만 있을 수 있어요. 그룹에 선택한 데이터베이스 중 하나가 이미 다른 복제/장애 조치 그룹에 포함되어 있어요.
해결 방법	Select Databases 를 선택해 이미 다른 그룹에 포함된 데이터베이스를 선택 해제해요.

오류	Cannot directly add previously replicated object '<database_name>' to a replication group. Please use the provided system functions to convert this object first.
원인	복제/장애 조치 그룹에 추가하려는 데이터베이스가 이전에 데이터베이스 복제용으로 구성되었어요.
해결 방법	데이터베이스의 복제를 비활성화해요. 데이터베이스 복제에서 그룹 기반 복제로 전환 을 참고해요.

그룹에 공유를 추가할 수 없음

오류	Share '<share_name>' is already configured to replicate to account '<account_name>' by replication group '<group_name>'.
원인	공유는 하나의 복제/장애 조치 그룹에만 있을 수 있어요. 그룹에 선택한 공유 중 하나가 이미 다른 복제/장애 조치 그룹에 포함되어 있어요.
해결 방법	Select Objects 를 선택해 이미 다른 그룹에 포함된 공유를 선택 해제해요.

복제 구성에 Snowsight를 사용할 때의 제한 사항

Snowsight로 복제/장애 조치 그룹을 만들 수 있는 사람은 ACCOUNTADMIN 역할을 가진 사용자뿐이에요. CREATE REPLICATION GROUP 또는 CREATE FAILOVER GROUP 권한을 가진 역할을 가진 사용자는 해당 SQL 명령으로 그룹을 만들 수 있어요.
Snowsight로 복제/장애 조치 그룹을 편집하거나 삭제할 수 있는 사람은 ACCOUNTADMIN 역할을 가진 사용자뿐이에요. 복제/장애 조치 그룹에 대한 OWNERSHIP 권한을 가진 역할을 가진 사용자는 해당 SQL 명령으로 그룹을 편집하고 삭제할 수 있어요.
계정이 프라이빗 연결(private connectivity)을 사용하면 Snowsight로 그룹을 만들거나, 수정하거나, 삭제할 수 없어요. SQL을 사용해 이러한 작업을 완료할 수 있어요.

더 알아보기 (Learn more)

여러 계정 간 복제와 장애 조치 소개 — 복제 개념과 복제된 객체
복제 고려 사항 — 복제된 객체의 동작과 제약
여러 계정 간 보안 통합 및 네트워크 정책 복제 — 보안 통합 및 네트워크 정책 복제
스테이지, 파이프, 로드 이력 복제 — 데이터 파이프라인 객체 복제