데이터베이스 복제 고려 사항

이 주제는 데이터베이스 복제를 사용할 때 보조(secondary) 데이터베이스에서 특정 Snowflake 기능의 동작을 설명해요.

출처: Snowflake User Guide - Database replication considerations

본문

중요: 이 섹션은 계정 복제(account replication) 기능과는 다른 제한된 데이터베이스 복제 기능을 설명해요. Snowflake는 데이터베이스를 복제하고 장애 조치하는 데 계정 복제 기능을 사용할 것을 강력히 권장해요.

복제된 객체와 데이터로 작업하기 위한 추가 지침은 복제 고려 사항을 참고해요.

데이터베이스 복제와 보안 객체

이 섹션은 보안 정책과 시크릿의 데이터베이스 복제 동작을 설명해요.

마스킹 & 행 접근 정책:

다음 조건 중 하나라도 참이면 복제 연산이 실패해요.

기본 데이터베이스가 Enterprise(이상) 계정에 있고 정책/태그를 포함하지만, 복제가 승인된 계정 중 하나 이상이 하위 에디션에 있는 경우.
기본 데이터베이스에 포함된 객체가 다른 데이터베이스의 태그에 대한 댕글링 참조(dangling reference)를 가진 경우.

데이터베이스 복제의 댕글링 참조 동작은 복제 또는 장애 조치 그룹에서 여러 데이터베이스를 복제하면 피할 수 있어요.

태그 기반 마스킹 정책:

다음 조건 중 하나라도 참이면 복제 연산이 실패해요.

기본 데이터베이스가 Enterprise(이상) 계정에 있고 정책/태그를 포함하지만, 복제가 승인된 계정 중 하나 이상이 하위 에디션에 있는 경우.
기본 데이터베이스에 포함된 객체가 다른 데이터베이스의 태그에 대한 댕글링 참조를 가진 경우.

태그 기반 마스킹 정책에 대한 자세한 내용은 태그 기반 마스킹 정책을 참고해요.

비밀번호, 세션 & 인증 정책:

다음 조건 중 하나라도 참이면 복제 연산이 실패해요.

기본 데이터베이스가 Enterprise(이상) 계정에 있고 정책을 포함하지만, 복제가 승인된 계정 중 하나 이상이 하위 에디션에 있는 경우.
기본 데이터베이스에 포함된 이 객체들 중 하나가 같은 계정의 사용자에 연결된 경우. 이 경우 Snowflake는 복제 연산을 실패시켜요.

사용자 참조로 인한 실패한 데이터베이스 복제 연산을 피하려면 복제 또는 장애 조치 그룹을 사용해요.

시크릿:

데이터베이스 복제로 시크릿을 복제할 수 없어요. 시크릿을 복제하려면 복제 또는 장애 조치 그룹을 사용해요.

댕글링 참조

다른 데이터베이스의 객체에 대한 참조:

기본 데이터베이스의 뷰나 테이블 제약 조건이 다른 데이터베이스의 객체를 참조하는지 주의 깊게 분석해요. 데이터베이스 객체의 객체 종속성은 Account Usage OBJECT_DEPENDENCIES 뷰에서 확인할 수 있어요.

다음 표는 데이터베이스의 객체(참조 객체)가 다른 데이터베이스의 객체(참조 대상)를 참조할 때의 데이터베이스 복제 동작을 설명해요.

참조 객체	참조 대상	복제 동작
비구체화 뷰(non-materialized view)	객체	성공
구체화된 뷰	객체	실패
구체화된 뷰	삭제된 객체	실패
외래 키 제약 조건	기본 키(primary key)	실패
테이블	시퀀스	실패
마스킹 정책, 행 접근 정책, 또는 태그	정책/태그가 지정된 객체	실패
스트림	객체	실패

비구체화 뷰:

다른 데이터베이스의 어떤 객체든(예: 테이블 컬럼, 다른 뷰, UDF, 스테이지) 참조하는 비구체화 뷰는 복제될 수 있어요. 이 유형의 참조가 이름 기반이기 때문이에요. 이름 기반 참조는 복제를 실패시키지 않지만, 다른 데이터베이스들이 같은 리전에 복제되지 않으면 보조 데이터베이스에서 뷰에 대한 쿼리는 실패해요. 예를 들어 데이터베이스 d1의 뷰 v1이 각각 데이터베이스 d1과 d2의 테이블 t1과 t2를 참조한다고 가정해요. 보조 데이터베이스 d1에서 뷰 v1을 성공적으로 쿼리하려면 보조 데이터베이스 d2도 계정에 존재해야 해요(예: 다른 보조 데이터베이스로). 또한 기본 데이터베이스와 일관된 쿼리 결과를 위해 보조 데이터베이스 d1과 d2는 동시에 새로 고침되어야 해요.

구체화된 뷰:

구체화된 뷰의 댕글링 참조는 다음 오류 메시지로 복제를 실패시킬 수 있어요.

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

이 댕글링 참조는 다음 경우에 발생할 수 있어요.

구체화된 뷰가 다른 데이터베이스의 어떤 객체든 참조하는 경우. 구체화된 뷰는 이름이 아니라 ID로 객체를 참조해요. 데이터베이스 스냅샷은 데이터베이스 밖 객체에 대한 ID 기반 참조를 해석할 수 없어요. 이 한계를 우회하려면 두 데이터베이스를 같은 복제 또는 장애 조치 그룹에서 함께 복제해요. 또는 구체화된 뷰와 그것이 참조하는 객체를 같은 데이터베이스에 저장할 수 있어요.
구체화된 뷰가 유효하지 않은 경우(즉 삭제된 객체를 참조하는 경우). 유효하지 않은 구체화된 뷰의 댕글링 참조 오류를 피하려면 구체화된 뷰의 문제를 찾아 고쳐요. 구체화된 뷰 주제의 문제 해결 섹션을 참고해요.

제약 조건:

현재 댕글링 외래 키는 다음 오류 메시지로 복제를 실패시켜요.

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

이 상황은 기본 데이터베이스의 외래 키가 다른 데이터베이스의 기본 키를 참조하거나 그 반대일 때 발생해요. 제약 조건 참조가 ID 기반이기 때문이에요. 데이터베이스 스냅샷은 자신의 데이터베이스 밖 객체에 대한 ID 기반 참조를 해석할 수 없어요. 계정의 외래 키 참조를 보려면 정보 스키마(Information Schema) TABLE_CONSTRAINTS 뷰 또는 Account Usage TABLE_CONSTRAINTS 뷰를 쿼리해요. 이 한계를 우회하려면 두 데이터베이스를 같은 복제 또는 장애 조치 그룹에서 함께 복제해요. 또는 연결된 테이블을 같은 데이터베이스에 저장할 수 있어요.

시퀀스:

현재 댕글링 시퀀스는 다음 오류 메시지로 복제를 실패시켜요.

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

이 상황은 기본 데이터베이스의 테이블이 다른 데이터베이스의 시퀀스를 참조할 때 발생해요. 시퀀스 참조가 ID 기반이기 때문이에요. 데이터베이스 스냅샷은 자신의 데이터베이스 밖 객체에 대한 ID 기반 참조를 해석할 수 없어요. 이 한계를 우회하려면 두 데이터베이스를 같은 복제 또는 장애 조치 그룹에서 함께 복제해요. 또는 같은 데이터베이스에서 시퀀스를 참조할 수 있어요.

마스킹 & 행 접근 정책 및 태그:

마스킹 정책, 행 접근 정책, 또는 태그에 대한 댕글링 참조는 다음 오류 메시지로 복제를 실패시켜요.

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

이 상황은 정책/태그와 정책/태그가 지정된 객체가 서로 다른 데이터베이스에 존재할 때 발생해요. 예를 들어 db1.s1.t1이라는 테이블, db2.s1.rap1이라는 행 접근 정책이 있고 그 행 접근 정책이 그 테이블에 지정된 경우예요. 이 한계를 우회하려면 두 데이터베이스를 같은 복제 또는 장애 조치 그룹에서 함께 복제해요.

삭제된 객체에 대한 참조:

같은 또는 다른 데이터베이스의 다른 객체가 참조하는 객체를 삭제하면 댕글링 참조가 생겨요. 기본 데이터베이스의 객체가 삭제된 객체를 참조하면 복제 연산이 다음 오류 메시지로 실패해요.

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

이 한계를 우회하려면 다음 단계 중 하나를 완료하는 것을 권장해요.

참조된 객체를 언드롭(undrop)해요.
참조 객체를 수정해요(예: ALTER MATERIALIZED VIEW로 구체화된 뷰 수정). 다른 객체를 참조하거나 삭제된 객체에 대한 참조를 제거해요.
기본 데이터베이스에서 삭제된 객체를 참조하는 객체를 삭제해요.

여러 데이터베이스의 복제

여러 데이터베이스가 복제될 때 데이터베이스 간 시점 일관성(point-in-time consistency)은 사용할 수 없어요. 각 기본 데이터베이스의 스냅샷이 독립적으로 만들어지고, 보조 데이터베이스에 대한 변경도 독립적으로 커밋돼요. 서로 다른 데이터베이스의 테이블에 걸쳐 조인하는 뷰가 있거나 크로스 데이터베이스 트랜잭션에 의존한다면 이는 문제가 될 수 있어요. 예를 들어 두 기본 데이터베이스를 원자적으로 갱신하는 트랜잭션은 보조 데이터베이스에 동시에 반영되지 않을 수 있어요. 시점 일관성으로 여러 데이터베이스를 복제하려면 복제 또는 장애 조치 그룹을 사용해요.

동적 테이블과 데이터 복제

동적 테이블이 데이터베이스 복제 밖의 소스 객체를 참조해도 여전히 복제될 수 있어요. 다만 보조 데이터베이스가 기본 데이터베이스와 이름이 다르면 이름 해석이 복잡해질 수 있어요. 장애 조치 후 소스 객체가 참조되는 방식에 따라 예상치 못한 새로 고침 결과가 나올 수 있어요. 이를 방지하려면 복제 설정 중 데이터베이스 이름을 바꾸지 않거나, 대신 장애 조치 그룹 복제를 사용해요.

예를 들어 동적 테이블 dt가 정규화된 이름으로 source_table 소스 객체를 참조한다고 가정해요.

CREATE DYNAMIC TABLE dt
  TARGET_LAG = DOWNSTREAM
  WAREHOUSE = my_wh
  AS
    SELECT * FROM db2.sch1.source_table;

복제 중에 DB1이 보조 계정에서 DB2로 이름이 바뀌어요. 장애 조치 후 보조 계정의 DB2에서 동적 테이블 dt를 새로 고치면 소스 테이블이 원래 기본 데이터베이스가 아니라 같은 데이터베이스 안에서 해석돼요. 이는 이름 해석 규칙과 일치하지만 예상치 못한 결과를 낳을 수 있어요.

데이터베이스 복제 고려 사항