여러 계정에 걸쳐 데이터베이스 복제하기

여러 계정에 걸쳐 데이터베이스 복제하기

이 주제는 여러 Snowflake 계정에 걸쳐 데이터베이스를 복제하고 데이터베이스 객체와 저장된 데이터를 동기화 상태로 유지하는 데 필요한 단계를 설명해요. 데이터베이스 복제는 같거나 다른 리전의 Snowflake 계정 간에 일어날 수 있어요.

출처: Snowflake User Guide - Replicating databases

본문

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

데이터베이스 복제·장애 조치/복귀의 리전 지원

Amazon Web Services, Google Cloud Platform, Microsoft Azure의 모든 Snowflake 리전이 데이터베이스 복제와 장애 조치/복귀(Failover/Failback)를 지원해요. 계정은 리전 그룹 간(예: Virtual Private Snowflake(VPS)와 멀티테넌트 리전 사이)에도 데이터베이스를 복제해 데이터 공유와 계정 마이그레이션을 촉진할 수 있어요. 이 기능은 기본적으로 비활성화되어 있으며, 활성화를 위해 Snowflake 지원에 연락할 수 있어요.

데이터베이스 복제·장애 조치/복귀용 웹 인터페이스

주의: Snowsight에서 복제와 장애 조치/복귀를 관리·모니터링하는 것은 프라이빗 연결을 사용하는 계정에서만 사용할 수 있어요. 그 외 계정은 Snowsight로 복제 모니터링과 계정 객체·데이터베이스 복제를 참고해요.

계정 관리자(ACCOUNTADMIN 역할)는 Snowsight에서 복제와 장애 조치/복귀 작업을 관리할 수 있어요. (탐색: Catalog » Explorer)

기본 데이터베이스 관리하기:

  1. 기본 데이터베이스가 포함된 Snowflake 계정으로 Snowsight에 로그인해요.
  2. 계정 관리자 역할로 전환하려면 왼쪽 아래에서 내 이름 » Switch role » ACCOUNTADMIN을 선택해요.
  3. 탐색 메뉴에서 Catalog » Explorer를 선택하고 Horizon Catalog Explorer에서 기본 데이터베이스를 선택해요. 데이터베이스 상세 페이지가 열려요. 또는 복제가 활성화된 데이터베이스만 보려면 Replication Status » Primary 필터로 계정의 기본 데이터베이스를 나열한 뒤 목록에서 데이터베이스를 선택해 상세 페이지를 열어요.

    참고: Replication Status 필터는 계정이 데이터베이스 복제의 소스 또는 대상 계정일 때만 사용할 수 있어요.

  4. … » Enable Replication을 선택해요. Enable replication 대화상자가 열려요. 수행할 작업을 선택해요.
    • Enable failover — 이 기능은 Business Critical Edition(이상)이 필요해요.
    • Create a secondary database in one or more target accounts — 다른 계정의 기본 데이터베이스가 현재 계정으로 복제가 활성화된 상태라면 현재 계정에 보조 데이터베이스를 만들 수 있어요. 대상 계정을 추가하려면 소스 계정에서 ALTER DATABASE 명령으로 기본 데이터베이스를 갱신해요.
    • Refresh each secondary database once, after it is created — 만들어진 각 보조 데이터베이스를 한 번 새로 고침해요.
  5. 이 데이터베이스의 각 대상 계정에 대해 보조 데이터베이스 생성과 데이터베이스 새로 고침 옵션을 체크해요.
  6. 대상 계정에 로그인한 뒤, 그 계정에서 이전에 ACCOUNTADMIN 역할을 부여받은 사용자로 다시 로그인해요. Snowflake가 요청한 작업을 수행하고 성공 대화상자를 표시해요. 이 데이터베이스의 복제는 데이터베이스 상세 페이지의 Replication 탭에서 관리해요.

보조 데이터베이스 관리하기:

  1. 보조 데이터베이스가 포함된 Snowflake 계정으로 Snowsight에 로그인해요.
  2. 왼쪽 위 드롭다운 메뉴(로그인 이름 옆)를 선택해 Switch Role » ACCOUNTADMIN을 선택해요.
  3. 탐색 메뉴에서 Catalog » Explorer를 선택해요. 페이지 오른쪽 위의 작업(…) 버튼에서 다음 작업을 사용할 수 있어요.
    • Create a secondary database — 다른 계정의 기본 데이터베이스가 현재 계정으로 복제가 활성화된 상태라면 현재 계정에 보조 데이터베이스를 만들 수 있어요. 대상 계정을 추가하려면 소스 계정에서 ALTER DATABASE 명령으로 기본 데이터베이스를 갱신해요.
  4. Horizon Catalog Explorer에서 보조 데이터베이스를 선택해요. 데이터베이스 상세 페이지가 열려요.
  5. Replication 탭을 선택해요. 페이지 오른쪽 위의 작업(…) 버튼에서 다음 작업을 사용할 수 있어요.
    • Promote the secondary database to serve as the primary database — 이 기능은 Business Critical Edition(이상)이 필요해요.

      참고: 보조 데이터베이스를 기본 데이터베이스 역할로 승격하려면 기본 데이터베이스가 그 보조 데이터베이스가 있는 대상 계정으로 장애 조치가 활성화되어 있어야 해요. 이 옵션을 사용할 수 없다면 소스 계정에서 ALTER DATABASE 명령으로 기본 데이터베이스에 대한 장애 조치를 대상 계정으로 활성화할 수 있어요.

    • Refresh the secondary database — 보조 데이터베이스를 새로 고침해요.
    • Copy a template to create a task that refreshes the secondary database on a schedule — 스케줄에 따라 보조 데이터베이스를 새로 고치는 태스크를 만들 템플릿을 복사해요. 템플릿을 Snowsight worksheet에 붙여넣고 원하는 스케줄을 지정하도록 편집해요.

데이터베이스를 다른 계정으로 복제하기

이 섹션의 지침은 계정을 복제용으로 준비하고, 로컬 데이터베이스를 기본 데이터베이스 역할로 승격하고, 이 기본 데이터베이스의 초기 복제를 다른 계정으로 수행하고, 보조 데이터베이스의 새로 고침을 스케줄링하는 방법을 설명해요.

중요: 대상 계정에는 Tri-Secret Secure나 AWS PrivateLink 같은 Snowflake 서비스에 대한 프라이빗 연결이 기본적으로 활성화되어 있지 않아요. 규정 준수·보안 또는 기타 목적으로 Tri-Secret Secure나 프라이빗 연결이 필요하다면 대상 계정에서 해당 기능을 구성하고 활성화하는 것은 당신의 책임이에요.

사전 요구 사항: 조직의 계정에 대한 복제 활성화

데이터베이스를 복제하기 전에 조직 관리자가 소스와 대상 계정에 대한 복제를 활성화해야 해요.

데이터베이스 복제·장애 조치 활성화 및 보조 데이터베이스 새로 고침

참고: 명시된 곳을 제외하고, 이 섹션의 SQL 문을 실행할 수 있는 것은 계정 관리자(ACCOUNTADMIN 역할)뿐이에요.

1단계: 조직의 모든 계정 보기

조직 안에서 복제가 활성화된 계정의 목록을 가져와요. 이 계정들의 기존 영구 또는 트랜션트 데이터베이스는 기본 데이터베이스 역할을 하도록 수정할 수 있어요. 기본 데이터베이스의 복제본(즉 보조 데이터베이스)은 이 계정들에서만 만들 수 있어요. 조직의 계정 목록을 보려면 SHOW REPLICATION ACCOUNTS를 쿼리해요.

SHOW REPLICATION ACCOUNTS;

+------------------+---------------------------------+---------------+------------------+---------+-------------------+
| snowflake_region | created_on                      | account_name  | account_locator  | comment | organization_name |
|------------------+---------------------------------+---------------+------------------+---------+-------------------|
| AWS_US_WEST_2    | 2018-11-19 16:11:12.720 -0700   | ACCOUNT1      | MYACCOUNT1       |         | MYORG             |
| AWS_US_EAST_1    | 2019-06-02 14:12:23.192 -0700   | ACCOUNT2      | MYACCOUNT2       |         | MYORG             |
+------------------+---------------------------------+---------------+------------------+---------+-------------------+

2단계: 로컬 데이터베이스를 기본 데이터베이스 역할로 승격하기

ALTER DATABASE … ENABLE REPLICATION TO ACCOUNTS 문으로 기존 영구 또는 트랜션트 데이터베이스를 기본 데이터베이스 역할을 하도록 수정해요. 이 데이터베이스의 복제본(즉 보조 데이터베이스)을 저장할 수 있는 조직 안 계정의 쉼표 구분 목록을 제공하고, 그 계정의 사용자가 보조 데이터베이스의 객체를 쿼리할 수 있게 해요. 계정 account1의 로컬 데이터베이스 mydb1을 기본 데이터베이스 역할로 승격하고 account2와 account3 계정이 각각 이 데이터베이스의 복제본을 저장할 수 있다고 지정해요.

ALTER DATABASE mydb1 ENABLE REPLICATION TO ACCOUNTS myorg.account2, myorg.account3;

3단계: 기본 데이터베이스에 대한 장애 조치 활성화하기

참고: 장애 조치/복귀는 Business Critical(이상)이 필요해요.

ALTER DATABASE … ENABLE FAILOVER TO ACCOUNTS 문으로 기본 데이터베이스에 대한 장애 조치를 조직 안의 하나 이상의 계정으로 활성화해요. 이 계정들 중 어느 하나의 기본 데이터베이스 복제본(즉 보조 데이터베이스)은 기본 데이터베이스 역할을 하도록 승격될 수 있어요. 기본 데이터베이스에 대한 장애 조치 활성화는 지정된 계정에 기본 데이터베이스의 복제본이 만들어진 전후 어느 때든 수행할 수 있어요.

-- 기본 계정에서 실행
ALTER DATABASE mydb1 ENABLE FAILOVER TO ACCOUNTS myorg.account2, myorg.account3;

4단계: 보조 데이터베이스 만들기

기본 데이터베이스를 저장하는 계정 또는 다른 계정(같거나 다른 리전)에 기존 기본 데이터베이스의 복제본을 만들어요. 보조 데이터베이스는 2단계의 ALTER DATABASE … ENABLE REPLICATION TO ACCOUNTS 문에 지정된 계정에서만 만들 수 있다는 점을 기억해요.

참고: 복제 명령(예: 소스 계정에서 데이터베이스를 기본 데이터베이스로 승격)은 일반적으로 리전을 넘어 연산을 트리거하며 효과가 나타나는 데 몇 초 걸릴 수 있어요. 예를 들어 소스 계정에서 데이터베이스를 기본 데이터베이스 역할로 승격하고 대상 계정에서 보조 데이터베이스를 만드는 경우, 보조 데이터베이스를 만들기까지 몇 초 걸릴 수 있어요.

각 대상 계정에서 CREATE DATABASE … AS REPLICA OF 문을 실행해 지정된 기본 데이터베이스의 복제본을 만들어요.

중요: 모범 사례로 각 보조 데이터베이스에 그 기본 데이터베이스와 같은 이름을 주는 것을 권장해요. 이 관행은 같은 데이터베이스 안의 다른 객체(예: 뷰에서 정규화된 테이블 이름 쿼리)가 정규화된 객체('<db>.<schema>.<object>')를 참조하는 것을 지원해요. 보조 데이터베이스가 기본 데이터베이스와 이름이 다르면 이러한 객체 참조가 보조 데이터베이스에서 깨져요.

다음 예시는 myorg.account2 계정에서 myorg.account1.mydb1 기본 데이터베이스의 복제본을 만들어요.

-- ACCOUNT2 계정으로 로그인.

-- 조직의 기본·보조 데이터베이스 집합을 쿼리.
-- 이 예시에서 MYORG.ACCOUNT1 기본 데이터베이스를 복제할 수 있습니다.
SHOW REPLICATION DATABASES;

-- 'mydb1' 기본 데이터베이스의 복제본 만들기
-- 기본 데이터베이스의 DATA_RETENTION_TIME_IN_DAYS 파라미터가 기본값이 아닌 값으로 설정되어 있으면
-- 보조 데이터베이스에도 같은 값을 설정합니다.
CREATE DATABASE mydb1
  AS REPLICA OF myorg.account1.mydb1
  DATA_RETENTION_TIME_IN_DAYS = 10;

-- 보조 데이터베이스 확인
SHOW REPLICATION DATABASES;

5단계: 각 보조 데이터베이스 새로 고침하기

이 섹션의 지침은 기본 데이터베이스의 스냅샷에서 보조 데이터베이스를 새로 고치는 방법(ALTER DATABASE … REFRESH)을 설명해요. 스냅샷에는 객체와 데이터의 변경이 포함돼요. 매우 큰 기본 데이터베이스의 초기 복제에는 문 타임아웃(statement timeout)을 늘리는 것을 권장해요.

참고:

  • 보조 데이터베이스를 새로 고치려면 연산을 수행하는 역할이 데이터베이스에 대한 OWNERSHIP 권한이 있거나, OWNERSHIP 권한이 있는 역할이 부여된 역할이어야 해요.
  • 새로 고침 연산을 실행하는 역할이 데이터베이스 새로 고침 결과로 추가된 모든 새 객체를 소유해요.
ALTER DATABASE mydb1 REFRESH;

6단계: 스케줄에 따라 보조 데이터베이스 새로 고침하기

모범 사례로 보조 데이터베이스의 새로 고침을 스케줄링하는 것을 권장해요. 이 섹션은 지정된 스케줄에 따라 데이터베이스 새로 고침을 자동으로 시작하는 방법을 제공해요. 보조 데이터베이스를 새로 고치는 빈도는 보조 데이터베이스 데이터의 복구 시점 목표(RPO, Recovery Point Objective)에 따라 달라져요. 예를 들어 데이터에 의존하는 애플리케이션이 최대 1시간의 데이터 손실을 허용한다면 최소한 매시간 데이터를 새로 고쳐야 해요. 데이터 손실 허용도가 5분이라면 최소한 5분마다 보조 데이터베이스를 새로 고쳐요.

참고:

  • 기본 데이터베이스의 초기 복제는 수동으로(ALTER DATABASE … REFRESH) 실행하고, 이후의 새로 고침만 스케줄링하는 것을 권장해요.
  • 태스크의 단일 실행에는 기본 60분 제한이 있어요. 이 제한은 종료되지 않는 태스크에 대한 안전장치로 구현됐어요. 드물게 매우 큰 데이터베이스의 새로 고침이 기본 태스크 실행 제한을 초과할 수 있어요. 이것이 발생했는지 확인하려면 TASK_HISTORY 테이블 함수를 쿼리해요. ALTER TASK … SET USER_TASK_TIMEOUT_MS = <num>을 실행해 태스크의 타임아웃 제한을 늘리는 것을 고려해요.

사전 요구 사항: 보조 데이터베이스를 저장하는 계정에는 다음 Snowflake 객체가 필요해요.

  • 보조 데이터베이스
  • 이 섹션에서 만든 새 객체를 저장할 별도의 데이터베이스. 보조 데이터베이스는 읽기 전용이라 이 데이터베이스는 보조 데이터베이스와 분리되어야 해요. 이 데이터베이스는 다음 객체도 포함해야 해요.
    • 스키마 — PUBLIC 스키마를 사용하거나 CREATE SCHEMA로 새 스키마를 만들어요.
    • 웨어하우스 — 문법 요건을 충족하기 위해 어떤 웨어하우스든 제공할 수 있지만 데이터베이스 새로 고침에는 사용되지 않아요. CREATE WAREHOUSE로 새 웨어하우스를 만들어요.
  • 스케줄에 따라 보조 데이터베이스를 새로 고치는 태스크

필요한 권한: 이 섹션의 단계는 보조 데이터베이스가 새로 고침되는 계정에서 다음 권한이 있는 역할이 필요해요.

객체 유형 객체 권한 참고
계정 보조 데이터베이스를 저장하는 계정 EXECUTE TASK 새 태스크를 실행하는 데 필요
데이터베이스 보조 데이터베이스 OWNERSHIP 보조 데이터베이스를 새로 고치는 데 필요
데이터베이스 새 태스크를 저장하는 데이터베이스 USAGE
스키마 새 태스크를 저장하는 스키마 USAGE, CREATE TASK
태스크 OWNERSHIP 태스크를 만든 역할이 기본적으로 객체를 소유해요. GRANT privileges … TO ROLE로 소유권을 다른 역할에 이전할 수 있어요.
웨어하우스 태스크 구성에 사용된 웨어하우스 USAGE 태스크를 구성하려면 웨어하우스 지정이 필요하지만, 웨어하우스는 태스크 실행이나 새로 고침 연산에 사용되지 않아요.

단계: 스케줄에 따라 새로 고침하려는 각 보조 데이터베이스에 대해 다음을 완료해요.

  1. CREATE TASK로 스케줄에 따라 데이터베이스 새로 고침을 시작하는 태스크를 만들어요. 복제 스케줄을 지정하는 CREATE TASK 문법에는 웨어하우스가 필요하지만, 그 웨어하우스는 복제에 사용되지 않아요. 예를 들어 보조 데이터베이스 mydb1을 4시간 타임아웃으로 10분마다 새로 고치는 refresh_mydb1_task라는 태스크를 만들어요. 태스크는 기존 웨어하우스 mywh로 구성돼요. 
    CREATE TASK refresh_mydb1_task
  WAREHOUSE = mywh
  SCHEDULE = '10 minute'
  USER_TASK_TIMEOUT_MS = 14400000
AS
  ALTER DATABASE mydb1 REFRESH;
  2. 태스크는 만들 때 기본적으로 일시 중지(suspended)돼요. 태스크가 태스크 정의에 지정된 파라미터에 따라 실행되도록 태스크를 재개해요. 
    ALTER TASK refresh_mydb1_task RESUME;

예시:

선호하는 Snowflake 클라이언트에서 다음 SQL을 실행해 복제·장애 조치를 활성화하고 초기 데이터베이스 새로 고침과 스케줄 새로 고침을 설정해요.

-- 아래 명령은 소스 계정에서 실행됩니다

-- 복제가 활성화된 계정 보기
SHOW REPLICATION ACCOUNTS;

ALTER DATABASE mydb ENABLE REPLICATION TO ACCOUNTS myorg.account2, myorg.account3;
ALTER DATABASE mydb ENABLE FAILOVER TO ACCOUNTS myorg.account2, myorg.account3;

-- 아래 명령은 각 대상 계정에서 실행됩니다

-- 복제가 활성화된 데이터베이스 보기
-- 아래 CREATE DATABASE 문을 위한 소스 데이터베이스의 primary 컬럼에 유의
SHOW REPLICATION DATABASES;

-- 기본 데이터베이스의 DATA_RETENTION_TIME_IN_DAYS 파라미터가 기본값이 아닌 값으로 설정되어 있으면
-- 보조 데이터베이스에도 같은 값을 설정합니다.
CREATE DATABASE mydb
  AS REPLICA OF myorg.account1.mydb
  DATA_RETENTION_TIME_IN_DAYS = 10;

-- 초기 새로 고침을 위한 문 타임아웃 증가
-- 대규모 데이터베이스의 초기 새로 고침에는 선택 사항이지만 권장됨
ALTER SESSION SET STATEMENT_TIMEOUT_IN_SECONDS = 604800;

-- 현재 세션에 활성 웨어하우스가 있으면 웨어하우스 문 타임아웃 갱신
SELECT CURRENT_WAREHOUSE();
ALTER WAREHOUSE my_wh SET STATEMENT_TIMEOUT_IN_SECONDS = 604800;

-- 초기 새로 고침 후 웨어하우스 문 타임아웃 재설정
ALTER WAREHOUSE my_wh UNSET STATEMENT_TIMEOUT_IN_SECONDS;

-- 보조 데이터베이스 새로 고침
ALTER DATABASE mydb REFRESH;

-- 태스크 만들기
-- 각 보조 데이터베이스에 대해 별도의 데이터베이스를 사용해 새로 고침 스케줄 설정
USE DATABASE my_db2;

-- 각 보조 데이터베이스에 대해 태스크를 만들고 RESUME
-- 특정 사용 사례에 맞게 태스크 스케줄과 타임아웃을 편집
CREATE TASK my_refresh_task
  WAREHOUSE = my_wh
  SCHEDULE = '10 minute'
  USER_TASK_TIMEOUT_MS = 14400000
AS
  ALTER DATABASE mydb REFRESH;

-- 태스크 시작
ALTER TASK my_refresh_task RESUME;

레거시 계정 로케이터 사용하기:

현재 복제·장애 조치 명령에서 계정을 식별할 때 레거시 snowflake_region.account_locator 형식이 지원되지만, 미래에 동작을 멈출 수 있으므로 사용을 권장하지 않아요.

초기 복제를 위한 문 타임아웃 증가

데이터베이스 복제는 객체와 데이터를 복사할 때 당신의 가상 웨어하우스가 아닌 Snowflake 제공 컴퓨팅 리소스를 사용해요. 다만 STATEMENT_TIMEOUT_IN_SECONDS 세션/객체 파라미터는 문이 취소되기 전에 실행되는 시간을 여전히 제어해요. 기본값은 172800(2일)이에요. 매우 큰 기본 데이터베이스의 초기 복제는 (데이터베이스의 메타데이터 양과 데이터베이스 객체의 데이터 양에 따라) 완료하는 데 2일 이상 걸릴 수 있으므로, 복제 연산을 실행하는 세션에서 STATEMENT_TIMEOUT_IN_SECONDS 값을 604800(7일, 최대값)으로 늘리는 것을 권장해요. 같은 세션에서 ALTER DATABASE secondary_db_name REFRESH 문을 실행하기 전에 다음 ALTER SESSION 문을 실행해요.

ALTER SESSION SET STATEMENT_TIMEOUT_IN_SECONDS = 604800;

STATEMENT_TIMEOUT_IN_SECONDS 파라미터는 세션의 활성 웨어하우스에도 적용돼요. 파라미터는 세션 또는 웨어하우스 수준에서 설정된 더 낮은 값을 따르는 것을 기억해요. 현재 세션에 활성 웨어하우스가 있다면 이 웨어하우스에도(ALTER WAREHOUSE로) STATEMENT_TIMEOUT_IN_SECONDS를 604800으로 설정해요. 예:

-- 현재 세션의 활성 웨어하우스 확인(있는 경우)
SELECT CURRENT_WAREHOUSE();

-- 활성 웨어하우스의 STATEMENT_TIMEOUT_IN_SECONDS 값 변경
ALTER WAREHOUSE my_wh SET STATEMENT_TIMEOUT_IN_SECONDS = 604800;

복제 연산이 완료된 후 파라미터 값을 기본값으로 재설정할 수 있어요.

ALTER WAREHOUSE my_wh UNSET STATEMENT_TIMEOUT_IN_SECONDS;

데이터베이스 새로 고침 진행 모니터링

초기 데이터베이스 복제 또는 이후의 보조 데이터베이스 새로 고침의 현재 상태를 확인하려면 (Snowflake 정보 스키마의) DATABASE_REFRESH_PROGRESS, DATABASE_REFRESH_PROGRESS_BY_JOB 테이블 함수를 쿼리해요. 데이터베이스 새로 고침 연산은 복제할 데이터 양에 따라 몇 시간 이상 걸릴 수 있어요. 지정된 데이터베이스에 대한 특정 날짜 범위 내 복제 기록을 보려면 다음 중 하나를 쿼리해요.

  • (정보 스키마의) DATABASE_REPLICATION_USAGE_HISTORY 테이블 함수 — 지난 14일의 복제 사용 활동을 반환해요.
  • (Account Usage의) DATABASE_REPLICATION_USAGE_HISTORY 뷰 — 지난 365일(1년)의 복제 사용 활동을 반환해요.

예시:

-- mydb1 보조 데이터베이스 새로 고침 진행 모니터링
select * from table(information_schema.database_refresh_progress('mydb1'));

데이터베이스 새로 고침 기록 보기

보조 데이터베이스 새로 고침 연산의 기록을 보려면 (정보 스키마의) DATABASE_REFRESH_HISTORY 테이블 함수를 쿼리해요. 이 함수는 지난 14일의 데이터베이스 새로 고침 활동을 반환해요. 또는 (공유된 Snowflake 데이터베이스의 Account Usage 스키마에 있는) DATABASE_REPLICATION_USAGE_HISTORY 뷰를 쿼리해요. 이 뷰는 지난 365일(1년)의 데이터베이스 복제 사용 활동을 반환해요.

예시:

-- mydb1 보조 데이터베이스 새로 고침 연산 기록 보기
select * from table(information_schema.database_refresh_history('mydb1'));

데이터베이스 복제 비용 모니터링

데이터베이스 복제로 복제된 개별 데이터베이스에 대해 ACCOUNTADMIN 역할을 가진 사용자는 Snowsight 또는 SQL로 지정된 날짜 범위 안에서 Snowflake 계정에 대해 전송된 복제 데이터 양(바이트)을 볼 수 있어요.

계정의 데이터 전송량을 보려면:

  • 탐색 메뉴에서 Admin » Cost management를 선택해요.

SQL로는 다음 중 하나를 쿼리해요.

  • (정보 스키마의) DATABASE_REPLICATION_USAGE_HISTORY 테이블 함수 — 지난 14일의 데이터베이스 복제 사용 활동을 반환해요.
  • (Account Usage의) DATABASE_REPLICATION_USAGE_HISTORY 뷰 — 지난 365일(1년)의 데이터베이스 복제 사용 활동을 반환해요.

DATABASE_REPLICATION_USAGE_HISTORY 뷰에 대해 다음 쿼리를 실행할 수 있어요.

쿼리: 복제 비용 기록(일별, 객체별)

이 쿼리는 복제된 데이터베이스 전체 목록과 지난 30일 동안 복제 서비스를 통해 소비된 크레딧 양을 일별로 나눠 제공해요. 크레딧 소비의 불규칙성이나 지속적으로 높은 소비는 추가 조사가 필요한 신호예요.

SELECT TO_DATE(start_time) AS date,
  database_name,
  SUM(credits_used) AS credits_used
FROM snowflake.account_usage.database_replication_usage_history
WHERE start_time >= DATEADD(month,-1,CURRENT_TIMESTAMP())
GROUP BY 1,2
ORDER BY 3 DESC;

쿼리: 복제 기록 & 평균

이 쿼리는 지난 1년 동안 주별로 그룹화된 복제가 소비한 일일 평균 크레딧을 보여줘요. 일일 평균의 이상치를 식별해 소비의 급증이나 변화를 조사하는 데 도움이 돼요.

WITH credits_by_day AS (
  SELECT TO_DATE(start_time) AS date,
    SUM(credits_used) AS credits_used
  FROM snowflake.account_usage.database_replication_usage_history
  WHERE start_time >= DATEADD(year,-1,CURRENT_TIMESTAMP())
  GROUP BY 1
  ORDER BY 2 DESC
)
SELECT DATE_TRUNC('week',date),
  AVG(credits_used) AS avg_daily_credits
FROM credits_by_day
GROUP BY 1
ORDER BY 1;

기본·보조 데이터베이스의 데이터 집합 비교

선택적으로 HASH_AGG 함수를 사용해 기본·보조 데이터베이스의 무작위 테이블 집합에서 행을 비교해 데이터 일관성을 검증해요. HASH_AGG 함수는 (순서 없는) 입력 행 집합에 대한 집계된 부호 있는 64비트 해시 값을 반환해요. 보조 데이터베이스의 전체 또는 무작위 부분집합 테이블과 (기본 데이터베이스 스냅샷의 타임스탬프 시점의) 기본 데이터베이스에서 이 함수를 쿼리하고 출력을 비교해요.

보조 데이터베이스에서 실행:

  1. 보조 데이터베이스에서 (정보 스키마의) DATABASE_REFRESH_PROGRESS 테이블 함수를 쿼리해요. PRIMARY_UPLOADING_DATA 단계의 DETAILS 컬럼에서 snapshot_transaction_timestamp를 기록해요. 이는 기본 데이터베이스의 최신 스냅샷 타임스탬프예요. 
    select parse_json(details)['snapshot_transaction_timestamp']
from table(information_schema.database_refresh_progress('mydb'))
where phase_name = 'PRIMARY_UPLOADING_DATA';
  2. 지정된 테이블에 대해 HASH_AGG 함수를 쿼리해요. 다음 쿼리는 mytable 테이블의 모든 행에 대한 해시 값을 반환해요. 
    SELECT HASH_AGG(*) FROM mytable;

기본 데이터베이스에서 실행:

  1. 기본 데이터베이스에서 같은 테이블에 대해 HASH_AGG 함수를 쿼리해요. Time Travel을 사용해 보조 데이터베이스의 최신 스냅샷이 촬영된 타임스탬프를 지정해요. 
    SELECT HASH_AGG(*) FROM mytable AT(TIMESTAMP => '<snapshot_transaction_timestamp>'::TIMESTAMP);
  2. 두 쿼리의 결과를 비교해요. 출력은 동일해야 해요.

보조 데이터베이스 삭제하기

DROP DATABASE 명령으로 언제든 보조 데이터베이스를 삭제할 수 있어요. 데이터베이스 소유자(즉 데이터베이스에 대한 OWNERSHIP 권한이 있는 역할)만 데이터베이스를 삭제할 수 있어요.

기본 데이터베이스 삭제하기

기본 데이터베이스의 복제본(즉 보조 데이터베이스)이 하나 이상 존재하면 기본 데이터베이스를 삭제할 수 없어요. 기본 데이터베이스를 삭제하려면 먼저 보조 데이터베이스를 기본 데이터베이스 역할로 승격한 뒤 이전 기본 데이터베이스를 삭제해요. 또는 기본 데이터베이스의 모든 보조 데이터베이스를 삭제한 뒤 기본 데이터베이스를 삭제해요.

더 알아보기