복제 고려 사항

이 항목에서는 Snowflake에서 오브젝트, 특히 데이터베이스, 스키마 및 비임시 테이블을 복제할 때의 주요 고려 사항에 대해 설명합니다. DDL 및 DML 트랜잭션(소스 오브젝트에 대한), Time Travel 및 데이터 보존 기간과 같은 요소가 오브젝트 복제에 영향을 줄 수 있습니다.

이 항목의 내용:

복제된 오브젝트에 대한 액세스 제어 권한

원본 오브젝트가 데이터베이스 또는 스키마인 경우 복제본은 원본 오브젝트에 포함된 모든 하위 오브젝트의 복제본에 부여된 모든 권한을 상속합니다.

  • 데이터베이스의 경우, 포함된 오브젝트에는 스키마, 테이블, 뷰 등이 포함됩니다.

  • 스키마의 경우, 포함된 오브젝트에는 테이블, 뷰 등이 포함됩니다.

컨테이너 자체(데이터베이스 또는 스키마)의 복제본은 원본 컨테이너에 부여된 권한을 상속하지 않습니다.

대부분의 오브젝트에 대해 CREATE <오브젝트> … CLONE 문은 원본 오브젝트에 대해 부여된 권한을 오브젝트 복제본에 복사하지 않습니다. 하지만 COPY GRANTS 절을 지원하는 CREATE <오브젝트> 명령(예: CREATE TABLE, CREATE VIEW)을 사용하면 오브젝트 복제본에 대해 부여된 권한을 선택적으로 복사할 수 있습니다. 예를 들어, CREATE TABLE … CLONE 명령 구문은 COPY GRANTS 매개 변수를 지원합니다. CREATE TABLE 문에 COPY GRANTS 매개 변수를 지정하면 만들기 작업 수행 시 OWNERSHIP을 제외한 모든 권한이 원본 테이블에서 새 테이블로 복사됩니다. COPY GRANTS 절을 지원하는 다른 CREATE 명령에 대해서도 같은 동작이 이루어집니다.

다른 모든 경우에는 새로 생성된 복제본에 필요한 모든 권한을 부여해야 합니다(GRANT <권한> 사용).

복제 및 Snowflake 오브젝트

이 섹션에서는 특정 Snowflake 오브젝트와 관련된 특별 복제 고려 사항을 설명합니다.

복제 및 오브젝트 매개 변수

복제된 오브젝트는 해당 오브젝트가 복제될 때 원본 오브젝트에 설정된 모든 오브젝트 매개 변수를 상속합니다. 오브젝트 매개 변수가 오브젝트 컨테이너(즉, 계정, 데이터베이스, 스키마)에 설정될 수 있고 원본 오브젝트에 명시적으로 설정되지 않은 경우 오브젝트 복제는 기본 매개 변수 값 또는 최저 수준에서 재정의된 값을 상속합니다. 오브젝트 매개 변수에 대한 자세한 내용은 매개 변수 를 참조하십시오.

복제 및 기본 시퀀스

테이블에서 열은 기본 값을 생성하는 시퀀스 를 참조할 수 있습니다. 테이블이 복제될 때 복제된 테이블은 원본 또는 복제된 시퀀스를 참조합니다.

  • 테이블과 시퀀스가 모두 포함된 데이터베이스 또는 스키마가 복제될 때 복제된 테이블은 복제된 시퀀스를 참조합니다.

  • 그렇지 않으면, 복제된 테이블이 원본 시퀀스를 참조합니다.

    예를 들어, 다른 데이터베이스 또는 스키마에 시퀀스가 정의된 경우 복제된 테이블은 원본 시퀀스를 참조합니다. 아니면, 테이블 자체만을 복제하는 경우 복제된 테이블은 원본 시퀀스를 참조합니다.

    새 테이블에서 원본 시퀀스를 사용하지 않으려면 다음 명령을 실행합니다.

    ALTER TABLE <table_name> ALTER COLUMN <column_name> SET DEFAULT <new_sequence>.nextval;
    

복제 및 외래 키 제약 조건

테이블에는 기본 키를 포함하는 테이블을 참조하는 외래 키 제약 조건이 있을 수 있습니다. 외래 키 제약 조건이 있는 테이블이 복제될 때, 복제된 테이블은 기본 키를 포함하는 원본 테이블이나 복제된 테이블을 참조합니다.

  • 두 테이블이 모두 포함된 데이터베이스나 스키마가 복제된 경우에는 외래 키가 있는 복제된 테이블이 복제된 다른 테이블의 기본 키를 참조합니다.

  • 테이블이 별도의 데이터베이스 또는 스키마에 있는 경우 복제된 테이블은 원본 테이블의 기본 키를 참조합니다.

복제 및 클러스터링 키

테이블에는 유사한 행을 같은 마이크로 파티션에 배치하기 위해 클러스터링 키 로 지정된 열의 하위 세트가 있을 수 있습니다. 클러스터링 키가 있는 테이블이 복제되면 새 테이블이 클러스터링 키와 함께 생성됩니다. 기본적으로, 자동 클러스터링 은 새 테이블에 대해 일시 중단됩니다. 새 테이블에 대한 자동 클러스터링을 재개하려면 다음 명령을 실행하십시오.

ALTER TABLE <name> RESUME RECLUSTER

복제 및 스테이지

명명된 개별 외부 스테이지를 복제할 수 있습니다. 외부 스테이지는 외부 클라우드 저장소의 버킷 또는 컨테이너를 참조하며, 외부 스테이지를 복제해도 참조된 클라우드 저장소에는 영향을 주지 않습니다.

명명된 내부(즉, Snowflake) 스테이지는 복제할 수 없습니다.

데이터베이스 또는 스키마를 복제할 때:

  • 복제 작업이 시작될 때 원본에 있는 명명된 외부 스테이지가 복제됩니다.

  • 테이블이 복제됩니다. 즉, 각 테이블와 연결된 내부 스테이지도 복제됩니다. 원본 데이터베이스 또는 스키마의 테이블 스테이지에 있는 모든 데이터 파일은 복제본에 복사되지 않습니다(즉, 복제된 테이블 스테이지가 비어 있음).

  • 명명된 내부 스테이지는 복제되지 않습니다.

복제 및 파이프

데이터베이스 또는 스키마가 복제될 때, 내부(즉, Snowflake) 스테이지를 참조하는 원본 컨테이너의 모든 파이프는 복제되지 않습니다.

그러나 외부 스테이지를 참조하는 모든 파이프는 복제되지 않습니다. 여기에는 INTEGRATION 매개 변수가 설정된 모든 파이프 오브젝트가 포함됩니다. 이 매개 변수는 Google Cloud Storage 또는 Microsoft Azure Blob 저장소의 파일에서 데이터를 로딩할 때 자동 수집 Snowpipe를 활성화하는 알림 통합을 가리킵니다.

데이터 파일이 스테이지 위치(예: Blob 저장소 컨테이너)에 생성되면 알림 사본이 스테이지 위치와 일치하는 모든 파이프로 전송됩니다. 이를 통해 수행되는 동작은 다음과 같습니다.

  • 테이블이 파이프 정의의 COPY 문에서 정규화(db_name.schema_name.table_name 또는 schema_name.table_name 형식)되면, Snowpipe는 각 파이프에 대한 소스 테이블(즉, COPY 문의 database.schema.table)로 중복 데이터를 로드합니다.

  • 파이프 정의에서 테이블이 정규화되지 않은 경우 Snowpipe는 원본 및 복제된 데이터베이스/스키마의 테이블(예: mytable)에 데이터를 로드합니다.

파이프 복제본의 기본 상태는 다음과 같습니다.

  • AUTO_INGEST = FALSE 일 때는 복제된 파이프가 기본적으로 일시 중지됩니다.

  • AUTO_INGEST = TRUE 일 때는 복제된 파이프가 STOPPED_CLONED 상태로 설정됩니다. 이 상태에서 파이프는 새로 스테이징된 파일의 결과로 이벤트 알림을 누적하지 않습니다. 파이프가 명시적으로 다시 시작될 때, 새 이벤트 알림의 결과로 트리거된 데이터 파일만 처리합니다.

어느 한 상태의 파이프 복제는 ALTER PIPE … RESUME 문을 실행하여 다시 시작할 수 있습니다.

복제 및 스트림

현재, 원본 테이블 및 스트림이 포함된 데이터베이스 또는 스키마가 복제될 때 스트림(복제본에서)에서 사용되지 않은 레코드에는 액세스할 수 없습니다. 이 동작은 테이블에 대한 Time Travel 과 일치합니다. 테이블이 복제된 경우, 테이블 복제본에 대한 과거 데이터는 복제본이 생성된 시간/지점에서 시작됩니다.

복제 및 태스크

태스크가 포함된 데이터베이스 또는 스키마가 복제될 때 복제본의 태스크는 기본적으로 일시 중단됩니다. 태스크는 개별적으로 다시 시작(ALTER TASK … RESUME을 사용하여)할 수 있습니다.

복제 및 거버넌스 오브젝트

마스킹 정책 및 행 액세스 정책:

다음 방식은 복제된 오브젝트에 액세스할 때 테이블이나 뷰에 대한 SELECT 권한이 있는 사용자로부터 데이터를 보호하는 데 유용합니다.

  • 개별 정책 오브젝트를 복제하는 기능은 지원되지 않습니다.

  • 스키마를 복제하면 스키마 내의 모든 정책이 복제됩니다.

  • 복제된 테이블은 원본 테이블과 동일한 정책에 매핑됩니다. 즉, 기본 테이블이나 기본 테이블의 열에 정책이 설정되어 있으면 복제된 테이블이나 복제된 테이블의 열에 정책이 연결됩니다.

    • 테이블이 상위 스키마 복제 컨텍스트에서 복제되는 경우, 소스 테이블에 동일한 상위 스키마의 정책에 대한 참조(즉, 로컬 참조)가 있으면 복제된 테이블도 복제된 정책에 대한 참조를 갖습니다.

    • 소스 테이블이 다른 스키마(즉, 외부 참조)의 정책을 참조하는 경우 복제된 테이블에도 외부 참조가 유지합니다.

자세한 내용은 CREATE <오브젝트> … CLONE 섹션을 참조하십시오.

다음 섹션도 참조하십시오.

태그:

  • 원본 오브젝트(예: 테이블)의 태그 연결은 복제된 오브젝트에서 유지 관리됩니다.

  • 데이터베이스 또는 스키마의 경우:

    해당 데이터베이스 또는 스키마에 저장된 태그도 복제됩니다.

    데이터베이스 또는 스키마가 복제되면 해당 스키마 또는 데이터베이스에 있는 태그도 복제됩니다.

    테이블 또는 뷰가 원본 스키마/데이터베이스에 존재하고 같은 스키마 또는 데이터베이스의 태그에 대한 참조가 있는 경우, 복제된 테이블 또는 뷰가 원본 스키마 또는 데이터베이스의 태그 대신 (대상 스키마/데이터베이스에서) 복제된 해당 태그에 매핑됩니다.

태그 기반 마스킹 정책:

태그가 마스킹 정책 및 테이블과는 다른 스키마에 저장되는 태그 기반 마스킹 정책의 경우, 마스킹 정책과 테이블을 포함하는 스키마를 복제하면 복제된 테이블이 복제된 스키마가 아닌 원본 스키마의 마스킹 정책으로 보호됩니다.

하지만 태그, 마스킹 정책, 테이블이 모두 스키마에 존재하는 태그 기반 마스킹 정책의 경우, 스키마를 복제하면 원본 스키마가 아닌 복제된 스키마에서 테이블이 마스킹 정책으로 보호됩니다.

DDL이 복제에 미치는 영향

복제는 신속하게 수행되지만, 특히 대규모 오브젝트(예: 테이블)의 경우에는 즉시 수행되지 않습니다. 그러므로 복제 작업이 진행되는 동안 원본 오브젝트에서 DDL 문을 실행(예: 스키마의 테이블 이름 변경)하면 변경 사항이 복제본에 표시되지 않을 수 있습니다. 이는 DDL 문이 원자성이며 다중 문 트랜잭션의 일부가 아니기 때문입니다.

또한, Snowflake는 복제 작업이 시작될 때 존재했던 오브젝트 이름과 어떤 이름이 변경되었는지를 기록하지 않습니다. 그러므로 원본 하위 오브젝트의 이름을 변경(또는 삭제 및 재생성)하는 DDL 문은 진행 중인 복제 작업과 경쟁하고 이름 충돌이 발생할 수 있습니다.

다음 예에서는 상위 데이터베이스를 복제하는 동안 t_sales 테이블을 삭제한 후 다른 테이블을 변경하고 삭제된 테이블과 동일한 이름을 지정하여 오류가 발생합니다.

CREATE OR REPLACE DATABASE staging_sales CLONE sales;

DROP TABLE sales.public.t_sales;

ALTER TABLE sales.public.t_sales_20170522 RENAME TO sales.public.t_sales;

002002 (42710): None: SQL compilation error: Object 'T_SALES' already exists.

복제 작업 중 이름 확인에서 충돌을 방지하려면 복제가 완료될 때까지 삭제된 오브젝트에서 이전에 사용한 이름으로 오브젝트의 이름을 변경하지 않는 것이 좋습니다.

DML 및 데이터 보존이 복제에 미치는 영향

DATA_RETENTION_TIME_IN_DAYS 매개 변수는 오브젝트에서 Time Travel 작업을 수행하기 위해 Snowflake가 과거 데이터를 보존하는 일 수를 지정합니다. Time Travel용으로 보존되는 데이터에서는 테이블 수준의 저장소 비용이 발생하므로, 일부 사용자는 일부 테이블에서 이 매개 변수를 0 으로 설정하여 이러한 테이블에 대한 데이터 보존을 실질적으로 비활성화합니다(즉, 이 값이 0 으로 설정되면 DML 트랜잭션을 위해 보존되는 Time Travel 데이터가 삭제되어 무시할 수 있는 수준의 추가 저장소 비용이 발생함).

복제 작업에서는 특히 대규모 테이블의 경우 완료하기까지 시간이 소요됩니다. 이 기간 중에 DML 트랜잭션은 원본 테이블의 데이터를 수정할 수 있습니다. 결과적으로, Snowflake는 작업이 시작될 때의 상태로 테이블 데이터를 복제하려고 시도합니다. 그러나 복제 중에 발생한 DML 트랜잭션용 데이터가 삭제되면(테이블의 보존 시간이 0 이므로) 작업을 수행하기 위해 데이터를 사용할 수 없어 다음과 유사한 오류가 발생하게 됩니다.

ProgrammingError occured: "000707 (02000): None: Data is not available." with query id None

이를 해결하기 위해서는 오브젝트를 복제하는 경우를 위한 다음 모범 사례 중 1개를 수행하는 것이 좋습니다.

  • 가능하면 복제 작업이 완료될 때까지 원본 오브젝트(또는 모든 하위 오브젝트)에서 DML 트랜잭션을 실행하지 마십시오.

  • 실행해야 하는 경우에는 복제를 시작하기 전 스키마(또는 전체 데이터베이스를 복제하는 경우 데이터베이스)의 모든 테이블에 DATA_RETENTION_TIME_IN_DAYS=1 을 설정하십시오. 작업이 완료되면 필요한 경우 원본의 해당 테이블에서 해당 매개 변수 값을 0 으로 재설정해야 합니다.

    복제된 테이블에 이 값을 0 으로 설정할 수도 있습니다(복제된 테이블에서 DML을 변경하고 테이블에서 Time Travel과 관련된 추가 저장소 비용이 발생하지 않도록 하려면).

Time Travel을 사용하여 복제하기(데이터베이스, 스키마, 테이블 및 스트림만 해당)

이 섹션에서는 Time Travel 을 사용하여 과거의 특정 시간/시점에서 오브젝트를 복제할 때 고려해야 할 내용을 설명합니다.

과거 오브젝트 복제하기

AT | BEFORE 절에 설정된 시간/시점에 원본 오브젝트가 없으면 오류가 반환됩니다.

다음 예에서 CREATE TABLE … CLONE 문은 원본 테이블이 존재하지 않았던 과거(30분 전)의 시점에 원본 테이블을 복제하려고 시도합니다.

CREATE TABLE t_sales (numeric integer) data_retention_time_in_days=1;

CREATE OR REPLACE TABLE sales.public.t_sales_20170522 CLONE sales.public.t_sales at(offset => -60*30);

002003 (02000): SQL compilation error:
Object 'SALES.PUBLIC.T_SALES' does not exist.

지정된 시간/시점에 존재하지 않는 복제된 데이터베이스 또는 스키마의 모든 하위 오브젝트는 복제되지 않습니다.

다음의 상황에서는 복제 작업이 실패하게 됩니다.

  • 지정된 Time Travel 시간이 복제된 데이터베이스 또는 스키마의 모든 현재 하위 항목 에 대한 보존 시간을 초과하는 경우.

  • AUTO-INGEST = TRUE 로 설정된 파이프 오브젝트가 AT | BEFORE 절에 지정된 시점 이후에 다시 생성(CREATE OR REPLACE PIPE 구문 사용)되거나 삭제된 경우. 이러한 제한 사항은 REST API를 사용한 수동 Snowpipe 수집을 위해 생성된 파이프 오브젝트(즉, AUTO-INGEST = FALSE 로 설정)에는 적용되지 않습니다.

과거 오브젝트 메타데이터 복제하기

오브젝트 복제본은 CREATE <오브젝트> … CLONE 문이 실행될 때 또는 Time Travel 을 사용하여 지정된 시간/과거의 시점에 현재 원본 오브젝트의 이름구조 를 상속합니다. 오브젝트 복제본은 Time Travel의 사용 여부와 관계없이 문이 실행되는 시점에 원본 오브젝트에 있는 설명 또는 테이블 클러스터링 키와 같은 다른 메타데이터를 모두 상속합니다.

참고

긴 복제 작업에서 동작이 일관적으로 수행될 수 있도록 AT 또는 BEFORE 절이 CREATE <오브젝트> … CLONE 문에 지정되지 않은 경우 복제 작업에서는 문이 시작되면 AT 절 값이 타임스탬프로 내부적으로 설정됩니다.

맨 위로 이동