복제 고려 사항

복제 고려 사항 (Replication considerations)

이 토픽은 복제/장애 조치 그룹 또는 데이터베이스 복제 로 복제할 때 보조 데이터베이스와 객체에서 특정 Snowflake 기능이 어떻게 동작하는지 설명하고, 복제된 객체와 데이터를 다룰 때의 일반적인 지침을 제공해요.

출처: Snowflake 문서 - Replication considerations

본문

Standard 및 Business Critical 기능

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

이전에 ALTER DATABASE … ENABLE REPLICATION TO ACCOUNTS 명령으로 개별 데이터베이스에 대한 데이터베이스 복제를 활성화했다면, 데이터베이스 복제에 특화된 추가 고려 사항은 데이터베이스 복제 고려 사항 을 참고해요.

복제 그룹 및 장애 조치 그룹 제약 사항

다음 섹션들은 계정 객체, 데이터베이스, 공유를 복제 그룹과 장애 조치 그룹에 추가할 때의 제약 사항을 설명해요.

데이터베이스 및 공유 객체

데이터베이스 및 공유 객체에는 다음 제약 사항이 적용돼요.

객체는 하나의 장애 조치 그룹에만 있을 수 있어요.
각 그룹이 다른 타깃 계정으로 복제되는 한 객체는 여러 복제 그룹에 있을 수 있어요.
객체는 장애 조치 그룹과 복제 그룹 양쪽에 동시에 있을 수 없어요.

아웃바운드 공유만 복제할 수 있어요. 인바운드 공유(inbound shares, 프로바이더로부터의 공유) 의 복제는 지원되지 않아요.

계정 객체

계정은 데이터베이스나 공유 이외의 객체를 포함하는 복제/장애 조치 그룹을 하나만 가질 수 있어요.

복제 권한

이 섹션은 시스템에서 복제 및 장애 조치 그룹 객체에 대해 사용자가 수행할 수 있는 작업을 지정하기 위해 역할에 부여할 수 있는 복제 권한을 설명해요. GRANT 명령의 구문은 GRANT … TO ROLE 을 참고해요.

참고: 데이터베이스 복제 의 경우 ACCOUNTADMIN 역할을 가진 사용자만 데이터베이스 복제와 장애 조치를 활성화하고 관리할 수 있어요. 데이터베이스 복제에 필요한 권한에 대한 추가 정보는 6단계: 일정에 따라 보조 데이터베이스 새로고침 의 필요한 권한 표 를 참고해요.

권한	객체	사용처	비고
OWNERSHIP	복제 그룹, 장애 조치 그룹	객체를 삭제, 변경하고 접근 권한을 부여하거나 취소하는 능력을 부여해요.	부여할 수 있는 사람: ACCOUNTADMIN 역할, MANAGE GRANTS 권한이 있는 역할, 그룹에 대한 OWNERSHIP 권한이 있는 역할.
CREATE REPLICATION GROUP	계정	복제 그룹을 만드는 능력을 부여해요.	ACCOUNTADMIN 역할이 부여해야 해요.
CREATE FAILOVER GROUP	계정	장애 조치 그룹을 만드는 능력을 부여해요.	ACCOUNTADMIN 역할이 부여해야 해요.
FAILOVER	장애 조치 그룹	보조 장애 조치 그룹을 기본 장애 조치 그룹으로 승격하는 능력을 부여해요.	그룹에 대한 OWNERSHIP 권한이 있는 역할이 부여하거나 취소할 수 있어요.
REPLICATE	복제 그룹, 장애 조치 그룹	보조 그룹을 새로고침하는 능력을 부여해요.	그룹에 대한 OWNERSHIP 권한이 있는 역할이 부여하거나 취소할 수 있어요.
MODIFY	복제 그룹, 장애 조치 그룹	객체의 설정이나 속성을 변경하는 능력을 부여해요.	그룹에 대한 OWNERSHIP 권한이 있는 역할이 부여하거나 취소할 수 있어요.
MONITOR	복제 그룹, 장애 조치 그룹	객체 내 세부 정보를 보는 능력을 부여해요.	그룹에 대한 OWNERSHIP 권한이 있는 역할이 부여하거나 취소할 수 있어요.

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

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

복제 그룹 전반의 복제와 참조

복제(또는 장애 조치) 그룹의 객체 중 다른 복제/장애 조치 그룹의 객체를 참조하는 댕글링 참조(dangling references)가 있는 객체는 어떤 상황에서는 타깃 계정으로 복제가 성공할 수 있어요. 복제 작업이 타깃 계정에서 소스 계정에서 발생할 수 있는 동작과 일치하는 동작을 만들면 복제가 성공해요.

예를 들어 장애 조치 그룹 fg_a 의 테이블에 있는 컬럼이 장애 조치 그룹 fg_b 의 시퀀스를 참조하면 두 그룹의 복제는 모두 성공해요. fg_a 가 fg_b 보다 먼저 복제되면, fg_b 가 복제되지 않은 상태에서 시퀀스를 참조하는 테이블에 (장애 조치 후) 삽입 작업이 실패 해요. 이 동작은 소스 계정에서도 발생할 수 있어요. 소스 계정에서 시퀀스가 삭제되면 삭제된 시퀀스를 참조하는 컬럼이 있는 테이블에 대한 삽입 작업이 실패해요.

댕글링 참조가 데이터를 보호하는 보안 정책인 경우, 보안 정책이 있는 복제(또는 장애 조치) 그룹은 정책을 참조하는 객체를 포함한 복제 그룹이 복제되기 전에 복제되어야 해요.

주의

별도의 복제/장애 조치 그룹에서 데이터를 보호하는 보안 정책을 변경하면 불일치가 발생할 수 있으므로 신중하게 수행해야 해요.

데이터베이스 객체의 경우 Account Usage의 OBJECT_DEPENDENCIES 뷰 에서 객체 종속성 을 볼 수 있어요.

네트워크 정책의 댕글링 참조

네트워크 정책의 댕글링 참조는 다음 오류 메시지와 함께 복제가 실패하게 만들 수 있어요.

Dangling references in the snapshot. Correct the errors before refreshing again.
The following references are missing (referred entity <- [referring entities])

댕글링 참조를 피하려면 복제/장애 조치 그룹에 대해 CREATE 또는 ALTER 명령을 실행할 때 OBJECT_TYPES 목록에 다음 객체 유형을 지정해요.

네트워크 정책이 네트워크 규칙을 사용하면 네트워크 규칙이 생성된 스키마를 포함하는 데이터베이스를 포함해요.
네트워크 정책이 계정과 연결되어 있으면 OBJECT_TYPES 목록에 NETWORK POLICIES와 ACCOUNT PARAMETERS를 포함해요.
네트워크 정책이 사용자와 연결되어 있으면 OBJECT_TYPES 목록에 NETWORK POLICIES와 USERS를 포함해요.

자세한 내용은 네트워크 정책 복제 를 참고해요.

패키지 정책의 댕글링 참조

계정에 패키지 정책(packages policy) 이 설정되어 있으면 계정 객체를 포함하는 복제/장애 조치 그룹에 대한 새로고침 작업 중에 다음 댕글링 참조 오류가 발생해요.

003131 (55000): Dangling references in the snapshot. Correct the errors before refreshing again.
The following references are missing (referred entity <- [referring entities]):
POLICY '<policy_db>.<policy_schema>.<packages_policy_name>' <- [ACCOUNT '<account_locator>']

댕글링 참조를 피하려면 패키지 정책을 포함하는 데이터베이스를 타깃 계정으로 복제해요. 정책을 포함하는 데이터베이스는 동일하거나 다른 복제/장애 조치 그룹에 있을 수 있어요.

시크릿의 댕글링 참조

자세한 내용은 시크릿과 복제 를 참고해요.

스트림의 댕글링 참조

스트림의 댕글링 참조는 다음 오류 메시지와 함께 복제가 실패하게 만들어요.

Primary database: the source object ''<object_name>'' for this stream ''<stream_name>'' is not included in the replication group.
Stream replication does not support replication across databases in different replication groups. Please see Streams Documentation
https://docs.snowflake.com/en/user-guide/account-replication-considerations#replication-and-streams for options.

댕글링 참조 오류를 피하려면:

기본 데이터베이스가 스트림과 그 기본(base) 객체를 모두 포함하거나
스트림을 포함하는 데이터베이스와 스트림이 참조하는 기본 객체를 포함하는 데이터베이스가 동일한 복제/장애 조치 그룹에 포함되어야 해요.

복제와 읽기 전용 보조 객체

타깃 계정의 모든 보조 객체(보조 데이터베이스와 공유 포함)는 읽기 전용이에요. 복제된 객체나 객체 유형에 대한 변경은 타깃 계정에서 로컬로 수행할 수 없어요. 예를 들어 USERS 객체 유형이 소스 계정에서 타깃 계정으로 복제되면 타깃 계정에서 새 사용자를 만들거나 수정할 수 없어요.

새로운 로컬 데이터베이스와 공유는 타깃 계정에서 만들고 수정할 수 있어요. ROLES 도 타깃 계정으로 복제되면 그 타깃 계정에서 새 역할을 만들거나 수정할 수 없어요. 따라서 타깃 계정의 보조 객체에 있는 역할에 권한을 부여하거나(취소할 수도 없고) 할 수 없어요. 하지만 타깃 계정에서 생성된 로컬 객체(예: 데이터베이스, 공유, 복제/장애 조치 그룹)의 보조 역할에는 권한을 부여(또는 취소)할 수 있어요.

복제와 타깃 계정의 객체

복제가 아닌 다른 방법(예: 스크립트 사용)으로 타깃 계정에 계정 객체(예: 사용자, 역할)를 만들었다면 이러한 사용자와 역할에는 기본적으로 전역 식별자가 없어요. 타깃 계정이 소스 계정에서 새로고침될 때, 새로고침 작업은 타깃 계정의 OBJECT_TYPES 목록에 있는 유형 중 전역 식별자가 없는 계정 객체를 삭제(drop) 해요.

참고: USERS 또는 ROLES를 복제하기 위한 초기 새로고침 작업은 오류를 발생시킬 수 있어요. 이는 사용자와 역할과 관련된 데이터 및 메타데이터의 실수 삭제를 방지하기 위한 것이에요. 이러한 객체 유형이 삭제되거나 새로고침 작업이 실패하게 되는 상황에 대한 자세한 내용은 사용자 및 역할의 초기 복제 를 참고해요.

이러한 객체가 삭제되는 것을 방지하려면 타깃 계정에서 스크립트로 만든 객체에 전역 ID 적용 을 참고해요.

타깃 계정에서 다시 생성된 객체

소스 계정의 기존 객체가 CREATE OR REPLACE 문으로 대체되면 기존 객체가 삭제되고 단일 트랜잭션에서 같은 이름의 새 객체가 생성돼요. 예를 들어 기존 테이블 t1 에 대해 CREATE OR REPLACE 문을 실행하면 테이블 t1 이 삭제된 다음 새 테이블 t1 이 생성돼요. 자세한 내용은 CREATE TABLE의 사용상 주의사항을 참고해요.

타깃 계정에서 객체가 대체될 때 DROP과 CREATE 문은 새로고침 작업 중에 원자적으로(atomically) 실행되지 않아요. 즉 객체가 새 객체로 다시 생성되는 동안 타깃 계정에서 잠시 사라질 수 있어요.

복제와 보안 정책

보안 정책을 포함하는 데이터베이스와 참조(즉 할당)는 복제 및 장애 조치 그룹을 사용해 복제할 수 있어요. 보안 정책에는 다음이 포함돼요.

집계 정책
인증 정책
데이터 이동 정책(데이터 이동 규칙 포함)
마스킹 정책
비밀번호 정책
프라이버시 정책
프로젝션 정책
행 접근 정책
세션 정책(보조 역할이 있는 세션 정책 포함)
태그 기반 마스킹 정책

데이터베이스 복제 를 사용한다면 데이터베이스 복제와 보안 객체 를 참고해요.

인증, 비밀번호 및 세션 정책

사용자에 대한 인증, 비밀번호, 세션 정책 참조는 복제 그룹이나 장애 조치 그룹에서 정책이 포함된 데이터베이스(ALLOWED_DATABASES = policy_db)와 USERS 를 지정하면 복제돼요.

정책 데이터베이스나 사용자가 이미 타깃 계정으로 복제된 경우, 소스 계정의 복제/장애 조치 그룹을 업데이트해 정책을 성공적으로 복제하는 데 필요한 데이터베이스와 객체 유형을 포함시켜요. 그런 다음 새로고침 작업을 실행해 타깃 계정을 업데이트해요.

사용자 수준 정책을 사용하지 않으면 USERS 를 복제/장애 조치 그룹에 포함할 필요가 없어요.

참고: 정책은 계정 수준 정책 할당과 사용자 수준 정책 할당과 같은 계정에 있어야 해요.

계정 또는 계정의 사용자에 보안 정책이 설정되어 있는데 복제/장애 조치 그룹을 업데이트해 정책이 포함된 policy_db 와 USERS 를 포함시키지 않으면 타깃 계정에서 댕글링 참조가 발생해요. 이 경우 댕글링 참조란 정책의 정규화된 이름이 소스 계정의 데이터베이스를 가리키기 때문에 Snowflake가 타깃 계정에서 정책을 찾을 수 없다는 것을 의미해요. 결과적으로 타깃 계정이나 타깃 계정의 사용자는 보안 정책을 준수할 필요가 없게 돼요.

보안 정책을 성공적으로 복제하려면 복제/장애 조치 그룹에 댕글링 참조를 방지하는 데 필요한 객체 유형과 데이터베이스가 포함되어 있는지 확인해요.

프라이버시 정책

차등 프라이버시(differential privacy) 와 관련된 프라이버시 정책과 프라이버시 보호 테이블 및 뷰를 복제할 때 다음을 고려해요.

소스 계정에서 테이블이나 뷰에 프라이버시 정책이 할당되어 있으면 그 정책을 타깃 계정에서 복제해야 해요.
프라이버시 예산(privacy budget)에 대한 누적 프라이버시 손실은 복제되지 않아요.
타깃 및 소스 계정의 누적 프라이버시 손실은 별도로 추적돼요.
타깃 계정의 관리자는 복제된 프라이버시 예산을 조정할 수 없어요. 프라이버시 예산은 소스 계정의 예산과 동기화돼요.
분석가가 소스 계정과 타깃 계정 모두에서 프라이버시 보호 테이블이나 뷰에 접근할 수 있다면, 프라이버시 예산 한도에 도달하기 전에 두 배의 프라이버시 손실을 초래할 수 있어요.
컬럼에 설정된 프라이버시 도메인도 복제돼요.

보조 역할을 사용한 세션 정책

보조 역할과 함께 세션 정책을 사용한다면 역할을 포함하는 동일한 복제 그룹에 정책 데이터베이스를 지정해야 해요. 예:

CREATE REPLICATION GROUP myrg
  OBJECT_TYPES = DATABASES, ROLES, USERS
  ALLOWED_DATABASES = session_policy_db
  ALLOWED_ACCOUNTS = myorg.myaccount
  REPLICATION_SCHEDULE = '10 MINUTE';

계정 수준 객체를 포함하는 복제/장애 조치 그룹(myrg)과 다른 복제/장애 조치 그룹(rg2)에 보조 역할을 참조하는 세션 정책 데이터베이스를 지정하고 rg2 를 먼저 복제하거나 장애 조치하면 댕글링 참조 가 발생해요. 오류 메시지는 역할을 포함하는 복제/장애 조치 그룹에 세션 정책 데이터베이스를 두라고 안내해요. 이 동작은 세션 정책이 계정이나 사용자에 설정될 때 발생해요.

세션 정책과 계정 수준 객체가 다른 복제 그룹에 있고 세션 정책이 계정이나 사용자에 설정되어 있지 않으면 타깃 계정을 복제하고 새로고침할 수 있어요. 계정 수준 객체를 포함하는 복제 그룹을 먼저 새로고침해야 해요.

보조 역할과 함께 세션 정책과 역할 객체를 복제하거나 장애 조치한 후 타깃 계정을 새로고침하면 타깃 계정이 소스 계정의 세션 정책과 보조 역할 동작을 반영해요.

또한 타깃 계정의 데이터베이스를 새로고침할 때 데이터베이스에 보조 역할을 참조하는 세션 정책이 포함되어 있으면 ALLOWED_SECONDARY_ROLES 는 항상 [ALL] 로 평가돼요.

복제와 시크릿

시크릿은 복제/장애 조치 그룹을 통해서만 복제할 수 있어요. 시크릿을 포함하는 데이터베이스, 시크릿을 참조하는 UDF나 프로시저를 포함하는 데이터베이스, 시크릿을 참조하는 통합을 단일 복제/장애 조치 그룹에 지정해요.

시크릿을 포함하는 데이터베이스가 하나의 복제/장애 조치 그룹에 있고 시크릿을 참조하는 통합이 다른 복제/장애 조치 그룹에 있다면:

통합을 먼저 복제한 다음 시크릿을 복제하면 작업이 성공해요. 모든 객체가 복제되고 댕글링 참조가 없어요.
시크릿을 통합보다 먼저 복제하고 시크릿이 타깃 계정에 아직 존재하지 않으면, 댕글링 참조를 방지하기 위해 타깃 계정에 "플레이스홀더 시크릿(placeholder secret)"이 추가돼요. Snowflake는 플레이스홀더 시크릿을 통합에 매핑해요. 통합을 포함하는 그룹을 복제한 후, 시크릿을 포함하는 그룹에 대한 다음 새로고침 작업에서 Snowflake는 타깃 계정을 업데이트해 플레이스홀더 시크릿을 통합에서 참조하는 시크릿으로 교체해요.
시크릿을 복제했지만 account1 에서 account2 로 통합을 복제하지 않으면, 통합이 없어 시크릿을 사용할 수 없으므로 타깃 계정(account2)에서 통합이 작동하지 않아요. 또한 장애 조치를 해서 타깃 계정이 소스 계정으로 승격되어도 통합이 작동하지 않아요. account1 을 소스 계정으로 만들어 장애 조치할 때는 시크릿과 통합 참조가 일치하고 플레이스홀더 시크릿이 사용되지 않아요. 이렇게 하면 객체들이 서로를 참조할 수 있으므로 보안 통합과 자격 증명을 포함하는 시크릿을 사용할 수 있어요.

복제와 복제(cloning)

과거에는 복제된(cloned) 객체 가 보조 데이터베이스로 물리적으로 복제되었지 논리적으로 복제되지는 않았어요. 즉 표준 데이터베이스의 복제된 테이블은 클론에 대한 DML 작업이 기존 데이터를 추가하거나 수정하기 전까지는 전체 데이터 저장 공간에 기여하지 않았어요. 그러나 복제된 테이블이 보조 데이터베이스로 복제되면 물리적 데이터도 복제되어 계정의 데이터 스토리지 사용량이 늘어났어요.

논리적으로 복제된 복제 테이블은 복제 원본인 원본 테이블의 마이크로 파티션을 공유하므로 타깃 계정에서 보조 테이블의 물리적 저장을 줄여줘요.

원본 테이블과 복제 테이블이 동일한 복제/장애 조치 그룹에 포함되면 복제 테이블을 논리적으로 타깃 계정으로 복제할 수 있어요.

클론의 논리적 복제

원본 테이블과 복제 테이블이 동일한 복제/장애 조치 그룹에 포함되면 복제 테이블을 논리적으로 타깃 계정으로 복제할 수 있어요.

예를 들어 데이터베이스 db2 의 테이블 t2 가 데이터베이스 db1 의 테이블 t1 의 클론이고 두 데이터베이스 모두 복제 그룹 rg1 에 포함되어 있으면 테이블 t2 는 타깃 계정에서 논리적 클론으로 생성돼요.

복제된 객체는 복제되어 원본 객체의 추가 클론을 만들 수 있어요. 원본 객체와 복제된 객체는 동일한 클론 그룹(clone group) 의 일부예요. 예를 들어 데이터베이스 db3 의 테이블 t3 이 t2 의 클론으로 생성되면 원본 테이블 t1 및 복제 테이블 t2 와 같은 클론 그룹에 있어요.

데이터베이스 db3 이 나중에 복제 그룹 rg1 에 추가되면 테이블 t3 은 타깃 계정에서 테이블 t1 의 논리적 클론으로 생성돼요.

고려 사항

소스 계정에서 같은 클론 그룹에 있던 테이블이 타깃 계정에서는 같은 클론 그룹에 있지 않을 수 있어요.
원본 테이블과 복제 테이블은 동일한 복제/장애 조치 그룹에 있어야 해요.
어떤 경우에는 클론 그룹의 모든 마이크로 파티션을 복제 테이블과 공유하지 못할 수 있어요. 이로 인해 타깃 계정의 복제 테이블에 추가 저장 공간이 사용될 수 있어요.

예제

데이터베이스 db2 의 테이블 t2 는 데이터베이스 db1 의 테이블 t1 의 클론이에요. t2 를 타깃 계정으로 논리적으로 복제하려면 두 데이터베이스를 복제 그룹 myrg 에 포함해요.

CREATE REPLICATION GROUP myrg
  OBJECT_TYPES = DATABASES
  ALLOWED_DATABASES = db1, db2
  ALLOWED_ACCOUNTS = myorg.myaccount2
  REPLICATION_SCHEDULE = '10 MINUTE';

복제와 자동 클러스터링

기본 데이터베이스에서 Snowflake는 자동 클러스터링(Automatic Clustering) 으로 클러스터형 테이블을 모니터링하고 필요에 따라 재클러스터링해요. 새로고침 작업의 일부로 클러스터형 테이블은 테이블 마이크로 파티션의 현재 정렬로 보조 데이터베이스에 복제돼요. 따라서 보조 데이터베이스의 클러스터형 테이블에 대해 중복이 될 재클러스터링은 수행되지 않아요.

보조 데이터베이스에 클러스터형 테이블이 있고 그 데이터베이스가 기본 데이터베이스로 승격되면 Snowflake는 이 데이터베이스의 테이블에 대한 자동 클러스터링을 시작하면서 동시에 이전 기본 데이터베이스의 클러스터형 테이블 모니터링을 일시 중지해요.

구체화된 뷰의 자동 클러스터링 정보는 (이 토픽의) 복제와 구체화된 뷰 를 참고해요.

복제와 크고 변동이 심한 테이블

테이블의 한 개 이상의 행이 업데이트되거나 삭제되면 기본 데이터베이스에서 이 데이터를 저장하는 영향을 받은 모든 마이크로 파티션이 다시 생성되고 보조 데이터베이스와 동기화되어야 해요. 크고 변동이 심한 디멘전(dimension) 테이블의 경우 복제 비용이 상당할 수 있어요.

복제 비용이 큰 크고 변동이 심한 디멘전 테이블에는 다음 완화 방법을 사용할 수 있어요.

그러한 테이블을 저장하는 기본 데이터베이스를 더 낮은 빈도로 복제해요.
변동을 줄이도록 데이터 모델을 변경해요.

자세한 내용은 크고 변동이 심한 테이블의 비용 관리 를 참고해요.

복제와 Time Travel

Time Travel 및 Fail-safe 데이터는 보조 데이터베이스에 대해 독립적으로 유지되며 기본 데이터베이스에서 복제되지 않아요. Time Travel을 사용해 보조 데이터베이스의 테이블과 뷰를 쿼리하면 기본 데이터베이스에서 같은 쿼리를 실행할 때와 다른 결과가 나올 수 있어요.

과거 데이터(Historical Data): 기본 데이터베이스에서 Time Travel로 쿼리할 수 있는 과거 데이터는 보조 데이터베이스로 복제되지 않아요.

예를 들어 Snowpipe를 사용해 10분마다 데이터를 테이블에 지속적으로 로드하고 보조 데이터베이스를 1시간마다 새로고침한다고 가정해요. 새로고침 작업은 테이블의 최신 버전만 복제해요. 보존 기간 내의 매 시간 버전은 Time Travel로 쿼리할 수 있지만, 매시간 내의 반복 버전(개별 Snowpipe 로드)은 사용할 수 없어요.

데이터 보존 기간(Data Retention Period): 보조 데이터베이스 테이블의 데이터 보존 기간은 보조 데이터베이스가 기본 데이터베이스의 테이블에 기록된 DML 작업(즉 데이터 변경 또는 삭제)으로 새로고침될 때 시작돼요.

참고: 데이터 보존 기간 파라미터인 DATA_RETENTION_TIME_IN_DAYS 는 보조 데이터베이스의 데이터베이스 객체에만 복제되지 데이터베이스 자체에는 복제되지 않아요. 파라미터 복제에 대한 자세한 내용은 파라미터 를 참고해요.

복제와 구체화된 뷰

기본 데이터베이스에서 Snowflake는 구체화된 뷰의 자동 백그라운드 유지 관리를 수행해요. 기본 테이블이 변경되면 테이블에 정의된 모든 구체화된 뷰가 Snowflake가 제공하는 컴퓨팅 리소스를 사용하는 백그라운드 서비스에 의해 업데이트돼요. 또한 구체화된 뷰에 자동 클러스터링이 활성화되어 있으면 기본 데이터베이스에서 뷰가 모니터링되고 필요에 따라 재클러스터링돼요.

새로고침 작업은 구체화된 뷰 정의 를 보조 데이터베이스로 복제하며, 구체화된 뷰 데이터 는 복제되지 않아요. 보조 데이터베이스에서 구체화된 뷰의 자동 백그라운드 유지 관리는 기본적으로 활성화돼요. 기본 데이터베이스에서 구체화된 뷰에 자동 클러스터링이 활성화되어 있으면 보조 데이터베이스에서도 구체화된 뷰의 자동 모니터링과 재클러스터링이 활성화돼요.

참고: 구체화된 뷰의 자동 백그라운드 동기화 비용은 보조 데이터베이스를 포함하는 각 계정에 청구돼요.

복제와 Apache Iceberg™ 테이블

Iceberg 테이블에 복제를 사용할 때 다음 사항을 고려해요.

Snowflake는 현재 Snowflake 관리형 테이블의 복제만 지원해요.
변환된(converted) Iceberg 테이블의 복제는 지원되지 않아요. Snowflake는 새로고침 작업 중 변환된 테이블을 건너뜁니다.
복제된 테이블의 경우 타깃 계정과 같은 리전의 스토리지 위치에 대한 접근을 구성해야 해요.
기본 외부 볼륨에서 복제에 사용되는 스토리지 위치를 삭제하거나 변경하면 새로고침 작업이 실패할 수 있어요.
타깃 계정에서 보조 테이블은 타깃 계정을 소스 계정으로 승격할 때까지 읽기 전용이에요.
Snowflake는 보조 테이블에 대해 기본 Iceberg 테이블의 디렉터리 계층 구조를 유지해요.
이 기능에는 복제 비용이 적용돼요. 자세한 내용은 복제 비용 이해를 참고해요.
복제 및 장애 조치 그룹의 계정 객체에 대한 고려 사항은 계정 객체 를 참고해요.

복제와 다이내믹 테이블

다이내믹 테이블 복제 동작은 다이내믹 테이블을 포함하는 기본 데이터베이스가 복제 그룹의 일부인지 장애 조치 그룹의 일부인지에 따라 달라져요.

다이내믹 테이블과 복제 그룹

다이내믹 테이블을 포함하는 데이터베이스는 복제 그룹을 사용해 복제할 수 있어요. 그것이 의존하는 소스 객체는 같은 복제 그룹에 있어야 할 필요는 없어요.

각 타깃 계정의 복제된 객체는 보조(secondary) 객체라고 부르며 소스 계정의 기본(primary) 객체의 복제본이에요. 보조 객체는 타깃 계정에서 읽기 전용 이에요. 타깃 계정에서 보조 복제 그룹이 삭제되면 그 그룹에 포함된 데이터베이스는 읽기/쓰기가 돼요. 그러나 복제 그룹에 포함된 다이내믹 테이블은 타깃 계정에서 보조 그룹이 삭제된 후에도 읽기 전용으로 유지 돼요. 이러한 읽기 전용 다이내믹 테이블에서는 DML이나 다이내믹 테이블 새로고침이 발생할 수 없어요.

다이내믹 테이블과 장애 조치 그룹

다이내믹 테이블을 포함하는 데이터베이스는 장애 조치 그룹을 사용해 복제할 수 있어요. 다이내믹 테이블이 장애 조치 그룹이나 데이터베이스 복제 밖의 소스 객체를 참조하더라도 여전히 복제될 수 있어요. 장애 조치 후 다이내믹 테이블은 새로고침 중 이름 확인(name resolution)을 사용해 소스 객체를 해석해요. 새로고침은 소스 객체의 상태에 따라 성공하거나 실패할 수 있어요. 성공하면 다이내믹 테이블이 소스 객체의 최신 데이터로 다시 초기화돼요.

보조 다이내믹 테이블은 읽기 전용이며 새로고침되지 않아요. 장애 조치가 발생하고 보조 다이내믹 테이블이 기본 다이내믹 테이블로 승격된 후 첫 새로고침은 재초기화이며, 그 다음부터는 다이내믹 테이블이 데이터의 증분 새로고침으로 구성된 경우 증분 새로고침이 이어져요.

참고: 소스 객체와 다이내믹 테이블이 동일한 복제 스냅샷을 공유한다는 보장이 없으므로 재초기화된 다이내믹 테이블은 원래 복제본과 다를 수 있어요.

예제: 누락된 소스 객체로 인한 새로고침 실패

[IMAGE: Simple diagram of refresh failure due to missing source objects.]

다이내믹 테이블이 장애 조치 그룹 밖의 소스 테이블에 의존하면 장애 조치 후 새로고침할 수 없어요. 위 다이어그램에서 기본 계정의 다이내믹 테이블 dt 는 보조 계정으로 복제돼요. dt 는 기본 계정과 같은 장애 조치 그룹에 포함되지 않은 source_table 에 의존해요. 장애 조치 후 source_table 을 해석할 수 없으므로 보조 계정의 새로고침이 실패해요.

예제: 별도 복제를 통해 소스 객체가 보조 계정에 존재하는 경우 새로고침 성공

[IMAGE: Simple diagram of successful refresh with different failover groups.]

위 다이어그램에서 다이내믹 테이블 dt 는 source_table 에 의존해요. 기본 계정의 dt 와 source_table 모두 독립적인 장애 조치 그룹을 통해 보조 계정으로 복제돼요. 복제와 장애 조치 후 보조 계정에서 dt 를 새로고침하면 이름 확인을 통해 source_table 을 찾을 수 있으므로 새로고침이 성공해요.

예제: 소스 객체가 보조 계정에 로컬로 존재하는 경우 새로고침 성공

[IMAGE: Simple diagram of successful refresh with different failover groups.]

위 다이어그램에서 다이내믹 테이블 dt 는 source_table 에 의존하며 장애 조치 그룹을 통해 기본 계정에서 보조 계정으로 복제돼요. source_table 은 보조 계정에 로컬로 생성돼요. 장애 조치 후 보조 계정에서 dt1 을 새로고침하면 이름 확인을 통해 source_table 을 찾을 수 있으므로 새로고침이 성공할 수 있어요.

복제와 Snowpipe Streaming

기본 데이터베이스에서 Snowpipe Streaming 으로 채워진 테이블은 타깃 계정의 보조 데이터베이스로 복제돼요.

기본 데이터베이스에서 채널(channels) 을 통해 테이블이 생성되고 행이 삽입돼요. 오프셋 토큰(offset tokens) 이 수집 진행 상황을 추적해요. 새로고침 작업은 기본 데이터베이스에서 보조 데이터베이스로 테이블 객체, 테이블 데이터, 테이블과 관련된 채널 오프셋을 복제해요.

Snowpipe Streaming 아키텍처

Snowflake는 Snowpipe Streaming에 대해 두 가지 기본 아키텍처를 지원하며, 이에 따라 사용 가능한 클라이언트 API와 성능 특성이 달라져요.

클래식 아키텍처의 Snowpipe Streaming

읽기 전용 작업(소스 및 타깃 계정에서 사용 가능):

channel getLatestCommittedOffsetToken API
SHOW CHANNELS 명령

쓰기 작업(소스 계정에서만 사용 가능):

client openChannel API
channel insertRow API
channel insertRows API

고성능 아키텍처의 Snowpipe Streaming

이 아키텍처는 대량 작업과 향상된 상태 확인을 포함한 최적화된 기능을 제공하며, 대용량의 복제된 환경 관리에 중요해요.

아래 설명된 모든 기능은 Snowpipe Streaming SDK 와 Snowpipe Streaming REST API 를 통해 접근할 수 있어서 인프라 요구 사항에 따라 유연하게 통합할 수 있어요.

쓰기 및 관리 작업(소스 계정에서만 사용 가능):

채널 수명 주기 관리: 데이터 스트림을 설정하는 데 필요한 수집 채널을 열고 관리해요. 예를 들어 Java SDK의 openChannel 메서드예요.
트랜잭션 일관성 있는 수집: 행을 추가하는 핵심 기능이에요. 여기에 삽입된 데이터는 커밋되면 복제 스냅샷에 포함되는 것이 보장돼요. 예를 들어 Java SDK의 appendRows 메서드예요.
오프셋 토큰 추적: 최신 커밋된 오프셋 토큰을 검색해 수집 중 데이터 무결성을 보장하고 중복을 방지해요. 예를 들어 Java SDK의 getLatestCommittedOffsetToken 메서드예요.
대량 상태 모니터링: 여러 채널에 걸쳐 상태와 지연 메트릭을 효율적으로 모니터링해요. 복제가 발생하기 전에 데이터 지연이 허용 가능한지 확인하는 데 중요해요. 예를 들어 Java SDK의 getChannelStatus 메서드예요.

읽기 전용 작업(소스 및 타깃 계정 모두에서 사용 가능):

채널 검사: SHOW CHANNELS와 같은 메타데이터 명령을 사용해 복제된 환경 전체에서 기존 수집 채널의 구성 세부 정보, 상태, 속성을 봐요.

데이터 손실 방지

장애 조치 시 데이터 손실을 피하려면 업스트림 데이터 소스에서 성공적으로 삽입된 행의 데이터 보존 시간이 구성된 복제 일정보다 길어야 해요. 기본 데이터베이스의 테이블에 데이터가 삽입되고 보조 데이터베이스로 복제되기 전에 장애 조치가 발생하면, 같은 데이터를 새로 승격된 기본 데이터베이스의 테이블에 다시 삽입해야 해요. 다음 예제는 장애 조치 시나리오를 보여줘요.

기본 데이터베이스 repl_db의 테이블 t1이 Snowpipe Streaming과 Kafka 커넥터로 데이터로 채워져 있어요.
기본 데이터베이스의 t1에 대한 채널 1의 offsetToken은 100이고 채널 2의 offsetToken은 100이에요.
타깃 계정에서 새로고침 작업이 성공적으로 완료돼요.
보조 데이터베이스의 t1에 대한 채널 1과 채널 2의 offsetToken은 100이에요.
기본 데이터베이스의 t1에 더 많은 행이 삽입돼요.
기본 데이터베이스의 t1에 대한 채널 1과 채널 2의 offsetToken은 이제 200이에요.
추가 행과 새 채널 오프셋이 보조 데이터베이스로 복제되기 전에 장애 조치가 발생해요.

이 경우 새로 승격된 기본 데이터베이스의 테이블 t1 에 대해 각 채널에 100개의 누락 오프셋이 있어요. 누락된 데이터를 삽입하려면 새로 승격된 소스 계정에서 Snowpipe Streaming 활성 채널 다시 열기 를 참고해요.

복제 지원 요구 사항

클래식 아키텍처의 Snowpipe Streaming

클래식 아키텍처에 대한 Snowpipe Streaming 복제 지원에는 다음 최소 버전이 필요해요.

Snowflake Ingest SDK 버전 1.1.1 이상.
Kafka 커넥터를 사용하는 경우: Kafka 커넥터 버전 1.9.3 이상.

고성능 아키텍처의 Snowpipe Streaming

고성능 아키텍처에 대한 Snowpipe Streaming 복제 지원에는 다음 최소 버전이 필요해요.

Snowpipe Streaming SDK 버전 1.1.0 이상.

두 아키텍처의 데이터 보존 요구 사항

업스트림 데이터 소스에서 성공적으로 삽입된 행의 데이터 보존 시간은 구성된 복제 일정보다 길어야 해요. Kafka 커넥터를 사용한다면 log.retention 구성에 충분한 버퍼가 설정되어 있는지 확인해요.

복제와 스테이지

스테이지 객체에는 다음 제약 사항이 적용돼요.

Snowflake는 현재 그룹 기반 복제(복제 및 장애 조치 그룹)의 일부로 스테이지 복제를 지원해요. 데이터베이스 복제에서는 스테이지 복제가 지원되지 않아요.
외부 스테이지를 복제할 수 있어요. 다만 외부 스테이지의 파일은 복제되지 않아요.
내부 스테이지를 복제할 수 있어요. 내부 스테이지의 파일을 복제하려면 스테이지에서 디렉터리 테이블을 활성화해야 해요. Snowflake는 디렉터리 테이블이 매핑한 파일만 복제해요.
디렉터리 테이블이 있는 내부 스테이지를 복제할 때는 기본 또는 보조 스테이지에서 디렉터리 테이블을 비활성화할 수 없어요. 디렉터리 테이블에는 복제된 파일과 COPY 문으로 로드된 파일에 대한 중요한 정보가 들어 있어요.
내부 스테이지의 디렉터리 테이블에 5GB보다 큰 파일이 있으면 새로고침 작업이 실패해요. 이 제한을 해결하려면 5GB보다 큰 파일을 다른 스테이지로 옮겨요. 기본 또는 보조 스테이지, 또는 이전에 복제된 적이 있는 스테이지에서는 디렉터리 테이블을 비활성화할 수 없어요. 스테이지를 포함하는 데이터베이스를 복제/장애 조치 그룹에 추가하기 전에 다음 단계를 따르세요.
- 기본 스테이지의 디렉터리 테이블을 비활성화해요.
- 5GB보다 큰 파일을 디렉터리 테이블이 활성화되지 않은 다른 스테이지로 옮겨요.
- 파일을 다른 스테이지로 옮긴 후 기본 스테이지의 디렉터리 테이블을 다시 활성화해요.
사용자 스테이지와 테이블 스테이지의 파일은 복제되지 않아요.
스토리지 통합을 사용하는 명명된 외부 스테이지의 경우 장애 조치 전에 타깃 계정에서 보조 스토리지 통합에 대한 신뢰 관계를 구성해야 해요. 자세한 내용은 보조 스토리지 통합을 위한 클라우드 스토리지 접근 구성 을 참고해요.
디렉터리 테이블이 있는 외부 스테이지를 복제하고 소스 디렉터리 테이블에 대해 자동 새로고침 을 구성했다면 장애 조치 전에 보조 디렉터리 테이블에 대해 자동 새로고침을 구성해야 해요. 자세한 내용은 보조 스테이지의 디렉터리 테이블에 대한 자동 새로고침 구성 을 참고해요.
복제된 스테이지의 디렉터리 테이블이 스테이지의 복제된 파일과 일치하지 않으면 복사(COPY) 명령이 예상보다 오래 걸릴 수 있어요. 디렉터리 테이블을 일치시키려면 ALTER STAGE … REFRESH 문으로 새로고침해요. 디렉터리 테이블의 일관성 상태를 확인하려면 SYSTEM$GET_DIRECTORY_TABLE_STATUS 함수를 사용해요.

복제와 파이프

파이프 객체에는 다음 제약 사항이 적용돼요.

Snowflake는 현재 그룹 기반 복제(복제 및 장애 조치 그룹)의 일부로 파이프 복제를 지원해요. 데이터베이스 복제에서는 파이프 복제가 지원되지 않아요.
Snowflake는 파이프가 대상 테이블과 같은 복제 그룹에 속할 때만 파이프의 복사 이력(copy history)을 복제해요.
알림 통합의 복제는 지원되지 않아요.
Snowflake는 최신 테이블 truncate 이후의 로드 이력만 복제해요.
알림을 받으려면 장애 조치 전에 타깃 계정에서 보조 자동 로드 파이프를 구성해야 해요. 자세한 내용은 보조 자동 로드 파이프에 대한 알림 구성을 참고해요.
장애 조치 후 예상 실행 상태가 아닌 파이프를 해결하려면 SYSTEM$PIPE_STATUS 함수를 사용해요.
Snowflake는 Kafka 커넥터가 있는 Snowpipe의 복제와 장애 조치를 지원하지 않지만, Kafka 커넥터가 있는 Snowpipe Streaming의 복제와 장애 조치는 지원해요. 자세한 내용은 Snowpipe Streaming과 Kafka 커넥터를 참고해요.

데이터 메트릭 함수(DMF)의 복제

DMF 복제에는 다음 동작이 적용돼요.

이벤트 테이블 — DMF를 수동으로 호출하거나 예약했을 때 결과를 저장하는 이벤트 테이블은 Snowflake 계정에 로컬이므로 복제되지 않아요. Snowflake는 이벤트 테이블 복제를 지원하지 않아요.

복제 그룹 — DMF를 포함하는 데이터베이스를 복제 그룹에 추가하면 타깃 계정에서 다음이 발생해요.

DMF가 소스 계정에서 복제돼요.
DMF 정의가 지정하는 테이블이나 뷰(예: 외래 키 참조로)는 Cross-Cloud Auto-Fulfillment와 연관되어 있지 않으면 소스 계정에서 복제돼요.
타깃 계정의 예약된 DMF는 일시 중지돼요. 보조 DMF는 타깃 계정을 소스 계정으로 승격하고 보조 DMF가 기본 DMF가 되면 일정을 재개해요.

장애 조치 그룹 — 장애 조치 그룹을 사용해 DMF를 포함하는 데이터베이스를 복제하면 장애 조치 시 다음이 발생해요.

타깃 계정을 소스 계정으로 승격하면 일시 중지된 DMF의 일정을 재개해요.
다른 계정을 소스 계정으로 승격한 후 타깃 계정에서 예약된 DMF를 일시 중지해요.

DMF를 포함하는 데이터베이스를 타깃 계정으로 복제하지 않으면 새로 승격된 소스 계정에서 사용할 수 없으므로 타깃 계정이 소스 계정으로 승격될 때 테이블이나 뷰에 대한 DMF 연결이 삭제돼요.

팁: 계정을 장애 조치하기 전에 DMF 참조를 확인 하세요. DATA_METRIC_FUNCTION_REFERENCES Information Schema 테이블 함수를 호출해 승격 및 새로고침 작업 전에 DMF와 연결된 테이블 객체를 확인해요.

저장 프로시저와 사용자 정의 함수(UDF)의 복제

저장 프로시저와 UDF는 기본 데이터베이스에서 보조 데이터베이스로 복제돼요.

저장 프로시저와 UDF 및 스테이지

저장 프로시저나 UDF가 스테이지의 파일에 의존하면(예: 스테이지에서 업로드한 Python 코드로 정의된 저장 프로시저) 스테이지와 그 파일을 보조 데이터베이스로 복제해야 해요. 스테이지 복제에 대한 자세한 내용은 스테이지, 파이프, 로드 이력 복제 를 참고해요.

예를 들어 기본 데이터베이스에 스테이지에 저장된 코드를 가져오는 인라인 Python UDF가 있으면 스테이지와 가져온 코드가 보조 데이터베이스에서 복제되지 않는 한 UDF가 작동하지 않아요.

저장 프로시저와 UDF 및 외부 네트워크 접근

저장 프로시저나 UDF가 외부 네트워크 위치 에 대한 접근에 의존하면 다음 객체를 복제해야 해요.

복제/장애 조치 그룹의 allowed_integration_types 목록에 EXTERNAL ACCESS INTEGRATIONS를 포함해야 해요.
네트워크 규칙을 포함하는 데이터베이스.
외부 네트워크 위치와 인증하기 위한 자격 증명을 저장하는 시크릿을 포함하는 데이터베이스.
시크릿 객체가 보안 통합을 참조하면 복제/장애 조치 그룹의 allowed_integration_types 목록에 SECURITY INTEGRATIONS를 포함해야 해요.

복제와 스토리지 수명 주기 정책

Snowflake는 스토리지 수명 주기 정책(storage lifecycle policies) 과 정책의 테이블과의 연결을 타깃 계정으로 복제하지만, 정책을 실행하지는 않아요. Snowflake는 COOL 또는 COLD 티어의 아카이브 데이터를 복제하지 않아요. 소스 계정의 아카이브 데이터는 타깃 계정에서 사용할 수 없어요.

타깃 계정으로 장애 조치한 후 Snowflake는 원래 소스 계정에서 스토리지 수명 주기 정책 실행을 일시 중지해요. 소스 계정으로 복구(failback) 한 후 Snowflake는 정책 실행을 재개해요.

Snowflake는 장애 조치 후에도 보조 테이블에 대해 보조 스토리지 수명 주기 정책을 자동으로 실행하지 않아요. 하지만 타깃 계정에서 보조 정책을 새 테이블에 연결해 사용할 수 있어요. Snowflake는 그 새 테이블에 대해 정책을 실행해요.

복제와 스트림

이 섹션은 여러 계정 간 데이터베이스 복제 또는 계정 복제 및 장애 조치/복구 에서 스트림을 복제할 때 권장되는 모범 사례와 잠재적 우려 영역을 설명해요.

스트림에 대해 지원되는 소스 객체

복제된 스트림은 같은 데이터베이스의 테이블과 뷰에 대한 변경 데이터를 성공적으로 추적할 수 있어요.

현재 다음 소스 객체 유형은 지원되지 않아요.

외부 테이블
스트림 데이터베이스와 별도의 데이터베이스에 있는 테이블 또는 뷰. 단, 스트림 데이터베이스와 소스 객체를 저장하는 데이터베이스가 모두 동일한 복제/장애 조치 그룹에 포함된 경우는 예외예요.
공유 데이터베이스(즉 프로바이더 계정에서 내 계정으로 공유된 데이터베이스)의 테이블 또는 뷰.

스테이지, 파이프, 로드 이력 복제 를 활성화하면 디렉터리 테이블의 스트림 복제가 지원돼요.

기본 데이터베이스에 지원되지 않는 소스 객체를 가진 스트림이 포함되어 있으면 데이터베이스 복제 또는 새로고침 작업이 실패해요. 스트림의 소스 객체가 삭제된 경우에도 작업이 실패해요.

추가 전용(append-only) 스트림은 복제된 소스 객체에서 지원되지 않아요.

데이터 중복 방지

참고: 이 섹션에서 설명하는 시나리오 외에도 보조 데이터베이스의 스트림은 새로고침 작업에 처음 포함될 때 중복 행을 반환할 수 있어요. 이 경우 중복 행 은 단일 행에 METADATA$ACTION 컬럼 값이 여러 개 있는 것을 말해요.

초기 새로고침 작업 후에는 보조 데이터베이스에서 이 특정 문제가 발생하지 않아야 해요.

데이터 중복은 DML 작업이 고유성 검사 없이 스트림의 동일한 변경 데이터를 여러 번 기록할 때 발생해요. 이는 스트림과 스트림 변경 데이터의 대상 테이블이 별도의 데이터베이스에 저장되고, 이 데이터베이스들이 같은 그룹에서 복제 및 장애 조치되지 않을 때 발생할 수 있어요.

예를 들어 스트림 s 의 변경 데이터를 테이블 dt 에 정기적으로 삽입한다고 가정해요. (이 예제에서 스트림의 소스 객체는 중요하지 않아요.) 별도의 데이터베이스가 스트림과 대상 테이블을 저장해요.

타임스탬프 t1 에 스트림 s 의 소스 테이블에 행이 삽입되어 새 테이블 버전이 생성돼요. 스트림은 이 테이블 버전의 오프셋을 저장해요.
타임스탬프 t2 에 스트림을 저장하는 보조 데이터베이스가 새로고침돼요. 복제된 스트림 s 가 이제 오프셋을 저장해요.
타임스탬프 t3 에 스트림 s 의 변경 데이터가 테이블 dt 에 삽입돼요.
타임스탬프 t4 에 스트림 s 를 저장하는 보조 데이터베이스가 장애 조치돼요.
타임스탬프 t5 에 스트림 s 의 변경 데이터가 다시 테이블 dt 에 삽입돼요.

이 상황을 피하려면 스트림과 그 대상 테이블을 저장하는 데이터베이스를 함께 복제하고 장애 조치해요.

태스크 WHEN 절의 스트림 참조

WHEN boolean_expr 절에서 스트림을 참조하는 복제된 태스크를 실행할 때 예기치 않은 동작을 피하려면 다음 중 하나를 권장해요.

태스크와 스트림을 같은 데이터베이스에 만들거나,
스트림이 이를 참조하는 태스크와 다른 데이터베이스에 저장되어 있다면 두 데이터베이스를 같은 장애 조치 그룹에 포함해요.

태스크가 별도의 데이터베이스에 있는 스트림을 참조하고 두 데이터베이스가 같은 장애 조치 그룹에 포함되지 않으면, 스트림을 포함하는 데이터베이스 없이 태스크를 포함하는 데이터베이스가 장애 조치될 수 있어요. 이 시나리오에서는 태스크가 장애 조치된 데이터베이스에서 재개될 때 실행을 시도하다가 참조된 스트림을 찾지 못해 오류를 기록해요. 이 문제는 스트림을 포함하는 데이터베이스를 장애 조치하거나 태스크를 포함하는 장애 조치된 데이터베이스와 같은 계정에서 데이터베이스와 스트림을 다시 만드는 방식으로 해결할 수 있어요.

스트림 부실(Staleness)

기본 데이터베이스의 스트림이 부실(stale) 해지면 보조 데이터베이스의 복제된 스트림도 부실해지며 쿼리하거나 변경 데이터를 소비할 수 없어요. 이 문제를 해결하려면 기본 데이터베이스에서 스트림을 다시 만들어요(CREATE OR REPLACE STREAM 사용). 보조 데이터베이스가 새로고침되면 복제된 스트림이 다시 읽을 수 있게 돼요.

다시 만든 스트림의 오프셋은 기본적으로 현재 테이블 버전이에요. Time Travel을 사용해 이전 테이블 버전을 가리키는 스트림을 다시 만들 수도 있지만, 복제된 스트림은 읽을 수 없는 상태로 유지돼요. 자세한 내용은 (이 토픽의) 스트림 복제와 Time Travel 을 참고해요.

스트림 복제와 Time Travel

기본 데이터베이스가 장애 조치된 후 데이터베이스의 스트림이 Time Travel 을 사용해 마지막 새로고침 타임스탬프 이전의 시점에서 소스 객체에 대한 테이블 버전 을 읽으면 복제된 스트림을 쿼리하거나 변경 데이터를 소비할 수 없어요. 마찬가지로 CHANGES 절을 사용해 SELECT 문의 소스 객체에 대한 변경 데이터를 마지막 새로고침 타임스탬프 이전의 시점에서 쿼리하면 오류와 함께 실패해요.

이것은 새로고침 작업이 테이블 이력을 단일 테이블 버전으로 축소하기 때문이에요. 새로고침 작업 타임스탬프 이전에 생성된 반복 테이블 버전은 복제된 소스 객체의 테이블 이력에 보존되지 않아요.

다음 예제를 고려해요.

[IMAGE: Stream replication and Time Travel]

테이블 t1 이 변경 추적이 활성화된 기본 데이터베이스에 생성돼요(테이블 버전 tv0). 이후 DML 트랜잭션이 테이블 버전 tv1 과 tv2 를 만들어요.
테이블 t1 을 포함하는 보조 데이터베이스가 새로고침돼요. 이 복제된 테이블의 테이블 버전은 tv2 이지만 테이블 이력은 복제되지 않아요.
Time Travel을 사용해 오프셋이 테이블 버전 tv1 로 설정된 스트림이 기본 데이터베이스에 생성돼요.
보조 데이터베이스가 장애 조치되어 기본 데이터베이스가 돼요.
테이블 버전 tv1 이 테이블 이력에 없으므로 스트림 s1 을 쿼리하면 오류가 반환돼요.

테이블 t1 에 대한 이후 DML 트랜잭션이 테이블 버전을 tv3 로 진행하면 스트림 s1 의 오프셋이 전진한다는 점에 유의해요. 스트림이 다시 읽을 수 있게 돼요.

데이터 손실 방지

보조 데이터베이스에 대한 가장 최근의 새로고침 작업이 장애 조치 작업 전에 완료되지 않으면 데이터 손실이 발생할 수 있어요. 위험을 최소화하려면 보조 데이터베이스를 자주 새로고침하는 것을 권장해요.

복제와 태스크

이 섹션은 여러 계정 간 데이터베이스 복제 또는 계정 복제 및 장애 조치/복구 에서 태스크 복제를 설명해요.

복제 시나리오

태스크의 복제 동작은 태스크가 복제/장애 조치 그룹 으로 복제되는지 데이터베이스 복제 로 복제되는지에 따라 달라져요.

복제 그룹과 장애 조치 그룹

태스크가 복제 그룹이나 장애 조치 그룹으로 복제되면 복제 새로고침 시작 시점에 복제된 데이터베이스에 있는 모든 태스크가 복제돼요. 기본 데이터베이스의 최신 태스크 상태가 그대로 보조 데이터베이스로 복제돼요.

변경 시점	복제 동작
새로고침 시작 전	새로고침에 포함됨
새로고침 시작 후	다음 새로고침까지 포함되지 않음

데이터베이스 복제

참고: 태스크 그래프가 복제를 수행하는 역할과 다른 역할이 소유한 경우 데이터베이스 복제는 태스크 그래프에서 작동하지 않아요.

태스크가 데이터베이스 복제 로 복제되면 복제 동작은 최신 태스크 버전에 기반해요. 다음 표는 서로 다른 태스크 시나리오를 설명하고 태스크가 복제되는지 여부를 지정해요. 별도로 명시되지 않는 한 시나리오는 독립형 태스크와 태스크 그래프 의 태스크 모두에 적용돼요.

시나리오	복제	비고
태스크가 생성되고 재개(resume)되거나 수동으로 실행(EXECUTE TASK 사용)됨. 태스크를 재개하거나 실행하면 초기 태스크 버전이 생성돼요.	✔
태스크가 생성되었지만 재개되거나 실행된 적이 없음.	❌
태스크가 다시 생성됨(CREATE OR REPLACE TASK로 생성했지만 재개되거나 실행된 적이 없음).	✔	태스크가 다시 생성되기 전의 최신 버전이 복제돼요. 태스크를 재개하거나 수동으로 실행하면 새 버전이 커밋돼요. 데이터베이스가 다시 복제되면 새 최신 버전이 보조 데이터베이스로 복제돼요.
태스크가 생성되고 재개되거나 실행되었지만 이후 삭제됨.	❌
태스크 그래프가 생성되고 재개되거나 실행됨. 이후 태스크 그래프의 태스크가 수정되었지만 태스크 그래프의 루트 태스크가 다시 재개되거나 실행되지 않음. 수정의 예는 다음과 같아요: 루트 태스크, 자식 태스크 또는 파이널라이저 태스크에 ALTER TASK … SET/UNSET/MODIFY 사용, 자식 태스크 또는 파이널라이저 태스크에 ALTER TASK … SUSPEND 사용.	✔	태스크가 수정되기 전의 태스크 그래프의 최신 버전이 복제돼요. 태스크를 재개하거나 수동으로 실행하면 태스크 그래프 내 태스크의 파라미터 변경을 포함하는 새 버전이 커밋돼요. 새 변경 사항은 커밋된 적이 없으므로 태스크 그래프의 이전 버전만 복제돼요. 수정된 태스크 그래프가 보존 기간(현재 30일) 내에 재개되지 않으면 태스크의 최신 버전이 삭제된다는 점에 유의하세요. 이 기간 후에는 다시 재개되지 않는 한 태스크가 보조 데이터베이스로 복제되지 않아요.
태스크 그래프의 루트 태스크가 생성되고 재개되거나 실행되었지만 이후 일시 중지되고 삭제됨.	❌	전체 태스크 그래프가 보조 데이터베이스로 복제되지 않아요.
태스크 그래프의 자식 태스크가 생성되고 재개되거나 실행되었지만 이후 일시 중지되고 삭제됨.	✔	태스크 그래프의 최신 버전(태스크가 일시 중지되고 삭제되기 전)이 보조 데이터베이스로 복제돼요.

복제된 태스크의 재개 또는 일시 중지 상태

참고: 보조 데이터베이스의 태스크는 상태와 관계없이 장애 조치 후까지 예약되지 않아요. 자세한 내용은 장애 조치 후 태스크 실행 을 참고해요.

복제 그룹과 장애 조치 그룹

다음 두 조건이 모두 충족되면 태스크가 재개된 상태로 보조 데이터베이스에 복제돼요.

복제 또는 새로고침 작업이 시작될 때 태스크가 기본 데이터베이스에서 재개된 상태인 경우.
태스크 소유자 역할이 보조 데이터베이스에서 사용 가능한 경우.

두 조건 중 하나라도 충족되지 않으면 태스크가 일시 중지된 상태로 복제돼요.

복제된 태스크의 권한 부여에 대한 자세한 내용은 (이 토픽의) 복제된 태스크와 권한 부여 를 참고해요.

데이터베이스 복제

태스크가 데이터베이스 복제로(ALTER DATABASE … REFRESH 사용) 복제되면 태스크는 항상 일시 중지된 상태로 복제돼요.

복제된 태스크와 권한 부여

태스크 권한 부여를 복제하는 로직은 태스크가 복제/장애 조치 그룹 으로 복제되는지 데이터베이스 복제로 복제되는지에 따라 달라져요.

복제 그룹과 장애 조치 그룹

역할 객체가 보조 데이터베이스에서 사용 가능하면 태스크 권한 부여가 복제돼요. 역할과 태스크가 다른 복제/장애 조치 그룹에 있으면 태스크를 포함하는 그룹을 새로고침하기 전에 역할을 포함하는 그룹을 새로고침해요.

현재 태스크 소유자 역할이 보조 데이터베이스에서 사용 가능하면 태스크에 대한 모든 현재 권한 부여가 보조 데이터베이스로 복제돼요.
현재 태스크 소유자 역할을 사용할 수 없으면 태스크는 보조 데이터베이스에서 새로고침을 수행하는 역할이 소유해요.

데이터베이스 복제

태스크가 데이터베이스 복제로(ALTER DATABASE … REFRESH 사용) 복제되면 태스크에 대한 권한 부여는 보조 데이터베이스로 복제되지 않아요.

장애 조치 후 태스크 실행

보조 장애 조치 그룹이 기본 그룹으로 승격된 후에는 장애 조치 그룹의 데이터베이스에서 재개된 독립형 태스크와 재개된 루트 태스크가 있는 태스크 그래프가 점진적으로 예약돼요. 재개된 자식 태스크는 루트 태스크도 재개되지 않는 한 자동으로 실행되지 않아요. 정상적인 일정을 복원하는 데 필요한 시간은 데이터베이스의 재개된 태스크 수에 따라 달라져요.

복제와 dbt 프로젝트

dbt 프로젝트 객체는 기본 데이터베이스에서 보조 데이터베이스로 복제돼요.
보조 데이터베이스를 포함한 타깃 계정의 모든 보조 객체는 읽기 전용이에요. 보조 dbt 프로젝트는 실행할 수 없어요.
dbt 프로젝트가 참조하는 객체(예: 소스 테이블과 뷰)는 장애 조치 후 해당 dbt 프로젝트의 실행이 성공하도록 dbt 프로젝트와 함께 복제해야 해요.

dbt 프로젝트와 외부 네트워크 접근

dbt 프로젝트가 외부 네트워크 위치 에 대한 접근에 의존하면 다음 객체를 복제해야 해요.

복제/장애 조치 그룹의 allowed_integration_types 목록에 EXTERNAL ACCESS INTEGRATIONS를 포함해야 해요.
네트워크 규칙을 포함하는 데이터베이스.
외부 네트워크 위치와 인증하기 위한 자격 증명을 저장하는 시크릿을 포함하는 데이터베이스.
시크릿 객체가 보안 통합을 참조하면 복제/장애 조치 그룹의 allowed_integration_types 목록에 SECURITY INTEGRATIONS를 포함해야 해요.

dbt 프로젝트는 자신과 연결된 외부 네트워크 접근 통합을 저장하지 않아요. 외부 네트워크 접근 통합은 사용자가 EXECUTE DBT PROJECT 명령을 실행할 때 지정돼요. 따라서 외부 접근 통합을 별도로 복제해야 한다는 요구 사항이 더 분명해져요.

복제와 DCM 프로젝트

DCM 프로젝트 객체는 복제/장애 조치 그룹에 포함될 수 있어요. 복제되면 프로젝트 객체 내에 저장된 모든 배포 아티팩트(정의, 구성, 계획 및 배포 결과 포함)가 보존되며 프로젝트 객체와 함께 복제돼요.
DCM 프로젝트는 자신이 관리하는 객체를 복제하지 않아요. 프로젝트가 배포하는 데이터베이스, 스키마, 테이블 같은 객체를 프로젝트와 같은 복제/장애 조치 그룹에 포함해요.

장애 조치 후 DCM 프로젝트와 관리 객체

장애 조치 후 DCM 프로젝트가 관리하는 복제된 객체는 프로젝트에 자동으로 연결되어 관리되지 않아요. 다시 연결하려면 새 기본 계정에서 DCM 프로젝트의 전체 PLAN 및 DEPLOY 를 실행해요. 관리 객체는 이미 프로젝트의 마지막 배포 정의와 일치하므로, 이 배포는 각 객체가 DCM 프로젝트에 의해 다시 관리되는 것 외에는 변경 사항이 없을 것으로 예상돼요.

이러한 인계 단계는 개별 관리 객체가 이미 복제되어 그 자체로 사용 가능하므로 비즈니스 프로세스에 영향을 주지 않아요. 다만 장애 조치 후 첫 배포가 빈 변경 집합 대신 관리 객체의 인계를 보고한다는 의미일 뿐이에요. 그 이후부터 프로젝트는 장애 조치 전과 동일하게 동작해요.

DCM_DEPLOYMENT_HISTORY 정보 스키마 함수는 복제되지 않으므로, 장애 조치 후에는 해당 계정에서 수행된 배포만 표시해요. 프로젝트 객체 자체에 저장된 복제된 배포 이력을 검토하려면 SHOW DEPLOYMENTS IN DCM PROJECT 를 사용해요.

복제와 태그

태그와 태그 할당은 소스 계정에서 타깃 계정으로 복제할 수 있어요.

소스 계정에서 초기 복제 후에는 타깃 계정에서 태그 할당을 수정할 수 없어요. 예를 들어 보조(즉 복제된) 데이터베이스에 태그를 설정할 수 없어요. 타깃 계정에서 태그 할당을 수정하려면 소스 계정에서 수정한 다음 타깃 계정으로 복제해요.

태그를 성공적으로 복제하려면 복제/장애 조치 그룹에 다음이 포함되어 있는지 확인해요.

ALLOWED_DATABASES 속성의 태그를 포함하는 데이터베이스.
OBJECT_TYPES 속성에 태그가 있는 다른 계정 수준 객체(예: ROLES , WAREHOUSES ). 자세한 내용은 CREATE REPLICATION GROUP 및 CREATE FAILOVER GROUP 을 참고해요.

복제와 Snowflake 클래스 인스턴스

CUSTOM_CLASSIFIER 클래스의 인스턴스는 인스턴스를 포함하는 데이터베이스가 복제될 때 복제돼요. 다른 Snowflake 클래스 의 인스턴스 복제는 지원되지 않아요.

과거 사용량 데이터

기본 데이터베이스 활동에 대한 과거 사용량 데이터는 보조 데이터베이스로 복제되지 않아요. 각 계정에는 자체 쿼리 이력, 로그인 이력 등이 있어요.

과거 사용량 데이터에는 다음 Snowflake Information Schema 테이블 함수 또는 Account Usage 뷰가 반환하는 쿼리 데이터가 포함돼요.

COPY_HISTORY
LOGIN_HISTORY
QUERY_HISTORY
기타 등등

더 알아보기 (Learn more)

여러 계정 간 데이터베이스 및 계정 객체 복제 — 복제 구성 워크플로우
여러 계정 간 복제와 장애 조치 소개 — 복제 개념과 복제된 객체
스테이지, 파이프, 로드 이력 복제 — 데이터 파이프라인 객체 복제
여러 계정 간 보안 통합 및 네트워크 정책 복제 — 보안 통합 및 네트워크 정책 복제