복제 고려 사항¶

데이터베이스 및 공유 오브젝트¶

다음 제약 조건이 데이터베이스 및 공유 오브젝트에 적용됩니다.

• 오브젝트는 하나의 장애 조치 그룹에만 있을 수 있습니다.

• 각 그룹이 다른 대상 계정에 복제되는 한, 오브젝트는 여러 복제 그룹에 있을 수 있습니다.

• 오브젝트는 장애 조치 그룹과 복제 그룹 둘 다에 있을 수는 없습니다.

• 보조(복제본) 오브젝트는 기본 복제 또는 장애 조치 그룹에 추가할 수 없습니다.

아웃바운드 공유만 복제할 수 있습니다. 인바운드 공유 (공급자의 공유) 복제는 지원되지 않습니다.

계정 오브젝트¶

계정에는 데이터베이스 또는 공유 이외의 오브젝트가 포함된 복제 그룹 또는 장애 조치 그룹이 하나만 있을 수 있습니다.

스트림¶

스트림에 대한 허상 참조로 인해 다음 오류 메시지가 표시되며 복제에 실패하게 됩니다.

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.

허상 참조 오류를 방지하는 방법:

• 기본 데이터베이스는 스트림과 스트림의 기본 오브젝트를 모두 포함해야 합니다. 또는

• 스트림을 포함하는 데이터베이스와 스트림이 참조하는 기본 오브젝트를 포함하는 데이터베이스는 동일한 복제 또는 장애 조치 그룹에 포함되어야 합니다.

네트워크 정책¶

네트워크 정책의 허상 참조로 인해 다음 오류 메시지가 표시되며 복제가 실패할 수 있습니다.

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 를 포함합니다.

자세한 내용은 네트워크 정책 복제하기 섹션을 참조하십시오.

시크릿¶

자세한 내용은 복제 및 시크릿 섹션을 참조하십시오.

비밀번호 및 세션 정책¶

복제 그룹 또는 장애 조치 그룹에서 정책(ALLOWED_DATABASES = policy_db) 및 USERS 를 포함하는 데이터베이스를 지정할 때 사용자에 대한 비밀번호 및 세션 정책 참조가 복제됩니다.

정책 데이터베이스 또는 사용자가 대상 계정에 이미 복제된 경우, 정책을 성공적으로 복제하는 데 필요한 데이터베이스 및 오브젝트 유형을 포함하도록 원본 계정의 복제 그룹 또는 장애 조치 그룹을 업데이트합니다. 그런 다음 새로 고침 작업을 실행하여 대상 계정을 업데이트합니다.

사용자 수준 정책을 사용하지 않는 경우 USERS 를 복제 그룹 또는 장애 조치 그룹에 포함할 필요가 없습니다.

기본 데이터베이스의 외부 테이블¶

기본 데이터베이스의 외부 테이블로 인해 현재 다음 오류 메시지와 함께 복제 또는 새로 고침 작업이 실패합니다.

003906 (55000): SQL execution error:
Primary database contains an external table '<database_name>'. Replication of a database with external table is not supported

이 오류를 방지하려면 외부 테이블을 복제되지 않는 별도의 데이터베이스로 이동하십시오. 또는 데이터베이스를 다른 계정으로 마이그레이션하는 경우 기본 데이터베이스를 복제하고 복제에서 외부 테이블을 삭제한 다음 복제된 데이터베이스를 복제할 수 있습니다. 대상 계정에서 보조 데이터베이스를 승격한 후에는 데이터베이스에서 외부 테이블을 다시 생성해야 합니다.

보조 데이터베이스의 외부 테이블¶

외부 테이블은 이전에 기본 데이터베이스였고 외부 테이블이 그 시간 중에 생성된 경우 보조 데이터베이스에 존재할 수 있습니다. 다른 데이터베이스가 지정된 기본 데이터베이스로 승격되면 그 데이터베이스가 보조 데이터베이스가 됩니다. 보조 데이터베이스의 외부 테이블로 인해 현재 다음 오류와 함께 새로 고침 작업이 실패합니다.

003958 (55000): SQL execution error:
Secondary database contains an external table '<table_name>'. Replication of a database with external table is not supported.

이 오류를 방지하려면 외부 테이블을 복제된 보조 데이터베이스가 아닌 별도의 데이터베이스로 이동하십시오.

동적 테이블 및 복제 그룹¶

동적 테이블을 포함하는 데이터베이스는 복제 그룹을 사용하여 복제할 수 있습니다. 동적 테이블이 종속된 기본 오브젝트는 동일한 복제 그룹에 있을 필요가 없습니다.

보조 오브젝트는 대상 계정에서 읽기 전용 입니다. 보조 복제 그룹이 대상 계정에서 삭제되면 그룹에 포함된 데이터베이스가 읽기/쓰기 상태가 됩니다. 하지만 복제 그룹에 포함된 모든 동적 테이블은 대상 계정에서 보조 그룹이 삭제된 후에도 읽기 전용 상태로 유지됩니다. 이러한 읽기 전용 동적 테이블에서는 DML 또는 동적 테이블 새로 고침이 발생할 수 없습니다.

동적 테이블, 장애 조치 그룹, 데이터베이스 복제¶

동적 테이블을 포함하는 데이터베이스는 장애 조치 그룹을 사용하여 복제할 수 있습니다. 동적 테이블이 종속된 기본 오브젝트를 반드시 동일한 장애 조치 그룹에 포함해야 합니다. 그렇지 않으면 새로 고침 작업 중에 다음 오류 메시지와 함께 허상 참조가 발생합니다.

002749 (55000): SQL execution error: Dynamic table <dt_name> has dependencies that are missing in the replication membership: <dependency_table_name>

데이터베이스 복제를 사용하여 데이터베이스에서 동적 테이블이 복제되는 경우에도 같은 사항이 적용됩니다. 허상 참조 오류를 방지하려면 동적 테이블이 종속된 기본 오브젝트를 동일한 데이터베이스에 포함해야 합니다.

보조 동적 테이블은 읽기 전용이며 새로 고쳐지지 않습니다. 장애 조치가 발생하고 보조 동적 테이블이 기본 동적 테이블로 승격된 후, 첫 번째 새로 고침이 다시 초기화된 다음 동적 테이블이 데이터 증분 새로 고침으로 구성된 경우 증분 새로 고침이 이어집니다.

데이터 손실 방지하기¶

장애 조치 시 데이터 손실을 방지하려면 업스트림 데이터 원본에 성공적으로 삽입된 행의 데이터 보존 시간이 복제 빈도보다 커야 합니다. 데이터가 기본 데이터베이스의 테이블에 삽입되고 장애 조치가 이루어진 후에 보조 데이터베이스에 데이터를 복제할 수 있는 경우 새로 승격된 기본 데이터베이스의 테이블에 동일한 데이터를 삽입해야 합니다. 다음은 예시 시나리오입니다.

1. Snowpipe Streaming과 Kafka 커넥터를 사용하여 기본 데이터베이스 repl_db 의 테이블 t1 을 데이터로 채웁니다.

2. offsetToken 은 기본 데이터베이스에서 t1 에 대해 채널 1의 경우 100, 채널 2의 경우 100입니다.

3. 대상 계정에서 새로 고침 작업이 성공적으로 완료됩니다.

4. offsetToken 은 보조 데이터베이스에서 t1 에 대해 채널 1의 경우 100, 채널 2의 경우 100입니다.

5. 기본 데이터베이스에서 더 많은 행이 t1 에 삽입됩니다.

6. offsetToken 은 이제 기본 데이터베이스에서 t1 에 대해 채널 1의 경우 200, 채널 2의 경우 200입니다.

7. 장애 조치가 이루어진 후 추가 행과 새 채널 오프셋을 보조 데이터베이스에 복제할 수 있습니다.

이 경우 새로 승격된 기본 데이터베이스에서 테이블 t1 의 각 채널에 누락된 오프셋이 100개 있습니다. 누락된 데이터를 삽입하려면 새로 승격된 원본 계정에서 Snowpipe Streaming을 위한 활성 채널 다시 열기 섹션을 참조하십시오.

요구 사항¶

Snowpipe Streaming 복제 지원에 필요한 최소 버전은 다음과 같습니다.

• Snowflake Ingest SDK 버전 1.1.1 이상

• Kafka 커넥터를 사용하는 경우: Kafka 커넥터 버전 1.9.3 이상

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

저장 프로시저 또는 UDF가 어떤 스테이지의 파일에 종속되는 경우(예: 저장 프로시저가 어떤 스테이지에서 업로드되는 Python 코드로 정의된 경우), 스테이지와 스테이지의 파일을 보조 데이터베이스에 복제해야 합니다. 스테이지 복제에 대한 자세한 내용은 스테이지, 파이프 및 로드 기록 복제 섹션을 참조하십시오.

예를 들어 기본 데이터베이스에 스테이지에 저장된 코드를 가져오는 인라인 Python UDF가 있는 경우, 스테이지와 가져온 코드를 보조 데이터베이스에서 복제하지 않는 한 UDF는 작동하지 않습니다.

저장 프로시저와 UDF 및 외부 네트워크 액세스¶

저장 프로시저 또는 UDF가 외부 네트워크 위치 에 대한 액세스에 의존하는 경우 다음 오브젝트를 복제해야 합니다.

• 복제 또는 장애 조치 그룹의 allowed_integration_types 목록에 EXTERNAL ACCESS INTEGRATIONS가 포함되어야 합니다.

• 네트워크 규칙이 포함된 데이터베이스.

• 외부 네트워크 위치로 인증하기 위한 자격 증명을 저장하는 시크릿이 포함된 데이터베이스.

  참고

  시크릿 복제 에 대한 지원은 2023_08 번들(기본적으로 활성화됨) 에서 제공됩니다. 외부 액세스 통합에서 참조하는 외부 네트워크 위치로 인증하기 위해 자격 증명을 저장하는 시크릿 오브젝트를 복제하려면 반드시 BCR 번들을 활성화해야 합니다.

• 시크릿 오브젝트가 보안 통합을 참조하는 경우 복제 또는 장애 조치 그룹의 allowed_integration_types 목록에 SECURITY INTEGRATIONS를 포함해야 합니다.

스트림에 대해 지원되는 원본 오브젝트¶

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

현재, 다음 원본 오브젝트 유형은 지원되지 않습니다.

• 외부 테이블

• 스트림 데이터베이스와 원본 오브젝트를 저장하는 데이터베이스가 모두 동일한 복제 또는 장애 조치 그룹 에 포함되지 않는 한, 스트림 데이터베이스와 별개인 데이터베이스의 테이블 또는 뷰.

• 공유 데이터베이스(즉, 공급자 계정에서 자신의 계정으로 공유되는 데이터베이스)의 테이블 또는 뷰

스테이지, 파이프 및 로드 기록 복제 를 활성화하면 디렉터리 테이블의 스트림 복제가 지원됩니다.

기본 데이터베이스에 지원되지 않는 원본 오브젝트가 있는 스트림이 포함되는 경우 데이터베이스 복제 또는 새로 고침 작업이 실패합니다. 스트림에 대한 원본 오브젝트가 삭제된 경우에도 작업이 실패합니다.

복제된 원본 오브젝트에서는 Append-only 스트림이 지원되지 않습니다.

데이터 중복 방지하기¶

데이터 중복은 DML 작업이 고유성 검사 없이 스트림에서 같은 변경 데이터를 여러 번 쓸 때 발생합니다. 스트림 변경 데이터의 대상 테이블과 스트림이 별개의 데이터베이스에 저장되고 이러한 데이터베이스가 같은 그룹에서 복제되고 장애 조치되지 않는 경우에 데이터 중복이 발생할 수 있습니다.

예를 들어 스트림 s 에서 테이블 dt 로 변경 데이터를 정기적으로 삽입한다고 가정합니다. (이 예에서는 스트림의 원본 오브젝트가 중요하지 않습니다.) 별개의 데이터베이스가 스트림 및 대상 테이블을 저장합니다.

1. 타임스탬프 t1 에서 스트림 s 에 대한 원본 테이블에 행이 삽입되어 새 테이블 버전을 생성합니다. 스트림은 이 테이블 버전의 오프셋을 저장합니다.

2. 타임스탬프 t2 에서 스트림을 저장하는 보조 데이터베이스가 새로 고쳐집니다. 복제된 스트림 s 는 이제 오프셋을 저장합니다.

3. 타임스탬프 t3 에서 스트림 s 의 변경 데이터가 테이블 dt 에 삽입됩니다.

4. 타임스탬프 t4 에서 스트림 s 를 저장하는 보조 데이터베이스가 장애 조치됩니다.

5. 타임스탬프 t5 에서 스트림 s 의 변경 데이터가 테이블 dt 에 다시 삽입됩니다.

이 상황을 방지하려면 스트림과 대상 테이블을 저장하는 데이터베이스를 함께 복제하고 장애 조치하십시오.

작업 WHEN 절의 스트림 참조¶

WHEN boolean_expr 절에서 스트림을 참조하는 복제된 작업을 실행할 때 예기치 않은 동작을 방지하려면 다음 중 하나를 수행하는 것이 좋습니다.

• 같은 데이터베이스에 작업과 스트림 생성 또는

• 스트림이 해당 스트림을 참조하는 작업과는 다른 데이터베이스에 저장되어 있는 경우 두 데이터베이스를 모두 같은 장애 조치 그룹 에 포함합니다.

작업이 별개의 데이터베이스에 있는 스트림을 참조하고 두 데이터베이스가 모두 같은 장애 조치 그룹에 포함되지 않을 경우에는 작업이 포함된 데이터베이스를 스트림이 포함된 데이터베이스 없이 장애 조치할 수 있습니다. 이 시나리오에서는 작업이 장애 조치된 데이터베이스에서 재개되는 경우 작업이 실행을 시도하고 참조된 스트림을 찾을 수 없을 때 오류를 기록합니다. 이 문제는 스트림이 포함된 데이터베이스를 장애 조치하거나 작업이 포함된 장애 조치된 데이터베이스와 동일한 계정에 데이터베이스와 스트림을 다시 생성함으로써 해결할 수 있습니다.

스트림 부실¶

기본 데이터베이스의 스트림이 부실 해진 경우 보조 데이터베이스에서 복제된 스트림도 부실해져 쿼리할 수 없거나 스트림의 변경 데이터를 사용할 수 없습니다. 이 문제를 해결하려면 기본 데이터베이스에서 스트림을 다시 만드십시오(CREATE OR REPLACE STREAM 사용). 보조 데이터베이스가 새로 고쳐지면 복제된 스트림을 다시 읽을 수 있습니다.

다시 생성된 스트림의 오프셋은 기본적으로 현재 테이블 버전입니다. Time Travel을 사용하여 이전 테이블 버전을 가리키는 스트림을 다시 만들 수 있지만, 복제된 스트림은 읽을 수 없는 상태로 남습니다. 자세한 내용은 이 항목의 스트림 복제 및 Time Travel 을 참조하십시오.

스트림 복제 및 Time Travel¶

기본 데이터베이스가 장애 조치된 후 데이터베이스의 스트림이 Time Travel 을 사용하여 마지막 새로 고침 타임스탬프 이전의 시점에서 원본 오브젝트의 테이블 버전 을 읽는 경우 복제된 스트림을 쿼리할 수 없거나 변경 데이터를 사용할 수 없습니다. 마찬가지로, SELECT 문의 CHANGES 절을 사용하여 마지막 새로 고침 타임스탬프 이전의 시점에서 원본 오브젝트의 변경 데이터를 쿼리하면 오류가 발생하며 실패합니다.

이는 새로 고침 작업으로 테이블 기록이 단일 테이블 버전으로 축소되기 때문입니다. 새로 고침 작업 타임스탬프 전에 생성된 반복 테이블 버전은 복제된 원본 오브젝트의 테이블 기록에 보존되지 않습니다.

다음 예를 살펴보겠습니다.

1. 테이블 t1 이 변경 추적을 사용하는 기본 데이터베이스에 생성됩니다(테이블 버전 tv0). 이후의 DML 트랜잭션으로 테이블 버전 tv1 및 tv2 가 생성됩니다.

2. 테이블 t1 이 포함된 보조 데이터베이스가 새로 고쳐집니다. 이 복제된 테이블의 테이블 버전은 tv2 이지만, 테이블 기록은 복제되지 않습니다.

3. Time Travel을 사용하여 오프셋이 테이블 버전 tv1 로 설정된 기본 데이터베이스에 스트림이 생성됩니다.

4. 보조 데이터베이스가 장애 조치되어 기본 데이터베이스가 됩니다.

5. 테이블 버전 tv1 이 테이블 기록에 없으므로 스트림 s1 을 쿼리하면 오류가 반환됩니다.

테이블 t1 에 대한 후속 DML 트랜잭션에서 테이블 버전을 tv3 으로 반복할 때 스트림 s1 에 대한 오프셋이 진행됩니다. 스트림을 다시 읽을 수 있습니다.

데이터 손실 방지하기¶

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

복제 시나리오¶

다음 표에는 다양한 작업 시나리오에 대한 설명이 나와 있고 작업의 복제 여부가 명시되어 있습니다. 명시된 경우를 제외하면 이들 시나리오는 독립 실행형 작업과 DAG 의 작업에 모두 적용됩니다.

복제된 작업의 재개 또는 일시 중단 상태¶

다음 조건이 모두 충족되면 작업이 재개된 상태의 보조 데이터베이스에 복제됩니다.

• 작업이 완료될 때까지 복제 또는 새로 고침 작업이 시작될 때 독립 실행형 또는 루트 작업은 기본 데이터베이스에서 재개된 상태입니다. 작업이 이 기간의 일부 동안에만 재개된 상태인 경우에도 재개된 상태로 복제될 수 있습니다.

  하위 작업은 최신 버전의 작업에서 재개된 상태입니다.

• 상위 데이터베이스가 같거나 다른 복제 또는 장애 조치 그룹 의 역할 오브젝트와 함께 대상 계정에 복제되었습니다.

  역할과 데이터베이스가 복제된 후 각각 ALTER REPLICATION GROUP … REFRESH 또는 ALTER FAILOVER GROUP … REFRESH 를 실행하여 대상 계정의 오브젝트를 새로 고쳐야 합니다. ALTER DATABASE … REFRESH 를 실행하여 데이터베이스를 새로 고치면 데이터베이스에서 작업의 상태가 일시 중단으로 변경됩니다.

  복제 또는 새로 고침 작업은 최신 테이블 버전이 커밋될 때 최신 상태였던 작업에 대한 권한 부여를 포함합니다. 자세한 내용은 이 항목의 복제 작업 및 권한 부여 를 참조하십시오.

이러한 조건이 충족되지 않으면 작업이 일시 중단된 상태에서 보조 데이터베이스에 복제됩니다.

복제 작업 및 권한 부여¶

상위 데이터베이스가 같거나 다른 복제 또는 장애 조치 그룹의 역할 오브젝트와 함께 대상 계정에 복제되면 데이터베이스의 작업에 부여된 권한도 복제됩니다.

다음 논리에 따라 복제 또는 새로 고침 작업에서 복제되는 작업 권한이 결정됩니다.

• 현재 작업 소유자(즉, 작업에 대한 OWNERSHIP 권한이 있는 역할)가 작업이 마지막으로 재개되었을 때와 동일한 역할인 경우에는 작업에 대한 모든 현재 권한 부여가 보조 데이터베이스에 복제됩니다.

• 현재 작업 소유자가 작업이 마지막으로 재개되었을 때와 동일한 역할이 아닌 경우에는 작업 버전에서 소유자 역할에 부여된 OWNERSHIP 권한만 보조 데이터베이스에 복제됩니다.

• 현재 작업 소유자 역할을 사용할 수 없는 경우(예: 하위 작업이 삭제되지만 새 버전의 작업 DAG가 아직 커밋되지 않은 경우) 작업 버전에서 소유자 역할에 부여된 OWNERSHIP 권한만 보조 데이터베이스에 복제됩니다.

장애 조치 후 작업 실행¶

보조 장애 조치 그룹이 기본 그룹 역할을 하도록 승격된 후 장애 조치 그룹 내의 데이터베이스에서 재개된 모든 작업은 점진적으로 예약됩니다. 재개된 모든 독립 실행형 작업과 DAG의 정상적인 예약을 복원하는 데 필요한 시간은 데이터베이스에서 재개된 작업 수에 따라 다릅니다.