계정 오브젝트 복제하기¶
이 항목에서는 같은 조직의 Snowflake 계정 전체에 걸쳐 계정 오브젝트 및 데이터를 복제하고 오브젝트와 데이터를 동기화된 상태로 유지하는 데 필요한 단계를 설명합니다. 계정 복제는 다양한 리전 의 Snowflake 계정과 클라우드 플랫폼 에서 발생할 수 있습니다.
참고
계정을 Business Critical Edition 이상으로 업그레이드하는 경우 장애 조치 기능을 사용할 수 있게 되기까지 최대 12시간이 걸릴 수 있습니다.
이 항목의 내용:
복제 및 장애 조치/장애 복구를 위한 리전 지원¶
고객은 리전 그룹 내의 모든 리전에서 복제할 수 있습니다. 다양한 리전 그룹 에서 리전 간에(예: Snowflake 상업 리전에서 Snowflake 정부 리전으로) 복제하려면 Snowflake 지원 에 문의하여 액세스를 활성화하십시오.
데이터베이스 복제에서 그룹 기반 복제로 전환하기¶
ALTER DATABASE 항목을 사용하여 복제가 활성화된 데이터베이스는 복제 또는 장애 조치 그룹에 추가되기 전에 복제를 비활성화해야 합니다.
참고
ACCOUNTADMIN 역할을 사용하여 이 섹션의 SQL 문을 실행하십시오.
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;
계정 오브젝트 및 데이터베이스 복제하기¶
이 섹션의 지침은 복제를 위해 계정을 준비하고, 원본 계정에서 대상 계정으로 특정 오브젝트의 복제를 활성화하고, 대상 계정의 오브젝트를 동기화하는 방법을 설명합니다.
중요
대상 계정에는 기본적으로 활성화된 Tri-Secret Secure 또는 Snowflake 서비스에 대한 비공개 연결(예: AWS PrivateLink)이 없습니다. 규정 준수, 보안 또는 기타 목적을 위해 Snowflake 서비스에 대한 Tri-Secret Secure 또는 비공개 연결이 필요한 경우 대상 계정에서 해당 기능을 구성하고 활성화하는 것은 사용자의 책임입니다.
전제 조건: 조직의 계정에 대한 복제 활성화¶
조직 관리자(ORGADMIN 역할)는 원본 및 대상 계정에 대해 복제를 활성화해야 합니다.
계정에 대한 복제를 활성화하기 위해, ORGADMIN 역할을 가진 사용자는 SYSTEM$GLOBAL_ACCOUNT_SET_PARAMETER 함수를 사용하여 ENABLE_ACCOUNT_DATABASE_REPLICATION
매개 변수를 true
로 설정합니다. 조직의 여러 계정을 사용해 동일한 ORGADMIN 계정에서 복제할 수 있습니다.
ORGADMIN 계정에 로그인하여 조직에서 각 원본 계정과 대상 계정에 대해 복제를 활성화합니다.
USE ROLE ORGADMIN;
-- View the list of the accounts in your organization
-- Note the organization name and account name for each account for which you are enabling replication
SHOW ORGANIZATION ACCOUNTS;
-- Enable replication by executing this statement for each source and target account in your organization
SELECT SYSTEM$GLOBAL_ACCOUNT_SET_PARAMETER('<organization_name>.<account_name>', 'ENABLE_ACCOUNT_DATABASE_REPLICATION', 'true');
SYSTEM$GLOBAL_ACCOUNT_SET_PARAMETER 함수는 레거시 계정 로케이터 식별자를 지원하지만, 조직에 (다양한 리전에서) 같은 로케이터를 공유하는 계정이 여러 개 있을 때 예기치 않은 결과를 초래합니다.
1단계: 원본 계정에서 CREATE FAILOVER GROUP 권한이 있는 역할 만들기 — 선택 사항¶
역할을 생성하고 CREATE FAILOVER GROUP 권한을 부여합니다. 이 단계는 선택 사항입니다. 이 역할을 이미 만든 경우 2단계: 원본 계정에서 기본 장애 조치 그룹 생성하기 항목으로 건너뛰십시오.
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 |
+------------------+-------------------------------+--------------+-----------------+-----------------+-------------------+--------------+
리전 IDs 전체 목록을 살펴봅니다.
장애 조치 및 복제 그룹 구성원 보기¶
계정, 데이터베이스, 공유 오브젝트에는 그룹 구성원 자격에 대한 제약 이 있습니다. 새 그룹을 생성하거나 기존 그룹에 오브젝트를 추가하기 전에 기존 장애 조치 그룹 및 각 그룹의 오브젝트 목록을 검토할 수 있습니다.
참고
계정 관리자(ACCOUNTADMIN 역할이 있는 사용자) 또는 그룹 소유자(그룹에 대한 OWNERSHIP 권한이 있는 역할)만 이 섹션의 SQL 문을 실행할 수 있습니다.
현재 계정에 연결된 모든 장애 조치 그룹, 그리고 각 그룹의 오브젝트 유형을 봅니다.
SHOW FAILOVER GROUPS;
장애 조치 그룹 myfg
의 모든 데이터베이스 보기:
SHOW DATABASES IN FAILOVER GROUP myfg;
장애 조치 그룹 myfg
의 모든 공유 보기:
SHOW SHARES IN FAILOVER GROUP myfg;
원본 계정에서 대상 계정으로 계정 및 데이터베이스 오브젝트 복제 활성화하기¶
원본 계정에 지정된 계정 및 데이터베이스 오브젝트의 장애 조치 그룹을 생성하고 대상 계정 목록에 대한 복제 및 장애 조치를 활성화합니다. 구문은 CREATE FAILOVER GROUP 섹션을 참조하십시오.
예를 들어 원본 계정에서 동일 조직의 myaccount2
계정으로 사용자, 역할, 웨어하우스, 리소스 모니터, db1
및 db2
데이터베이스를 복제할 수 있습니다. 10분마다 자동으로 myaccount2
를 새로 고치도록 복제 일정을 설정합니다.
참고
이전에 ALTER DATABASE 항목을 사용하여 데이터베이스 복제에 대해 활성화된 복제 또는 장애 조치 그룹에 추가할 데이터베이스가 있는 경우, 그룹에 추가하기 전에 이 항목의 데이터베이스 복제에서 그룹 기반 복제로 전환하기 지침을 따르십시오.
원본 계정에서 실행됨:
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';
3단계: 대상 계정에서 CREATE FAILOVER GROUP 권한이 있는 역할 만들기 — 선택 사항¶
대상 계정에서 역할을 생성하고 CREATE FAILOVER GROUP 권한을 부여합니다. 이 단계는 선택 사항입니다. 이 역할을 이미 만든 경우 4단계: 대상 계정에 보조 장애 조치 그룹 생성하기 항목으로 건너뛰십시오.
USE ROLE ACCOUNTADMIN;
CREATE ROLE myrole;
GRANT CREATE FAILOVER GROUP ON ACCOUNT
TO ROLE myrole;
4단계: 대상 계정에 보조 장애 조치 그룹 생성하기¶
참고
원본 계정에는 존재하지 않는 계정 오브젝트(예: 사용자 또는 역할)가 대상 계정에 존재하는 경우 사용자 및 역할의 초기 복제 섹션을 참조하여 보조 그룹을 생성하십시오.
원본 계정의 기본 장애 조치 그룹의 복제본으로서 대상 계정에 보조 장애 조치 그룹을 생성합니다.
이 항목의 2단계: 원본 계정에서 기본 장애 조치 그룹 생성하기 에서 복제를 활성화한 각 대상 계정에서 CREATE FAILOVER GROUP … AS REPLICA OF 문을 실행합니다.
각 대상 계정에서 실행됨:
USE ROLE myrole;
CREATE FAILOVER GROUP myfg
AS REPLICA OF myorg.myaccount1.myfg;
5단계. 대상 계정의 보조 장애 조치 그룹을 수동으로 새로 고침 — 선택 사항¶
대상 계정의 오브젝트를 수동으로 새로 고치려면 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;
대상 계정의 스크립트에 의해 생성된 오브젝트에 전역 ID 적용하기¶
복제 이외의 방법(예: 스크립트 사용)을 통해 대상 계정에서 계정 오브젝트(예: 사용자 및 역할)를 생성한 경우, 이러한 사용자 및 역할에는 기본적으로 전역 식별자가 없습니다. 새로 고침 작업은 전역 식별자를 사용하여 이러한 오브젝트를 원본 계정의 동일 오브젝트에 동기화합니다.
대부분의 경우에는 대상 계정이 원본 계정에서 새로 고쳐지면 새로 고침 작업은 전역 식별자가 없는 대상 계정에 있는 OBJECT_TYPES
목록에서 유형의 모든 계정 오브젝트를 삭제 합니다. 그러나 대상 계정에 대한 사용자 및 역할의 초기 복제로 인해 첫 번째 새로 고침 작업이 실패할 수 있습니다. 이 동작에 대한 자세한 내용은 사용자 및 역할의 초기 복제 섹션을 참조하십시오.
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>');
참고
이름이 같은 원본 계정에 일치하는 사용자가 없는 대상 계정의 모든 사용자는 삭제됩니다.
원본 계정의 사용자와 이름이 일치하는 대상 계정의 사용자가 없는 경우 대상 계정의 초기 새로 고침 작업에서 모든 사용자가 삭제됩니다. 이로 인해 다음과 같은 데이터와 메타데이터가 손실될 수 있습니다.
복제 또는 장애 조치 그룹의 OBJECT_TYPES 목록에 USERS가 포함된 경우:
워크시트가 손실됩니다.
쿼리 기록이 손실됩니다.
USERS가 OBJECT_TYPES 목록에 포함되지만 ROLES는 포함되지 않는 경우:
사용자에게 부여된 권한이 손실됩니다.
ROLES가 OBJECT_TYPES 목록에 포함된 경우:
오브젝트를 공유하기 위해 부여된 권한이 손실됩니다.
대상 계정에서 사용자나 역할을 삭제하지 않으려면 다음을 수행하십시오.
원본 계정에서 초기 복제 전에 오직 대상 계정에만 존재하는 사용자나 역할을 전부 수동으로 다시 생성합니다.
대상 계정에서 SYSTEM$LINK_ACCOUNT_OBJECTS_BY_NAME 함수를 사용하여 두 계정에서 모두 동일한 이름을 가진 일치하는 오브젝트를 연결합니다.
보조 저장소 통합을 위한 클라우드 저장소 액세스 구성하기¶
저장소 통합 복제를 활성화할 경우 저장소 통합이 대상 계정에 복제된 후 추가 단계를 수행해야 합니다. 복제된 통합에는 기본 통합의 ID 및 IAM 엔티티와는 다른 고유한 ID 및 액세스 관리(IAM) 엔티티가 있습니다. 따라서 복제된 통합에 클라우드 저장소에 대한 액세스 권한을 부여하려면 클라우드 공급자 권한을 업데이트해야 합니다.
대상 계정에서 이 신뢰 관계를 한 번만 구성하면 됩니다.
이 프로세스는 원본 계정에 액세스 권한을 부여하는 것과 유사합니다. 자세한 내용은 다음 페이지를 참조하십시오.
보조 스테이지에서 디렉터리 테이블에 대한 자동 새로 고침 구성하기¶
디렉터리 테이블이 있는 외부 스테이지를 복제하고 원본 디렉터리 테이블에 대해 자동 새로 고침을 구성한 경우 보조 디렉터리 테이블에 대해 자동 새로 고침 을 구성하는 단계를 수행해야 합니다.
이 프로세스는 원본 계정에서 자동 새로 고침을 설정하는 것과 유사합니다. 자세한 내용은 다음을 참조하십시오.
Amazon S3: 구성 프로세스는 이벤트 알림 설정 방법에 따라 다릅니다.
Amazon SQS(Simple Queue Service)와 함께 Amazon S3 Event Notifications를 사용하는 경우 2단계: 이벤트 알림 구성 의 지침을 따르십시오.
Amazon SNS(Simple Notification Service)를 사용하는 경우 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의 경우 각 대상 계정의 알림 통합 이름이 원본 계정의 알림 통합 이름과 일치해야 합니다.
보조 자동 수집 파이프에 대한 알림 구성하기¶
장애 조치 전에 보조 자동 수집 파이프에 대한 클라우드 알림을 구성하려면 추가 단계를 수행해야 합니다. 이 섹션에서는 이 추가 구성이 필요한 이유와 지원되는 각 클라우드 공급자에 대해 구성을 완료하는 방법을 설명합니다.
Amazon S3¶
구성 프로세스는 이벤트 알림 설정 방법에 따라 다릅니다. 예를 들어 Snowflake 스테이지 위치에 대한 메시지를 게시하기 위해 Amazon SNS(Simple Notification Service) 항목에 의존하는 자동 수집 파이프가 있다고 가정해 보겠습니다.
파이프를 대상 계정에 복제하면 Snowflake가 새로운 Amazon SQS(Simple Queue Service) 큐를 자동으로 생성합니다. 스테이지 위치에 대한 알림을 받으려면 SNS 항목에 대해 대상 계정의 이 SQS 큐를 구독해야 합니다.
Amazon SQS(Simple Queue Service)와 함께 Amazon S3 Event Notifications를 사용하는 경우 4단계: 이벤트 알림 구성 의 지침을 따르십시오.
중요
파이프가 알림을 놓치지 않았는지 확인하려면 새 SQS 큐로 전환한 후 파이프를 새로 고쳐야 합니다.
Amazon SNS(Simple Notification Service)를 사용하는 경우 Snowflake SQS 큐에서 SNS 항목 구독하기 를 참조하십시오.
Amazon EventBridge을 사용하는 경우 옵션 3: Snowpipe를 자동화하도록 Amazon EventBridge 설정 섹션을 참조하십시오.
Microsoft Azure Blob 저장소¶
Microsoft Azure Blob 저장소의 스테이지에 있는 파일에서 데이터를 자동으로 로드하는 파이프에는 Event Grid 구독, 저장소 큐, 저장소 큐에 바인딩된 알림 통합이 필요합니다. 대상 계정의 보조 파이프에는 별도의 Event Grid, 저장소 큐, 저장소 큐에 바인딩된 알림 통합이 필요합니다. 원본 계정과 대상 계정 모두의 Event Grid는 동일한 Azure Storage 원본의 엔드포인트로 구성해야 합니다.
구성 세부 정보는 아래 다이어그램을 참조하십시오.
Event Grid 구독 및 알림 통합을 구성하려면 Azure Event Grid를 사용한 자동화 구성하기 의 자세한 지침을 따르십시오.
중요
각 대상 계정의 알림 통합 이름은 원본 계정의 알림 통합 이름과 일치해야 합니다.
Google Cloud Storage의 외부 스테이지¶
Google Cloud Storage에 있는 파일에서 데이터를 자동으로 로드하는 파이프에는 Google Pub/Sub 구독과 해당 구독을 참조하는 알림 통합이 필요합니다. 대상 계정에서 복제된 각 파이프에는 Google Pub/Sub 구독과 해당 구독을 참조하는 알림 통합도 필요합니다. 각 원본 및 대상 계정의 Pub/Sub 구독은 Google Cloud Storage 원본에서 알림을 받는 동일한 Pub/Sub 항목을 구독해야 합니다.
구성 세부 정보는 아래 다이어그램을 참조하십시오.
Pub/Sub 구독 생성 및 알림 통합에 대한 자세한 지침은 GCS Pub/Sub를 사용하여 자동화 구성하기 섹션을 참조하십시오.
중요
각 대상 계정의 알림 통합 이름은 원본 계정의 알림 통합 이름과 일치해야 합니다.
API 통합을 위해 원격 서비스 업데이트하기¶
API 통합 복제를 활성화한 경우 API 통합이 대상 계정에 복제된 후 추가 단계가 필요합니다. 복제된 통합에는 기본 통합의 ID 및 IAM 엔티티와는 다른 고유한 ID 및 액세스 관리(IAM) 엔티티가 있습니다. 따라서 복제된 함수에 대한 액세스 권한을 부여하려면 원격 서비스에 대한 권한을 업데이트해야 합니다. 이 프로세스는 기본 계정의 함수에 대한 액세스 권한을 부여하는 것과 유사합니다. 자세한 내용은 아래 링크를 참조하십시오.
Amazon Web Services Snowflake와 새 IAM 역할 사이의 트러스트 관계 설정하기.
Google Cloud Platform: 프록시 서비스에 대한 GCP 보안 정책 생성.
Microsoft Azure:
1단계. Azure용 API 통합 연결
2단계. JWT 유효성 검사 정책 생성하기
복제 모니터링¶
이 섹션에서는 계정 복제 진행률, 기록, 비용을 모니터링하는 방법에 대한 정보를 제공합니다.
복제 그룹 또는 장애 조치 그룹 새로 고침의 진행률 모니터링¶
복제 또는 장애 조치 그룹 새로 고침의 진행률을 모니터링하려면 (Snowflake Information Schema 에서) REPLICATION_GROUP_REFRESH_PROGRESS, REPLICATION_GROUP_REFRESH_PROGRESS_BY_JOB 테이블 함수를 쿼리합니다.
예¶
장애 조치 그룹 myfg
에 대한 가장 최근 새로 고침 작업의 진행률을 확인합니다.
SELECT PHASE_NAME, START_TIME, END_TIME, PROGRESS, DETAILS
FROM TABLE(information_schema.replication_group_refresh_progress('myfg'));
복제 기록¶
지정된 날짜 범위 내에서 특정 복제 또는 장애 조치 그룹의 복제 기록을 보려면 다음 중 하나를 쿼리하십시오.
예¶
지난 7일간 장애 조치 그룹 myfg
의 계정 복제 기록을 보려면 Information Schema REPLICATION_GROUP_REFRESH_HISTORY 테이블 함수를 쿼리하십시오.
SELECT PHASE_NAME, START_TIME, END_TIME, TOTAL_BYTES, OBJECT_COUNT
FROM TABLE(information_schema.replication_group_refresh_history('myfg'))
WHERE START_TIME >= current_date - interval '7 days';
이번 달의 계정 복제 기록을 보려면 Account Usage REPLICATION_GROUP_REFRESH_HISTORY 뷰를 쿼리하십시오.
SELECT REPLICATION_GROUP_NAME, PHASE_NAME, START_TIME, END_TIME, TOTAL_BYTES, OBJECT_COUNT
FROM snowflake.account_usage.replication_group_refresh_history
WHERE START_TIME >= date_trunc('month', current_date());
복제 비용 모니터링¶
복제에 대한 크레딧 사용을 모니터링하려면 다음 중 하나를 쿼리하십시오.
예¶
지난 7일간 계정 복제에 사용된 크레딧을 보려면 REPLICATION_GROUP_USAGE_HISTORY 테이블 함수를 쿼리하십시오.
SELECT start_time, end_time, replication_group_name, credits_used, bytes_transferred
FROM table(information_schema.replication_group_usage_history(date_range_start=>dateadd('day', -7, current_date())));
이번 달의 계정 복제 기록에 대해 복제 또는 장애 조치 그룹에서 사용하는 크레딧을 보려면 Account Usage REPLICATION_GROUP_USAGE_HISTORY 뷰를 쿼리하십시오.
SELECT start_time,
end_time,
replication_group_name,
credits_used,
bytes_transferred
FROM snowflake.account_usage.replication_group_usage_history
WHERE start_time >= DATE_TRUNC('month', CURRENT_DATE());
데이터베이스의 복제 비용 모니터링하기¶
복제 또는 장애 조치 그룹에 포함된 개별 데이터베이스의 복제 비용은 데이터베이스에 대해 복사된 바이트 수를 검색하고 이를 사용된 크레딧과 연결하여 계산할 수 있습니다.
예¶
Account Usage 뷰 쿼리하기¶
다음 예제에서는 지난 30일 동안 한 복제 그룹의 데이터베이스 복제 비용을 계산합니다.
REPLICATION_GROUP_REFRESH_HISTORY Account Usage 뷰를 쿼리하고 데이터베이스당 복제된 바이트 수의 합계를 계산합니다.
예를 들어, 지난 30일 동안 복제 그룹
myrg
의 데이터베이스에 대해 복제된 바이트 수의 합계를 계산하려면 다음을 수행하십시오.select sum(value:totalBytesToReplicate) as sum_database_bytes from snowflake.account_usage.replication_group_refresh_history rh, lateral flatten(input => rh.total_bytes:databases) where rh.replication_group_name = 'MYRG' and rh.start_time >= current_date - interval '30 days';
데이터베이스 바이트 합계의 출력을 확인합니다.
+--------------------+ | SUM_DATABASE_BYTES | |--------------------| | 22016 | +--------------------+
REPLICATION_GROUP_USAGE_HISTORY Account Usage 뷰를 쿼리하고 사용된 크레딧 수의 합계와 복제용으로 전송된 바이트의 합계를 계산합니다.
예를 들어, 사용된 크레딧 수의 합계와 지난 30일 동안 복제 그룹
myrg
의 복제용으로 전송된 바이트의 합계를 계산하려면 다음을 수행하십시오.select sum(credits_used) as credits_used, SUM(bytes_transferred) as bytes_transferred from snowflake.account_usage.replication_group_usage_history where replication_group_name = 'MYRG' and start_time >= current_date - interval '30 days';
사용된 크레딧 합계와 전송된 바이트 합계의 출력을 확인합니다.
+--------------+-------------------+ | CREDITS_USED | BYTES_TRANSFERRED | |--------------+-------------------| | 1.357923604 | 22013 | +--------------+-------------------+
데이터베이스에 대해 전송된 바이트 값, 사용된 크레딧 합계, 이전의 두 단계에서 복제용으로 전송된 모든 바이트의 합계를 사용하여 데이터베이스의 복제 비용을 계산합니다.
(<전송된_데이터베이스_바이트> / <전송된_바이트>) * <사용된_크레딧>
예:
(22016 / 22013) * 1.357923604 = 1.35810866)
Information Schema 테이블 함수 쿼리하기¶
지난 14일 이내에 수행된 새로 고침 작업의 경우 연결된 Information Schema 테이블 함수를 쿼리합니다.
복제 그룹
myrg
에 대한 데이터베이스 복제를 위해 복사된 바이트 수의 합계를 보려면 REPLICATION_GROUP_REFRESH_HISTORY 테이블 함수를 쿼리하십시오.select sum(value:totalBytesToReplicate) from table(information_schema.replication_group_refresh_history('myrg')) as rh, lateral flatten(input => total_bytes:databases) where rh.phase_name = 'COMPLETED' and rh.start_time >= current_date - interval '14 days';
REPLICATION_GROUP_USAGE_HISTORY 테이블 함수를 쿼리하여 사용된 크레딧 수의 합계와 복제 그룹
myrg
에 대한 복제용으로 전송된 바이트의 합계를 확인합니다.select sum(credits_used), sum(bytes_transferred) from table(information_schema.replication_group_usage_history( date_range_start=>dateadd('day', -14, current_date()), replication_group_name => 'myrg' ));
기본 및 보조 데이터베이스의 데이터 세트 비교¶
데이터베이스 오브젝트가 복제 또는 장애 조치 그룹에서 복제되는 경우 HASH_AGG 함수를 사용하여 기본 및 보조 데이터베이스의 임의 테이블 세트의 행을 비교하여 데이터 일관성을 확인할 수 있습니다. HASH_AGG 함수는 (순서 없는) 입력 행 세트에 대해 서명된 집계 64비트 해시 값을 반환합니다. 보조 데이터베이스와 기본 데이터베이스(기본 데이터베이스 스냅샷의 타임스탬프 기준)에 있는 테이블의 전체 또는 임의의 하위 세트에서 이 함수를 쿼리하고 출력을 비교합니다.
예¶
아래 예에서 데이터베이스 mydb
는 장애 조치 그룹 myfg
에 포함되어 있습니다. 데이터베이스 mydb
에는 테이블 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 함수를 쿼리합니다. 다음 쿼리는
mytable
테이블의 모든 행에 대한 해시 값을 반환합니다.SELECT HASH_AGG( * ) FROM mytable;
원본 계정에서 실행됨¶
기본 데이터베이스에서 동일한 테이블에 대해 HASH_AGG 함수를 쿼리합니다. Time Travel을 사용하여 보조 데이터베이스에 대한 최신 스냅샷이 생성된 타임스탬프를 지정합니다.
SELECT HASH_AGG( * ) FROM mytable AT(TIMESTAMP => '<primarySnapshotTimestamp>'::TIMESTAMP);
두 쿼리의 결과를 비교합니다. 출력은 동일해야 합니다.
보조 복제 또는 장애 조치 그룹 삭제하기¶
DROP REPLICATION GROUP 또는 DROP FAILOVER GROUP 명령을 사용하여 보조 복제 또는 장애 조치를 삭제할 수 있습니다. 복제 또는 장애 조치 그룹 소유자(즉, 그룹에 대한 OWNERSHIP 권한이 있는 역할)만 그룹을 삭제할 수 있습니다.
기본 복제 또는 장애 조치 그룹 삭제하기¶
그룹의 모든 복제본(즉, 보조 복제 또는 장애 조치 그룹)이 삭제된 후에만 기본 복제 또는 장애 조치 그룹을 삭제할 수 있습니다. 또는 기본 장애 조치 그룹의 역할을 하도록 보조 장애 조치 그룹을 승격한 다음, 이전의 기본 장애 조치 그룹을 삭제할 수 있습니다.
그룹 소유자만 그룹을 삭제할 수 있음에 유의하십시오.